RFC4023：Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)，March 2005
本备忘录的状态
本文档为 Internet 社区指定了 Internet 标准跟踪协议，并请求讨论和改进建议。本协议的标准化状态和现状请参考当前版本的《互联网官方协议标准》（STD 1）。本备忘录的分发不受限制。
版权声明
版权所有 (C) 互联网协会 (2005)。
梗概
MPLS 的各种应用程序使用具有多个条目的标签堆栈。在某些情况下，可以用基于 IP 的封装替换堆栈的顶部标签，从而使应用程序能够在其核心路由器中未启用 MPLS 的网络上运行。本文档规定了两种基于 IP 的封装：MPLS-in-IP 和 MPLS-in-GRE（Generic Routing Encapsulation，通用路由封装）。这些中的每一个都适用于某些情况。
1、 动机
在 MPLS 的许多应用中，通过 MPLS 骨干网的数据包携带具有多个标签的标签堆栈。如 [RFC3031-MPLS：多协议标签交换架构] 的 3.15 节所述，每个标签代表一个标签交换路径（Label Switched Path，LSP）。对于每个 LSP，有一个标签交换路由器 (Label Switching Router，LSR) 是“LSP 入口”，还有一个 LSR 是“LSP 出口”。如果 LSR A 和 B 分别是与数据包顶部标签对应的 LSP 的入口和出口，则 A 和 B 是与数据包的第二个标签（即紧接在顶部标签下方的标签）对应的 LSP 上的相邻 LSR .
顶部标签的目的（或其中一个目的）是将数据包从 A 传送到 B，以便 B 可以根据第二个标签进一步处理数据包。从这个意义上说，顶部标签用作数据包其余部分的封装标头。在某些情况下，其他类型的封装头可以在不损失功能的情况下替换顶部标签。例如，IP 标头或通用路由封装 (GRE) 标头可以替换顶部标签。由于封装的数据包仍然是 MPLS 数据包，因此结果是 MPLS-in-IP 或 MPLS-in-GRE 封装。
通过这些封装，LSP 上相邻的两个 LSR 可能被 IP 网络分隔开，即使该 IP 网络不提供 MPLS。
要使用这些封装中的任何一种，封装 LSR 必须知道
- 解封装 LSR 的 IP 地址，以及
- 解封装的 LSR 实际上支持特定的封装。
该知识可以通过手动配置或通过某种发现协议传送到封装 LSR。特别地，如果隧道被用于支持特定应用程序并且该应用程序具有设置或发现协议，则该应用程序的协议可以传达该知识。传达这些知识的方式超出了本文档的范围。
2、 需求说明
在本文档中，关键词“必须”、“不得”、“必需”、“应该”、“不应”、“应该”、“不应该”、“推荐”、“可以”和“可选” 将按照 [RFC2119-在 RFC 中用于表示需求级别的关键词] 中的描述进行解释。
3、IP封装
MPLS-in-IP 消息具有以下格式：
IP Header/IP头
该字段包含分别在 [RFC791-网络协议-INTERNET PROTOCOL] 或 [RFC2460] 中定义的 IPv4 或 IPv6 数据报头。源地址和目的地址分别设置为封装和解封装 LSR 的地址。
MPLS Label Stack/MPLS 标签栈
该字段包含 [RFC3032] 中定义的 MPLS 标签栈。
Message Body/消息正文
该字段包含一个 MPLS 消息体。
IPv4 Protocol Number字段或IPv6 Next Header字段设置为137，表示MPLS单播报文。（本规范不支持将 MPLS-in-IP 封装用于 MPLS 组播数据包。）
IP 报头之后是 MPLS 数据包，如 [RFC3032] 中所述。这种封装导致 MPLS 数据包通过“IP 隧道”发送。当隧道的接收端点收到一个数据包时，它通过去除 IP 头来解封装 MPLS 数据包。然后将数据包作为接收到的 MPLS 数据包进行处理，其“传入标签”[RFC3031] 是解封装数据包的最顶部标签。
4、 GRE中的封装
MPLS-in-GRE 封装将 MPLS 数据包封装在 GRE [RFC2784] 中。然后，数据包由 IP 标头（IPv4 或 IPv6）、GRE 标头和 MPLS 标签堆栈组成，如 [RFC3032-MPLS 标签栈编码] 中所述。GRE 报头中的协议类型字段必须设置为 MPLS 单播 (0x8847) 或组播 (0x8848) 的 Ethertype 值。
这种封装导致 MPLS 数据包通过“GRE 隧道”发送。当隧道的接收端点收到数据包时，它会通过删除 IP 和 GRE 标头来解封装 MPLS 数据包。然后将数据包作为接收到的 MPLS 数据包进行处理，其“传入标签”[RFC3031] 是解封装数据包的最顶部标签。
[RFC2784] 指定了可选的 GRE 校验和，[RFC2890] 指定了可选的 GRE 密钥和序列号字段。这些可选字段对于 MPLS-in-GRE 封装不是很有用。不需要序列号和校验和字段，因为在被隧道传输的本地 MPLS 数据包中没有相应的字段。解复用不需要 GRE 密钥字段，因为封装数据包的顶部 MPLS 标签用于此目的。GRE 密钥字段有时被视为一种安全功能，用作 32 位明文密码，但这是一种极其薄弱的安全形式。为了（a）促进封装/解封装过程的高速实现和（b）确保互操作性，我们要求所有实现都能够在没有这些可选字段的情况下正确运行。
更准确地说，MPLS-in-GRE 解封装器的实现必须能够在没有这些可选字段的情况下正确处理数据包。它可能能够使用这些可选字段正确处理数据包。
MPLS-in-GRE 封装器的实现必须能够生成没有这些可选字段的数据包。它可能有能力生成带有这些字段的数据包，但默认状态必须是生成的数据包没有这些字段。除非知道解封装器可以正确处理它们，否则封装器不得包含任何这些可选字段。传达这些知识的方法超出了本规范的范围。
5、 通用程序
某些过程对于 MPLS-in-IP 和 MPLS-in-GRE 封装都是通用的。在下文中，其地址出现在封装 IP 标头的 IP 源地址字段中的封装器称为“隧道头”。解封装器的地址出现在解封装 IP 标头的 IP 目标地址字段中，称为“隧道尾”。
如果正在使用 IPv6（对于 MPLS-in-IPv6 或 MPLS-in-GRE-in-IPv6），[RFC2473] 的程序通常适用。
5.1、 防止分片和重新组装
如果 MPLS-in-IP 或 MPLS-in-GRE 数据包被分片（由于“普通”IP 分片），隧道尾部将必须在包含的 MPLS 数据包被解封装之前重新组装它。当隧道尾部是路由器时，这可能是不可取的；隧道尾部可能没有能力或资源以必要的性能水平进行重组。
是否允许隧道数据包的分片必须在隧道头配置。默认值必须是数据包不被分片。只有在知道隧道尾部可以充分执行重组功能时才会更改默认值。
本节其余部分规定的程序仅适用于不分片的数据包。
显然，如果不将数据包分片，则隧道头在封装数据包之前不得将其分片。
如果使用 IPv4，则隧道必须设置 DF 位。这可以防止隧道中的中间节点执行分片。（如果使用 IPv6，中间节点在任何情况下都不会执行分片。）
隧道头应该执行路径 MTU 发现（[RFC1191-你了解MTU和TCP MSS不？] for IPv4，或 [RFC1981] for IPv6）。
隧道头必须为每个隧道维护一个“隧道 MTU”；这是 (a) 管理配置值和 (b) 发现的路径 MTU 值减去封装开销中的最小值。
如果隧道头接收到一个大小超过隧道 MTU 的 MPLS 数据包进行封装，则该数据包必须被丢弃。但是，静默丢弃此类数据包可能会导致严重的操作问题；数据包的发起者会注意到他的数据没有通过，但他可能没有意识到大数据包正在导致数据包丢失。因此，他可以继续发送被丢弃的数据包。路径 MTU 发现可以提供帮助（如果隧道头发回 ICMP 错误），但在隧道头处通常没有足够的可用信息来正确识别始发发送者。为了尽量减少问题，建议在实践中将 MTU 设计得足够大以避免分片。
在某些情况下，隧道头接收用于封装的 IP 数据包，它首先封装在 MPLS 中，然后封装在 MPLS-in-IP 或 MPLS-in-GRE 中。如果 IP 数据包的源可以从隧道头到达，并且如果在 MPLS 中封装数据包的结果将是一个大小超过隧道 MTU 的数据包，那么隧道头应该使用的值在外面进行分片和 PMTU 发现隧道是隧道 MTU 值减去 MPLS 封装的大小。（也就是说，隧道 MTU 值减去 MPLS 封装的大小就是要在 ICMP 消息中报告的 MTU。）该数据包将不得不被丢弃，但隧道头应将丢弃的数据包的 IP 源发送到[RFC1191] 或 [RFC1981] 中指定的正确 ICMP 错误消息。
5.2、 TTL 或跳数限制
隧道头可以将 MPLS 标签栈中的 TTL 放入封装 IPv4 头的 TTL 字段或封装 IPv6 头的 Hop Limit 字段中。隧道尾部可以将来自封装 IPv4 报头的 TTL 或来自封装 IPv6 报头的 Hop Limit 放入 MPLS 报头的 TTL 字段中，但前提是这不会增加 MPLS 报头中的 TTL 值。
是否进行此类修改以及如何进行修改的细节将取决于隧道尾部和隧道头部的配置。
5.3、 差异化服务
本文档中指定的过程使 LSP 能够通过 IP 或 GRE 隧道发送。[RFC2983]详细说明了在存在 IP-in-IP 隧道的情况下必须应用的许多考虑因素和程序，以正确支持差异化服务架构。这些注意事项和程序也适用于存在 MPLS-in-IP 或 MPLS-in-GRE 隧道的情况。
因此，当隧道头将要发送 MPLS 数据包到 MPLS-in-IP 或 MPLS-in-GRE 隧道时，封装 IPv4 或 IPv6 头的 DS 字段的设置可以（至少部分地）由MPLS 数据包的“行为聚合”。[RFC3270] 中规定了确定 MPLS 数据包行为聚合的过程。
类似地，在隧道尾部，封装的 IPv4 或 IPv6 头的 DS 字段可以用来确定封装的 MPLS 数据包的行为聚合。[RFC3270]规定了行为聚合和数据包的后续处置之间的关系。
6、 适用性
MPLS-in-IP 封装效率更高，在其他条件相同的情况下，它通常被认为是更可取的。但是，在某些情况下可以使用 MPLS-in-GRE 封装：
- 两台路由器在 GRE 隧道上“相邻”，该隧道由于某种原因存在，超出了本文档的范围，并且这两个路由器必须通过该相邻发送 MPLS 数据包。由于通过此邻接发送的所有数据包都必须具有 GRE 封装，因此 MPLS-in-GRE 封装比替代方案更有效，即 MPLS-in-IP 封装然后封装在 GRE 中。
- 实施考虑可能决定 MPLS-in-GRE 的使用。例如，某些硬件设备可能只能处理其快速路径中的 GRE 封装。
7、 IANA 考虑
IANA 已为 MPLS-in-IP 封装分配了 IP 协议编号 137，如第 3 节所述。以后不需要 IANA 采取任何行动。MPLS-in-GRE 封装不需要任何 IANA 操作。
8、 安全考虑
使用 IP 或 GRE 隧道时面临的主要安全问题是，隧道的接收端点可能会收到看似来自隧道的数据包，但实际上并未由隧道的传输端点放入隧道。 （指定的封装本身并不能使解封装器对封装器进行身份验证。）
第二个问题是数据包在进入隧道和离开的时间之间有可能被改变。 （指定的封装本身并不能向解封装器保证数据包的完整性。）
第三个问题是当数据包通过隧道传输时，数据包的内容可能会被看到。 （规范封装不确保隐私。）这些问题在实践中的重要性取决于其流量通过隧道发送的应用程序的安全要求。例如，如果生成数据包的应用程序不需要隐私，则隧道数据包缺乏隐私并不是一个重要问题。
由于使用所描述的封装机制的不同应用程序具有不同的潜在安全要求、部署场景和性能考虑因素，因此本规范将 IPsec 支持定义为 OPTIONAL。如果实现了 IPsec，基本实现要求在 8.1 节中描述。如果未实施 IPsec，则可能必须实施和部署其他机制。这些将在第 8.2 节中讨论。
8.1、 使用 IPsec 保护隧道
如果使用 IPsec 保护 MPLS-in-IP 或 MPLS-in-GRE 隧道，所有这些安全问题都可以避免。如果实施了 IPsec，则本节中定义的实施要求适用。
当使用 IPsec 时，隧道头和隧道尾应被视为安全关联的端点。为此，隧道头的单个IP地址将用作源IP地址，隧道尾的单个IP地址将用作目的IP地址。每个节点知道另一个节点的正确地址的方式超出了本文档的范围。如果使用控制协议来建立隧道（例如，将另一个隧道的 IP 地址通知一个隧道端点），则控制协议必须具有身份验证机制，并且必须在建立隧道时使用此机制。如果隧道是自动建立的，例如由 BGP 分发的信息，那么使用 BGP 的基于 MD5 的认证机制是令人满意的。
MPLS-in-IP 或 MPLS-in-GRE 封装的数据包应被视为起源于隧道头，目的地为隧道尾；因此应该使用 IPsec 传输模式。
当隧道头使用 IPsec 传输模式来保护 MPLS-in-IP 数据包时，MPLS-in-IP 数据包的 IP 报头将成为结果数据包的外部 IP 报头。后面跟着一个 IPsec 标头，后面跟着 MPLS 标签栈。IPsec 标头必须使用第 3 节中指定的 IP 协议编号将负载类型设置为 MPLS。如果 IPsec 传输模式应用于 MPLS-in-GRE 数据包，则 GRE 标头跟在 IPsec 标头之后。
在隧道尾部，IPsec 出站处理恢复包含的 MPLS-in-IP/GRE 数据包。然后隧道尾部剥离封装的 IP/GRE 标头以恢复 MPLS 数据包，然后根据其标签堆栈转发该数据包。
注意隧道尾和隧道头是LSP邻接，这意味着通过隧道发送的任何数据包的最顶层标签必须是由隧道尾分配给隧道头的标签。隧道尾部必须准确地知道它已分配给 IPsec 安全隧道的隧道头部的标签。该集合中的标签不得由隧道尾部分发到任何 LSP 邻接，除了 IPsec 安全隧道的隧道头。如果在没有 IPsec 封装的情况下接收 MPLS 数据包，并且它的最顶层标签在此集合中，则必须丢弃该数据包。
IPsec 保护的 MPLS-in-IP 或 MPLS-in-GRE 隧道必须提供身份验证和完整性。（请注意，身份验证和完整性将应用于整个 MPLS 数据包，包括 MPLS 标签堆栈。）因此，实现必须支持 ESP will null 加密。如果源需要机密性，可以支持带加密的 ESP。如果使用 ESP，隧道尾部必须检查在给定 SA 上接收的任何数据包的源 IP 地址是否是预期的。
密钥分发可以通过 IKE [RFC2409-IKE：互联网密钥交换] 手动或自动完成。必须支持手动键控。如果实现自动键控，则必须支持主模式下具有预共享密钥的 IKE。特定应用程序可能会升级此要求并请求实现自动键控。
手动密钥分发比自动密钥分发简单得多，但可扩展性也较差。因此，负责隧道端点的管理员（或管理员对）必须仔细考虑哪种密钥分发方法适用于特定隧道。如果认为特定隧道需要重放保护，则应配置自动密钥分发。
如果使用 MPLS-in-IP 封装，则与 SA 关联的选择器将是上述源地址和目标地址，加上第 3 节中指定的 IP 协议编号。如果需要保护多个 MPLS-in-IP在给定的一对节点之间分别建立隧道，每个隧道必须有唯一的 IP 地址对。
如果使用 MPLS-in-GRE 封装，则与 SA 关联的选择器将是上述源地址和目标地址，以及代表 GRE (47) 的 IP 协议编号。如果需要分别保护给定节点对之间的多个 MPLS-in-GRE 隧道，每个隧道必须具有唯一的 IP 地址对。
8.2、 在没有 IPsec 的情况下
如果隧道没有使用 IPsec 进行保护，那么应该使用其他一些方法来确保只有当这些数据包被隧道头封装时，隧道尾部才对数据包进行解封装和转发。如果隧道完全位于单个管理域内，则可以使用边界地址过滤来确保具有隧道端点IP 源地址或隧道端点IP 目标地址的数据包无法从外部进入域。
然而，当隧道头和隧道尾不在同一个管理域中时，这可能变得困难，如果数据包必须穿越公共互联网，基于目的地址的过滤甚至变得不可能。
有时，在管理域的边界上只进行源地址过滤（而不是目标地址过滤）。如果是这种情况，除非 MPLS-in-IP 或 MPLS-in-GRE 的解封装器验证数据包的 IP 源地址，否则过滤根本不会提供有效保护。本文档不要求解封装器验证隧道数据包的 IP 源地址，但应理解，如果不这样做，则预先假定存在有效的基于目的地（或基于源和基于目的地的组合）过滤在边界。
9、 致谢
该规范结合了 Tom Worster、Paul Doolan、Yasuhiro Katsube、Tom K. Johnson、Andrew G. Malis 和 Rick Wilder 在 IP 中封装 MPLS 的先前工作，以及 Yakov Rekhter、Daniel Tappan 在 GRE 中封装 MPLS 的先前工作，和埃里克·罗森。目前的作者要感谢所有这些作者的贡献。
许多人提出了宝贵的意见和更正，包括 Rahul Aggarwal、Scott Bradner、Alex Conta、Mark Duffy、Francois Le Feucheur、Allison Mankin、Thomas Narten、Pekka Savola 和 Alex Zinin。
10、 规范性引用
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981. [RFC792] Postel, J., "Internet Control Message Protocol", STD 5, RFC 792, September 1981. [RFC1191] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990. [RFC1981] McCann, J., Deering, S., and J. Mogul, "Path MTU Discovery for IP version 6", RFC 1981, August 1996. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC2463] Conta, A. and S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 2463, December 1998. [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in IPv6 Specification", RFC 2473, December 1998. [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., and P. Traina, "Generic Routing Encapsulation (GRE)", RFC 2784, March 2000. [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol Label Switching Architecture", RFC 3031, January 2001. [RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.
11、 参考资料
[RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the Internet Protocol", RFC 2401, November 1998. [RFC2402] Kent, S. and R. Atkinson, "IP Authentication Header", RFC 2402, November 1998. [RFC2406] Kent, S. and R. Atkinson, "IP Encapsulating Security Payload (ESP)", RFC 2406, November 1998. [RFC2409] Harkins, D. and D. Carrel, "The Internet Key Exchange (IKE)", RFC 2409, November 1998. [RFC2475] Blake, S., Black, D., Carlson, M., Davies, E., Wang, Z., and W. Weiss, "An Architecture for Differentiated Service", RFC 2475, December 1998. [RFC2890] Dommety, G., "Key and Sequence Number Extensions to GRE", RFC 2890, September 2000. [RFC2983] Black, D., "Differentiated Services and Tunnels", RFC 2983, October 2000. [RFC3260] Grossman, D., "New Terminology and Clarifications for Diffserv", RFC 3260, April 2002. [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.
完整的版权声明
版权所有 (C) 互联网协会 (2005)。
本文档受 BCP 78 中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
本文档和其中包含的信息按“原样”提供，贡献者、他/她所代表或赞助的组织（如果有）、互联网社会和互联网工程特别工作组不作任何明示或保证暗示，包括但不限于任何保证，即使用此处的信息不会侵犯任何权利或任何暗示的适销性或特定用途适用性保证。
知识产权
对于可能声称与本文档中描述的技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或者此类权利下的任何许可可能会或可能不会的程度，IETF 不采取任何立场能得到的;也不代表它已作出任何独立努力来确定任何此类权利。可以在 BCP 78 和 BCP 79 中找到有关 RFC 文档中权利的程序的信息。
可以获得向 IETF 秘书处披露的知识产权副本和任何可用许可的保证，或者可以获得本规范的实施者或用户使用此类专有权利的一般许可或许可的尝试结果来自 IETF 在线知识产权资源库 http://www.ietf.org/ipr。
IETF 邀请任何相关方提请其注意任何版权、专利或专利申请，或可能涵盖实施本标准可能需要的技术的其他专有权利。请将信息发送至 IETF ietf-ipr@ietf.org。
致谢
RFC 编辑器功能的资金目前由互联网协会提供。
