Internet Engineering Task Force (IETF) X. Xu
Request for Comments: 7510 Huawei Technologies
Category: Standards Track N. Sheth
ISSN: 2070-1721 Juniper Networks
L. Yong
Huawei USA
R. Callon
Juniper Networks
D. Black
EMC Corporation
April 2015
Internet Engineering Task Force (IETF) X. Xu
Request for Comments: 7510 Huawei Technologies
Category: Standards Track N. Sheth
ISSN: 2070-1721 Juniper Networks
L. Yong
Huawei USA
R. Callon
Juniper Networks
D. Black
EMC Corporation
April 2015
Encapsulating MPLS in UDP
用UDP封装MPLS
Abstract
摘要
This document specifies an IP-based encapsulation for MPLS, called MPLS-in-UDP for situations where UDP (User Datagram Protocol) encapsulation is preferred to direct use of MPLS, e.g., to enable UDP-based ECMP (Equal-Cost Multipath) or link aggregation. The MPLS-in-UDP encapsulation technology must only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Usage restrictions apply to MPLS-in-UDP usage for traffic that is not congestion controlled and to UDP zero checksum usage with IPv6.
本文档为MPLS指定了基于IP的封装，在UDP中称为MPLS，用于UDP（用户数据报协议）封装优于直接使用MPLS的情况，例如，启用基于UDP的ECMP（等成本多路径）或链路聚合。UDP封装技术中的MPLS必须仅部署在单个网络（具有单个网络运营商）或相邻一组合作网络运营商的网络中，在这些网络中管理流量以避免拥塞，而不是部署在需要拥塞控制的Internet上。使用限制适用于未受拥塞控制的流量的UDP使用中的MPLS以及IPv6的UDP零校验和使用。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7510.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7510.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3
1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 4
1.3. Applicability Statements . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 5
3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 10
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 10
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Existing Encapsulations . . . . . . . . . . . . . . . . . 3
1.2. Motivations for MPLS-in-UDP Encapsulation . . . . . . . . 4
1.3. Applicability Statements . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. Encapsulation in UDP . . . . . . . . . . . . . . . . . . . . 5
3.1. UDP Checksum Usage with IPv6 . . . . . . . . . . . . . . 6
3.2. Middlebox Considerations for IPv6 UDP Zero Checksums . . 10
4. Processing Procedures . . . . . . . . . . . . . . . . . . . . 10
5. Congestion Considerations . . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 13
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15
8. References . . . . . . . . . . . . . . . . . . . . . . . . . 15
8.1. Normative References . . . . . . . . . . . . . . . . . . 15
8.2. Informative References . . . . . . . . . . . . . . . . . 16
Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . . 17
Contributors . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19
This document specifies an IP-based encapsulation for MPLS, i.e., MPLS-in-UDP, which is applicable in some circumstances where IP-based encapsulation for MPLS is required and further fine-grained load balancing of MPLS packets over IP networks over Equal-Cost Multipath (ECMP) and/or Link Aggregation Groups (LAGs) is required as well. There are already IP-based encapsulations for MPLS that allow for fine-grained load balancing by using some special field in the encapsulation header as an entropy field. However, MPLS-in-UDP can be advantageous since networks have used the UDP port number fields as a basis for load-balancing solutions for some time.
本文档规定了MPLS的基于IP的封装，即UDP中的MPLS，适用于需要基于IP的MPLS封装的某些情况，并且还需要在IP网络上通过等成本多路径（ECMP）和/或链路聚合组（LAG）进一步实现MPLS包的细粒度负载平衡。已经有了基于IP的MPLS封装，通过使用封装头中的某些特殊字段作为熵字段，可以实现细粒度负载平衡。然而，UDP中的MPLS可能是有利的，因为网络已经使用UDP端口号字段作为负载平衡解决方案的基础一段时间了。
Like other IP-based encapsulation methods for MPLS, this encapsulation allows for two Label Switching Routers (LSR) to be adjacent on a Label Switched Path (LSP), while separated by an IP network. In order to support this encapsulation, each LSR needs to know the capability to decapsulate MPLS-in-UDP by the remote LSRs. This specification defines only the data-plane encapsulation and does not concern itself with how the knowledge to use this encapsulation is conveyed. Specifically, this capability can be either manually configured on each LSR or dynamically advertised in manners that are outside the scope of this document.
与用于MPLS的其他基于IP的封装方法一样，这种封装允许两个标签交换路由器（LSR）在标签交换路径（LSP）上相邻，同时由IP网络分隔。为了支持这种封装，每个LSR都需要知道远程LSR在UDP中解除MPL封装的能力。本规范仅定义数据平面封装，而不涉及如何传递使用该封装的知识。具体来说，此功能可以在每个LSR上手动配置，也可以以本文档范围之外的方式动态发布。
Similarly, the MPLS-in-UDP encapsulation format defined in this document by itself cannot ensure the integrity and privacy of data packets being transported through the MPLS-in-UDP tunnels and cannot enable the tunnel decapsulators to authenticate the tunnel encapsulator. Therefore, in the case where any of the above security issues is concerned, the MPLS-in-UDP SHOULD be secured with IPsec [RFC4301] or Datagram Transport Layer Security (DTLS) [RFC6347]. For more details, please see Section 6 (Security Considerations).
同样，本文档中定义的UDP封装格式的MPLS本身无法确保通过UDP隧道中的MPLS传输的数据包的完整性和隐私性，也无法使隧道解封装器对隧道封装器进行身份验证。因此，在涉及上述任何安全问题的情况下，UDP中的MPLS应使用IPsec[RFC4301]或数据报传输层安全性（DTLS）[RFC6347]进行保护。有关更多详细信息，请参阅第6节（安全注意事项）。
Currently, there are several IP-based encapsulations for MPLS such as MPLS-in-IP, MPLS-in-GRE (Generic Routing Encapsulation) [RFC4023], and MPLS-in-L2TPv3 (Layer 2 Tunneling Protocol Version 3) [RFC4817]. In all these methods, the IP addresses can be varied to achieve load balancing.
目前，有几种基于IP的MPLS封装，如IP中的MPLS、GRE中的MPLS（通用路由封装）[RFC4023]和MPLS-in-L2TPv3（第2层隧道协议版本3）[RFC4817]。在所有这些方法中，可以改变IP地址以实现负载平衡。
All these IP-based encapsulations for MPLS are specified for both IPv4 and IPv6. In the case of IPv6-based encapsulations, the IPv6 Flow Label can be used for ECMP and LAGs [RFC6438]. However, there is no such entropy field in the IPv4 header.
所有这些基于IP的MPLS封装都是为IPv4和IPv6指定的。对于基于IPv6的封装，IPv6流标签可用于ECMP和LAGs[RFC6438]。但是，IPv4报头中没有这样的熵字段。
For MPLS-in-GRE as well as MPLS-in-L2TPv3, protocol fields (the GRE Key and the L2TPv3 Session ID, respectively) can be used as the load-balancing key as described in [RFC5640]. For this, intermediate routers need to understand these fields in the context of being used as load-balancing keys.
对于GRE中的MPLS以及L2TPv3中的MPLS，协议字段（分别为GRE密钥和L2TPv3会话ID）可以用作[RFC5640]中所述的负载平衡密钥。为此，中间路由器需要在用作负载平衡密钥的上下文中理解这些字段。
Most existing routers in IP networks are already capable of distributing IP traffic "microflows" [RFC2474] over ECMPs and/or LAG based on the hash of the five-tuple of UDP [RFC768] and TCP packets (i.e., source IP address, destination IP address, source port, destination port, and protocol). By encapsulating the MPLS packets into a UDP tunnel and using the source port of the UDP header as an entropy field, the existing load-balancing capability as mentioned above can be leveraged to provide fine-grained load balancing of MPLS traffic over IP networks.
IP网络中的大多数现有路由器已经能够基于UDP[RFC768]和TCP数据包（即源IP地址、目标IP地址、源端口、目标端口和协议）的五元组散列，通过ECMPs和/或LAG分布IP流量“微流”[RFC2474]。通过将MPLS数据包封装到UDP隧道中，并使用UDP报头的源端口作为熵字段，可以利用上述现有的负载平衡功能来提供IP网络上MPLS流量的细粒度负载平衡。
The MPLS-in-UDP encapsulation technology MUST only be deployed within a single network (with a single network operator) or networks of an adjacent set of cooperating network operators where traffic is managed to avoid congestion, rather than over the Internet where congestion control is required. Furthermore, packet filters SHOULD be added to prevent MPLS-in-UDP packets from escaping from the network due to misconfiguration or packet errors.
UDP封装技术中的MPLS必须仅部署在单个网络（具有单个网络运营商）或相邻一组合作网络运营商的网络中，在这些网络中管理流量以避免拥塞，而不是部署在需要拥塞控制的Internet上。此外，应添加数据包过滤器，以防止UDP数据包中的MPLS由于配置错误或数据包错误而从网络中逃逸。
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 RFC 2119 [RFC2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC2119]中所述进行解释。
MPLS-in-UDP encapsulation format is shown as follows:
UDP封装格式的MPLS如下所示：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy | Dest Port = MPLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MPLS Label Stack ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Port = Entropy | Dest Port = MPLS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| UDP Length | UDP Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
~ MPLS Label Stack ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| |
~ Message Body ~
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source Port of UDP
UDP的源端口
This field contains a 16-bit entropy value that is generated by the encapsulator to uniquely identify a flow. What constitutes a flow is locally determined by the encapsulator and therefore is outside the scope of this document. What algorithm is actually used by the encapsulator to generate an entropy value is outside the scope of this document.
此字段包含由封装器生成的16位熵值，用于唯一标识流。构成流的内容由封装器在本地确定，因此不在本文档的范围内。封装器实际使用什么算法来生成熵值超出了本文的范围。
In case the tunnel does not need entropy, this field of all packets belonging to a given flow SHOULD be set to a randomly selected constant value so as to avoid packet reordering.
在隧道不需要熵的情况下，属于给定流的所有分组的该字段应设置为随机选择的常量值，以避免分组重新排序。
To ensure that the source port number is always in the range 49152 to 65535 (note that those ports less than 49152 are reserved by IANA to identify specific applications/protocols), which may be required in some cases, instead of calculating a 16-bit hash, the encapsulator SHOULD calculate a 14-bit hash and use those 14 bits as the least significant bits of the source port field. Also, the most significant two bits SHOULD be set to binary 11. That still conveys 14 bits of entropy information, which would be enough in practice.
为确保源端口号始终在49152到65535之间（注意，IANA保留了那些小于49152的端口，以识别特定的应用程序/协议），这在某些情况下可能是必需的，而不是计算16位哈希，封装器应该计算一个14位散列，并使用这14位作为源端口字段的最低有效位。此外，最高有效的两位应设置为二进制11。这仍然传递了14位的熵信息，这在实践中已经足够了。
Destination Port of UDP
UDP的目标端口
This field is set to a value (6635) allocated by IANA to indicate that the UDP tunnel payload is an MPLS packet.
此字段设置为IANA分配的值（6635），以指示UDP隧道有效负载是MPLS数据包。
UDP Length
UDP长度
The usage of this field is in accordance with the current UDP specification [RFC768].
此字段的使用符合当前UDP规范[RFC768]。
UDP Checksum
UDP校验和
For IPv4 UDP encapsulation, this field is RECOMMENDED to be set to zero for performance or implementation reasons because the IPv4 header includes a checksum and use of the UDP checksum is optional with IPv4, unless checksum protection of VPN labels is important (see Section 6). For IPv6 UDP encapsulation, the IPv6 header does not include a checksum, so this field MUST contain a UDP checksum that MUST be used as specified in [RFC768] and [RFC2460] unless one of the exceptions that allows use of UDP zero-checksum mode (as specified in [RFC6935]) applies. See Section 3.1 for specification of these exceptions and additional requirements that apply when UDP zero-checksum mode is used for MPLS-in-UDP traffic over IPv6.
对于IPv4 UDP封装，出于性能或实施原因，建议将此字段设置为零，因为IPv4报头包含校验和，并且在IPv4中使用UDP校验和是可选的，除非VPN标签的校验和保护很重要（请参阅第6节）。对于IPv6 UDP封装，IPv6标头不包含校验和，因此此字段必须包含必须按照[RFC768]和[RFC2460]中的规定使用的UDP校验和，除非允许使用UDP零校验和模式的异常之一（按照[RFC6935]中的规定）适用。请参阅第3.1节，了解在IPv6上的UDP流量中对MPLS使用UDP零校验和模式时适用的这些例外和附加要求的规范。
MPLS Label Stack
标签栈
This field contains an MPLS Label Stack as defined in [RFC3032].
此字段包含[RFC3032]中定义的MPLS标签堆栈。
Message Body
消息体
This field contains one MPLS message body.
此字段包含一个MPLS消息正文。
When UDP is used over IPv6, the UDP checksum is relied upon to protect both the IPv6 and UDP headers from corruption and MUST be used unless the requirements in [RFC6935] and [RFC6936] for use of UDP zero-checksum mode with a tunnel protocol are satisfied. MPLS-in-UDP is a tunnel protocol, and there is significant successful deployment of MPLS-in-IPv6 without UDP (i.e., without a checksum that covers the IPv6 header or the MPLS label stack), as described in Section 3.1 of [RFC6936]:
在IPv6上使用UDP时，UDP校验和可用于保护IPv6和UDP报头不受损坏，并且必须使用UDP校验和，除非[RFC6935]和[RFC6936]中关于在隧道协议中使用UDP零校验和模式的要求得到满足。UDP中的MPLS是一种隧道协议，如[RFC6936]第3.1节所述，在没有UDP的情况下（即没有覆盖IPv6报头或MPLS标签堆栈的校验和），成功部署了MPLS-in-IPv6：
There is extensive experience with deployments using tunnel protocols in well-managed networks (e.g., corporate networks and service provider core networks). This has shown the robustness of methods such as Pseudowire Emulation Edge-to-Edge (PWE3) and MPLS that do not employ a transport protocol checksum and that have not specified mechanisms to protect from corruption of the unprotected headers (such as the VPN Identifier in MPLS).
在管理良好的网络（如公司网络和服务提供商核心网络）中使用隧道协议进行部署方面有着丰富的经验。这表明了伪线仿真边到边（PWE3）和MPLS等方法的健壮性，这些方法不采用传输协议校验和，也没有指定机制来防止未受保护的报头（如MPLS中的VPN标识符）损坏。
The UDP checksum MUST be implemented and MUST be used in accordance with [RFC768] and [RFC2460] for MPLS-in-UDP traffic over IPv6 unless one or more of the following exceptions applies and the additional requirements stated below are complied with. There are three exceptions that allow use of UDP zero-checksum mode for IPv6 with MPLS-in-UDP, subject to the additional requirements stated below in this section. The three exceptions are:
UDP校验和必须按照[RFC768]和[RFC2460]在IPv6上的UDP通信中用于MPLS，除非以下一个或多个例外适用，并且符合以下附加要求。有三种例外情况允许在UDP中使用MPLS的IPv6的UDP零校验和模式，这取决于本节下面所述的附加要求。这三个例外是：
a. Use of MPLS-in-UDP in networks under single administrative control (such as within a single operator's network) where it is known (perhaps through knowledge of equipment types and lower-layer checks) that packet corruption is exceptionally unlikely and where the operator is willing to take the risk of undetected packet corruption.
a. 在单一管理控制下的网络（例如在单一运营商的网络内）中使用UDP中的MPLS，其中已知（可能通过了解设备类型和较低层检查）数据包损坏的可能性极低，并且运营商愿意承担未检测到的数据包损坏的风险。
b. Use of MPLS-in-UDP in networks under single administrative control (such as within a single operator's network) where it is judged through observational measurements (perhaps of historic or current traffic flows that use a non-zero checksum) that the level of packet corruption is tolerably low and where the operator is willing to take the risk of undetected packet corruption.
b. 在受单一管理控制的网络中（例如在单一运营商的网络中）使用UDP中的MPLS，通过观察测量（可能是使用非零校验和的历史或当前流量）进行判断数据包损坏的程度相当低，并且操作员愿意承担未检测到的数据包损坏的风险。
c. Use of MPLS-in-UDP for traffic delivery for applications that are tolerant of misdelivered or corrupted packets (perhaps through higher-layer checksum, validation, and retransmission or transmission redundancy) where the operator is willing to rely on the applications using the tunnel to survive any corrupt packets.
c. 在UDP中使用MPLS进行流量交付，用于容忍错误交付或损坏数据包的应用程序（可能通过更高层的校验和、验证和重传或传输冗余），其中运营商愿意依赖使用隧道的应用程序来生存任何损坏数据包。
These exceptions may also be extended to the use of MPLS-in-UDP within a set of closely cooperating network administrations (such as network operators who have agreed to work together in order to jointly provide specific services). Even when one of the above exceptions applies, use of UDP checksums may be appropriate when VPN services are provided over MPLS-in-UDP; see Section 6.
这些例外情况也可以扩展到在一组密切合作的网络管理机构（如同意合作以共同提供特定服务的网络运营商）内UDP中使用MPLS。即使当上述例外情况之一适用时，在UDP中通过MPLS提供VPN服务时，使用UDP校验和也是合适的；见第6节。
As such, for IPv6, the UDP checksum for MPLS-in-UDP MUST be used as specified in [RFC768] and [RFC2460] for tunnels that span multiple networks whose network administrations do not cooperate closely, even if each non-cooperating network administration independently satisfies one or more of the exceptions for UDP zero-checksum mode usage with MPLS-in-UDP over IPv6.
因此，对于IPv6，UDP中MPLS的UDP校验和必须按照[RFC768]和[RFC2460]中的规定，用于跨多个网络且网络管理不密切合作的隧道，即使每个不合作的网络管理独立地满足UDP零校验和模式使用的一个或多个例外情况，以及IPv6上UDP中的MPLS。
The following additional requirements apply to implementation and use of UDP zero-checksum mode for MPLS-in-UDP over IPv6:
以下附加要求适用于IPv6上UDP中MPLS的UDP零校验和模式的实现和使用：
a. Use of the UDP checksum with IPv6 MUST be the default configuration of all MPLS-in-UDP implementations.
a. 在IPv6中使用UDP校验和必须是UDP实现中所有MPL的默认配置。
b. The MPLS-in-UDP implementation MUST comply with all requirements specified in Section 4 of [RFC6936] and with requirement 1 specified in Section 5 of [RFC6936].
b. UDP实现中的MPLS必须符合[RFC6936]第4节规定的所有要求和[RFC6936]第5节规定的要求1。
c. The tunnel decapsulator SHOULD only allow the use of UDP zero-checksum mode for IPv6 on a single received UDP Destination Port regardless of the encapsulator. The motivation for this requirement is possible corruption of the UDP Destination Port, which may cause packet delivery to the wrong UDP port. If that other UDP port requires the UDP checksum, the misdelivered packet will be discarded
c. 隧道解封装器应仅允许在单个接收到的UDP目标端口上对IPv6使用UDP零校验和模式，而不考虑封装器。此要求的动机是UDP目标端口可能损坏，这可能导致数据包传递到错误的UDP端口。如果另一个UDP端口需要UDP校验和，则错误传递的数据包将被丢弃
d. The tunnel decapsulator MUST check that the source and destination IPv6 addresses are valid for the MPLS-in-UDP tunnel on which the packet was received if that tunnel uses UDP zero-checksum mode and discard any packet for which this check fails.
d. 如果UDP隧道使用UDP零校验和模式，则隧道解封装器必须检查源和目标IPv6地址是否对接收数据包的UDP隧道中的MPLS有效，并丢弃此检查失败的任何数据包。
e. The tunnel encapsulator SHOULD use different IPv6 addresses for each MPLS-in-UDP tunnel that uses UDP zero-checksum mode (regardless of decapsulator) in order to strengthen the decapsulator's check of the IPv6 source address (i.e., the same IPv6 source address SHOULD NOT be used with more than one IPv6 destination address, independent of whether that destination address is a unicast or multicast address). When this is not possible, it is RECOMMENDED to use each source IPv6 address for as few UDP zero-checksum mode MPLS-in-UDP tunnels (i.e., with as few destination IPv6 addresses) as is feasible.
e. 在使用UDP零校验和模式的UDP隧道中，隧道封装器应为每个MPLS使用不同的IPv6地址（无论解封装器如何），以加强解封装器对IPv6源地址的检查（即，同一IPv6源地址不应与多个IPv6目标地址一起使用，这与该目标地址是单播地址还是多播地址无关）。如果不可能，则建议在UDP隧道中使用每个源IPv6地址，以获得最少的UDP零校验和模式MPL（即，目标IPv6地址尽可能少）。
f. Any middlebox support for MPLS-in-UDP with UDP zero-checksum mode for IPv6 MUST comply with requirements 1 and 8-10 in Section 5 of [RFC6936].
f. 在IPv6的UDP零校验和模式下，对MPLS的任何中间盒支持必须符合[RFC6936]第5节中的要求1和8-10。
g. Measures SHOULD be taken to prevent IPv6 traffic with zero UDP checksums from "escaping" to the general Internet; see Section 5 for examples of such measures.
g. 应采取措施防止UDP校验和为零的IPv6流量“逃逸”到通用互联网；有关此类措施的示例，请参见第5节。
h. IPv6 traffic with zero UDP checksums MUST be actively monitored for errors by the network operator.
h. 网络运营商必须主动监控UDP校验和为零的IPv6流量是否存在错误。
The above requirements do not change either the requirements specified in [RFC2460] as modified by [RFC6935] or the requirements specified in [RFC6936].
上述要求不改变[RFC6935]修改的[RFC2460]中规定的要求或[RFC6936]中规定的要求。
The requirement to check the source IPv6 address in addition to the destination IPv6 address, plus the strong recommendation against reuse of source IPv6 addresses among MPLS-in-UDP tunnels collectively provide some mitigation for the absence of UDP checksum coverage of the IPv6 header. In addition, the MPLS data plane only forwards
除了检查目标IPv6地址外，还需要检查源IPv6地址，加上强烈建议不要在UDP隧道中的MPL之间重用源IPv6地址，这些都为IPv6报头缺少UDP校验和覆盖提供了一些缓解措施。此外，MPLS数据平面仅转发
packets with valid labels (i.e., labels that have been distributed by the tunnel egress LSR), providing some additional opportunity to detect MPLS-in-UDP packet misdelivery when the misdelivered packet contains a label that is not valid for forwarding at the receiving LSR. The expected result for IPv6 UDP zero-checksum mode for MPLS-in-UDP is that corruption of the destination IPv6 address will usually cause packet discard, as offsetting corruptions to the source IPv6 and/or MPLS top label are unlikely. Additional assurance is provided by the restrictions in the above exceptions that limit usage of IPv6 UDP zero-checksum mode to well-managed networks for which MPLS packet corruption has not been a problem in practice.
具有有效标签的分组（即，已由隧道出口LSR分发的标签），当误发分组包含在接收LSR处无效转发的标签时，提供一些额外的机会来检测UDP分组误发中的mpl。UDP中MPLS的IPv6 UDP零校验和模式的预期结果是，目标IPv6地址的损坏通常会导致数据包丢弃，因为不太可能抵消对源IPv6和/或MPLS顶部标签的损坏。上述例外情况中的限制提供了额外的保证，这些限制将IPv6 UDP零校验和模式的使用限制在管理良好的网络上，对于这些网络，MPLS数据包损坏在实践中并不成问题。
Hence, MPLS-in-UDP is suitable for transmission over lower layers in the well-managed networks that are allowed by the exceptions stated above, and the rate of corruption of the inner IP packet on such networks is not expected to increase by comparison to MPLS traffic that is not encapsulated in UDP. For these reasons, MPLS-in-UDP does not provide an additional integrity check when UDP zero-checksum mode is used with IPv6, and this design is in accordance with requirements 2, 3, and 5 specified in Section 5 of [RFC6936].
因此，UDP中的MPLS适合在上述例外情况允许的管理良好的网络中的较低层上传输，并且与未封装在UDP中的MPLS通信量相比，此类网络上的内部IP数据包的损坏率预计不会增加。由于这些原因，当IPv6使用UDP零校验和模式时，UDP中的MPLS不提供额外的完整性检查，并且该设计符合[RFC6936]第5节中规定的要求2、3和5。
MPLS does not accumulate incorrect state as a consequence of label stack corruption. A corrupt MPLS label results in either packet discard or forwarding (and forgetting) of the packet without accumulation of MPLS protocol state. Active monitoring of MPLS-in-UDP traffic for errors is REQUIRED as occurrence of errors will result in some accumulation of error information outside the MPLS protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936].
MPLS does not accumulate incorrect state as a consequence of label stack corruption. A corrupt MPLS label results in either packet discard or forwarding (and forgetting) of the packet without accumulation of MPLS protocol state. Active monitoring of MPLS-in-UDP traffic for errors is REQUIRED as occurrence of errors will result in some accumulation of error information outside the MPLS protocol for operational and management purposes. This design is in accordance with requirement 4 specified in Section 5 of [RFC6936].translate error, please retry
The remaining requirements specified in Section 5 of [RFC6936] are inapplicable to MPLS-in-UDP. Requirements 6 and 7 do not apply because MPLS does not have an MPLS-generic control feedback mechanism. Requirements 8-10 are middlebox requirements that do not apply to MPLS-in-UDP tunnel endpoints, but see Section 3.2 for further middlebox discussion.
[RFC6936]第5节中规定的其余要求不适用于UDP中的MPLS。要求6和7不适用，因为MPLS没有MPLS通用控制反馈机制。要求8-10是不适用于UDP隧道端点中MPLS的中间箱要求，但有关进一步的中间箱讨论，请参见第3.2节。
In summary, UDP zero-checksum mode for IPv6 is allowed to be used with MPLS-in-UDP when one of the three exceptions specified above applies, provided that the additional requirements specified in this section are complied with. Otherwise, the UDP checksum MUST be used for IPv6 as specified in [RFC768] and [RFC2460].
总之，如果符合本节规定的附加要求，当上述三种例外情况之一适用时，允许在UDP中使用IPv6的UDP零校验和模式与MPLS。否则，UDP校验和必须用于[RFC768]和[RFC2460]中指定的IPv6。
This entire section and its requirements apply only to use of UDP zero-checksum mode for IPv6; they can be avoided by using the UDP checksum as specified in [RFC768] and [RFC2460].
整个部分及其要求仅适用于IPv6的UDP零校验和模式的使用；可以通过使用[RFC768]和[RFC2460]中指定的UDP校验和来避免这些错误。
IPv6 datagrams with a zero UDP checksum will not be passed by any middlebox that validates the checksum based on [RFC2460] or that updates the UDP checksum field, such as NATs or firewalls. Changing this behavior would require such middleboxes to be updated to correctly handle datagrams with zero UDP checksums. The MPLS-in-UDP encapsulation does not provide a mechanism to safely fall back to using a checksum when a path change occurs redirecting a tunnel over a path that includes a middlebox that discards IPv6 datagrams with a zero UDP checksum. In this case, the MPLS-in-UDP tunnel will be black-holed by that middlebox. Recommended changes to allow firewalls, NATs, and other middleboxes to support use of an IPv6 zero UDP checksum are described in Section 5 of [RFC6936].
UDP校验和为零的IPv6数据报将不会通过任何基于[RFC2460]验证校验和或更新UDP校验和字段（如NAT或防火墙）的中间盒传递。更改此行为需要更新此类中间盒，以正确处理UDP校验和为零的数据报。UDP封装中的MPLS没有提供一种机制，在发生路径更改时安全地退回到使用校验和，在包含一个中间盒的路径上重定向隧道，该中间盒丢弃具有零UDP校验和的IPv6数据报。在这种情况下，UDP隧道中的MPLS将被该中间盒屏蔽。[RFC6936]第5节介绍了允许防火墙、NAT和其他中间盒支持使用IPv6零UDP校验和的建议更改。
This MPLS-in-UDP encapsulation causes MPLS packets to be forwarded through "UDP tunnels". When performing MPLS-in-UDP encapsulation by the encapsulator, the entropy value would be generated by the encapsulator and then be filled in the Source Port field of the UDP header. The Destination Port field is set to a value (6635) allocated by IANA to indicate that the UDP tunnel payload is an MPLS packet. As for whether the top label of the encapsulated MPLS packet is downstream-assigned or upstream-assigned, it is determined according to the following criteria, which are compatible with [RFC5332]:
UDP封装中的MPLS导致MPLS数据包通过“UDP隧道”转发。当封装器在UDP封装中执行MPLS时，熵值将由封装器生成，然后填入UDP报头的源端口字段。目标端口字段设置为IANA分配的值（6635），以指示UDP隧道有效负载是MPLS数据包。至于封装的MPLS分组的顶部标签是下行分配还是上行分配，根据以下标准确定，这些标准与[RFC5332]兼容：
a. If the tunnel destination IP address is a unicast address, the top label MUST be downstream-assigned;
a. 如果隧道目标IP地址是单播地址，则必须向下游分配顶部标签；
b. If the tunnel destination IP address is an IP multicast address, either all encapsulated MPLS packets in the particular tunnel have a downstream-assigned label at the top of the stack, or all encapsulated MPLS packets in that tunnel have an upstream-assigned label at the top of the stack. The means by which this is determined for a particular tunnel is outside the scope of this specification. In the absence of any knowledge about a specific tunnel, the label SHOULD be presumed to be upstream-assigned.
b. 如果隧道目标IP地址是IP多播地址，则特定隧道中的所有封装MPLS数据包在堆栈顶部具有下游分配的标签，或者该隧道中的所有封装MPLS数据包在堆栈顶部具有上游分配的标签。确定特定隧道的方法不在本规范范围内。在不了解特定隧道的情况下，应假定标签是上游指定的。
Intermediate routers, upon receiving these UDP encapsulated packets, could balance these packets based on the hash of the five-tuple of UDP packets. Upon receiving these UDP-encapsulated packets, the decapsulator would decapsulate them by removing the UDP headers and then process them accordingly. For other common processing procedures associated with tunneling encapsulation technologies including but not limited to Maximum Transmission Unit (MTU) and
中间路由器在接收到这些UDP封装的数据包后，可以基于UDP数据包的五个元组的散列来平衡这些数据包。在接收到这些UDP封装的数据包后，解封装器将通过移除UDP头来解封装，然后相应地处理它们。与隧道封装技术相关的其他常见处理程序，包括但不限于最大传输单元（MTU）和
preventing fragmentation and reassembly, Time to Live (TTL), and differentiated services, the corresponding "Common Procedures" defined in [RFC4023], which are applicable for MPLS-in-IP and MPLS-in-GRE encapsulation formats SHOULD be followed.
应遵循[RFC4023]中定义的适用于IP MPLS和GRE封装格式MPLS的相应“通用程序”，以防止碎片和重组、生存时间（TTL）和区分服务。
Note: Each UDP tunnel is unidirectional, as MPLS-in-UDP traffic is sent to the IANA-allocated UDP Destination Port, and in particular, is never sent back to any port used as a UDP Source Port (which serves solely as a source of entropy). This is at odds with a typical middlebox (e.g., firewall) assumption that bidirectional traffic uses a common pair of UDP ports. As a result, arranging to pass bidirectional MPLS-in-UDP traffic through middleboxes may require separate configuration for each direction of traffic.
注意：每个UDP隧道都是单向的，因为UDP通信中的MPLS被发送到IANA分配的UDP目标端口，特别是，不会被发送回任何用作UDP源端口（仅用作熵源）的端口。这与典型的中间包（如防火墙）假设的情况不一致，即双向通信使用一对公用的UDP端口。因此，安排UDP流量中的双向MPL通过中间盒可能需要对每个流量方向进行单独配置。
Section 3.1.3 of [RFC5405] discussed the congestion implications of UDP tunnels. As discussed in [RFC5405], because other flows can share the path with one or more UDP tunnels, congestion control [RFC2914] needs to be considered.
[RFC5405]第3.1.3节讨论了UDP隧道的拥塞影响。如[RFC5405]中所述，由于其他流可以与一个或多个UDP隧道共享路径，因此需要考虑拥塞控制[RFC2914]。
A major motivation for encapsulating MPLS in UDP is to improve the use of multipath (such as ECMP) in cases where traffic is to traverse routers that are able to hash on UDP Port and IP address. As such, in many cases this may reduce the occurrence of congestion and improve usage of available network capacity. However, it is also necessary to ensure that the network, including applications that use the network, responds appropriately in more difficult cases, such as when link or equipment failures have reduced the available capacity.
在UDP中封装MPLS的一个主要动机是，在流量要通过能够在UDP端口和IP地址上散列的路由器的情况下，改进多路径（如ECMP）的使用。因此，在许多情况下，这可以减少拥塞的发生并提高可用网络容量的利用率。然而，还必须确保网络，包括使用网络的应用程序，在更困难的情况下，例如当链路或设备故障降低了可用容量时，做出适当的响应。
The impact of congestion must be considered both in terms of the effect on the rest of the network of a UDP tunnel that is consuming excessive capacity, and in terms of the effect on the flows using the UDP tunnels. The potential impact of congestion from a UDP tunnel depends upon what sort of traffic is carried over the tunnel, as well as the path of the tunnel.
拥塞的影响必须考虑到对消耗过多容量的UDP隧道的网络其余部分的影响，以及对使用UDP隧道的流的影响。UDP隧道拥塞的潜在影响取决于通过隧道的流量类型以及隧道的路径。
MPLS is widely used to carry an extensive range of traffic. In many cases, MPLS is used to carry IP traffic. IP traffic is generally assumed to be congestion controlled, and thus a tunnel carrying general IP traffic (as might be expected to be carried across the Internet) generally does not need additional congestion control mechanisms. As specified in [RFC5405]:
MPLS被广泛用于承载范围广泛的业务。在许多情况下，MPLS用于承载IP流量。IP流量通常被认为是拥塞控制的，因此，承载一般IP流量的隧道（如预期通过互联网承载的）通常不需要额外的拥塞控制机制。按照[RFC5405]中的规定：
IP-based traffic is generally assumed to be congestion-controlled, i.e., it is assumed that the transport protocols generating IP-based traffic at the sender already employ mechanisms that are sufficient to address congestion on the path. Consequently, a tunnel carrying IP-based traffic should already interact appropriately with other traffic sharing the path, and specific congestion control mechanisms for the tunnel are not necessary.
基于IP的流量通常被假定为拥塞控制，即，假定在发送方处生成基于IP的流量的传输协议已经采用足以解决路径上的拥塞的机制。因此，承载基于IP的流量的隧道应该已经与共享该路径的其他流量进行适当的交互，并且不需要针对该隧道的特定拥塞控制机制。
For this reason, where MPLS-in-UDP tunneling is used to carry IP traffic that is known to be congestion controlled, the UDP tunnels MAY be used within a single network or across multiple networks, with cooperating network operators. Internet IP traffic is generally assumed to be congestion controlled. Similarly, in general, Layer 3 VPNs are carrying IP traffic that is similarly assumed to be congestion controlled.
因此，在UDP隧道中的MPLS用于承载已知为拥塞控制的IP流量的情况下，UDP隧道可以在单个网络内使用，也可以与合作的网络运营商跨多个网络使用。Internet IP流量通常被认为是拥塞控制的。类似地，通常情况下，第3层VPN承载的IP流量同样被认为是拥塞控制的。
Whether or not Layer 2 VPN traffic is congestion controlled may depend upon the specific services being offered and what use is being made of the Layer 2 services.
第2层VPN流量是否受到拥塞控制可能取决于提供的特定服务以及第2层服务的用途。
However, MPLS is also used in many cases to carry traffic that is not necessarily congestion controlled. For example, MPLS may be used to carry pseudowire or VPN traffic where specific bandwidth guarantees are provided to each pseudowire or to each VPN.
然而，MPLS在许多情况下也用于承载不一定是拥塞控制的流量。例如，MPLS可用于承载伪线或VPN流量，其中向每个伪线或每个VPN提供特定带宽保证。
In such cases, network operators may avoid congestion by careful provisioning of their networks, by rate limiting of user data traffic, and/or by using MPLS Traffic Engineering (MPLS-TE) to assign specific bandwidth guarantees to each LSP. Where MPLS is carried over UDP over IP, the identity of each individual MPLS flow is lost, in general, and MPLS-TE cannot be used to guarantee bandwidth to specific flows (since many LSPs may be multiplexed over a single UDP tunnel, and many UDP tunnels may be mixed in an IP network).
在这种情况下，网络运营商可以通过谨慎地提供其网络、通过限制用户数据流量和/或通过使用MPLS流量工程（MPLS-TE）为每个LSP分配特定的带宽保证来避免拥塞。在通过IP UDP传输MPLS的情况下，通常每个单个MPLS流的标识都会丢失，并且MPLS-TE不能用于保证特定流的带宽（因为许多LSP可以通过单个UDP隧道进行多路复用，并且许多UDP隧道可以混合在IP网络中）。
For this reason, where the MPLS traffic is not congestion controlled, MPLS-in-UDP tunnels MUST only be used within a single operator's network that utilizes careful provisioning (e.g., rate limiting at the entries of the network while over-provisioning network capacity) to ensure against congestion, or within a limited number of networks whose operators closely cooperate in order to jointly provide this same careful provisioning.
因此，在MPLS流量不受拥塞控制的情况下，UDP隧道中的MPLS只能在单个运营商的网络中使用，该运营商的网络利用谨慎的资源调配（例如，在过度调配网络容量的情况下限制网络入口的速率），以确保避免拥塞，或者在有限数量的网络中，运营商密切合作，共同提供同样的谨慎供应。
As such, MPLS-in-UDP MUST NOT be used over the general Internet, or over non-cooperating network operators, to carry traffic that is not congestion controlled.
因此，UDP中的MPLS不得在通用Internet上或非合作网络运营商上使用，以承载不受拥塞控制的流量。
Measures SHOULD be taken to prevent non-congestion-controlled MPLS-in-UDP traffic from "escaping" to the general Internet, e.g.:
应采取措施防止UDP流量中的非拥塞控制MPLS“逃逸”到通用互联网，例如：
a. Physical or logical isolation of the links carrying MPLS-over-UDP from the general Internet.
a. 通过UDP传输MPLS的链路与通用Internet的物理或逻辑隔离。
b. Deployment of packet filters that block the UDP Destination Ports used for MPLS-over-UDP.
b. 部署数据包筛选器，阻止UDP上MPLS使用的UDP目标端口。
c. Imposition of restrictions on MPLS-in-UDP traffic by software tools used to set up MPLS-in-UDP tunnels between specific end systems (as might be used within a single data center).
c. 通过软件工具对UDP通信中的MPLS施加限制，该软件工具用于在特定终端系统之间的UDP隧道中设置MPLS（可能在单个数据中心内使用）。
d. Use of a "Managed Circuit Breaker" for the MPLS traffic as described in [CIRCUIT-BREAKER].
d. 如[断路器]中所述，对MPLS流量使用“受管断路器”。
The security problems faced with the MPLS-in-UDP tunnel are exactly the same as those faced with MPLS-in-IP and MPLS-in-GRE tunnels [RFC4023]. In other words, the MPLS-in-UDP tunnel as defined in this document by itself cannot ensure the integrity and privacy of data packets being transported through the MPLS-in-UDP tunnel and cannot enable the tunnel decapsulator to authenticate the tunnel encapsulator. In the case where any of the above security issues is concerned, the MPLS-in-UDP tunnel SHOULD be secured with IPsec or DTLS. IPsec was designed as a network security mechanism, and therefore it resides at the network layer. As such, if the tunnel is secured with IPsec, the UDP header would not be visible to intermediate routers anymore in either IPsec tunnel or transport mode. As a result, the meaning of adopting the MPLS-in-UDP tunnel as an alternative to the MPLS-in-GRE or MPLS-in-IP tunnel is lost. By comparison, DTLS is better suited for application security and can better preserve network- and transport-layer protocol information. Specifically, if DTLS is used, the destination port of the UDP header MUST be set to an IANA-assigned value (6636) indicating MPLS-in-UDP with DTLS, and that UDP port MUST NOT be used for other traffic. The UDP source port field can still be used to add entropy, e.g., for load-sharing purposes. DTLS usage is limited to a single DTLS session for any specific tunnel encapsulator/decapsulator pair (identified by source and destination IP addresses). Both IP addresses MUST be unicast addresses -- multicast traffic is not supported when DTLS is used. An MPLS-in-UDP tunnel decapsulator implementation that supports DTLS is expected to be able to establish DTLS sessions with multiple tunnel encapsulators. Likewise, an MPLS-in-UDP tunnel encapsulator implementation is expected to be able to establish DTLS sessions with multiple decapsulators. (However,
UDP隧道中MPLS面临的安全问题与IP中MPLS和GRE隧道中MPLS面临的安全问题完全相同[RFC4023]。换句话说，本文档中定义的UDP隧道中的MPLS本身无法确保通过UDP隧道中的MPLS传输的数据包的完整性和隐私性，也无法使隧道解封装器对隧道封装器进行身份验证。在涉及上述任何安全问题的情况下，UDP隧道中的MPLS应使用IPsec或DTLS进行保护。IPsec被设计为一种网络安全机制，因此它驻留在网络层。因此，如果隧道由IPsec保护，则在IPsec隧道或传输模式下，中间路由器将无法再看到UDP头。因此，在UDP隧道中采用MPLS作为GRE中MPLS或IP隧道中MPLS的替代方案的意义就失去了。相比之下，DTLS更适合于应用程序安全，并且可以更好地保存网络和传输层协议信息。具体地说，如果使用DTLS，则UDP报头的目标端口必须设置为IANA分配的值（6636），指示使用DTLS的UDP中的MPLS，并且该UDP端口不得用于其他流量。UDP源端口字段仍然可以用于添加熵，例如用于负载共享目的。DTLS的使用仅限于任何特定隧道封装器/解封装器对（由源和目标IP地址标识）的单个DTLS会话。两个IP地址都必须是单播地址——使用DTLS时不支持多播通信。支持DTLS的MPLS in-UDP隧道解封装器实现预计能够与多个隧道封装器建立DTLS会话。同样，MPLS-in-UDP隧道封装器实现预计能够与多个解封装器建立DTLS会话。（但是，
different source and/or destination IP addresses may be involved. See Section 3.1 for discussion of one situation where use of different source IP addresses is important.)
可能涉及不同的源和/或目标IP地址。有关使用不同源IP地址非常重要的一种情况的讨论，请参见第3.1节。）
If the tunnel is not secured with IPsec or DTLS, 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. 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-UDP validates the IP source address of the packet.
如果隧道未使用IPsec或DTL进行保护，则应使用其他一些方法来确保仅当这些数据包由隧道头进行封装时，数据包才由隧道尾进行解封和转发。如果隧道完全位于单个管理域内，则可以使用边界处的地址过滤来确保具有隧道端点的IP源地址或隧道端点的IP目标地址的数据包不能从外部进入域。然而，当隧道头和隧道尾不在同一管理域中时，这可能变得困难，并且如果包必须穿越公共因特网，则基于目的地地址的过滤甚至可能变得不可能。有时，在管理域的边界上只进行源地址筛选（而不进行目标地址筛选）。如果是这种情况，则过滤根本无法提供有效的保护，除非UDP中MPLS的解封装器验证数据包的IP源地址。
This document does not require that the decapsulator validate the IP source address of the tunneled packets (with the exception that the IPv6 source address MUST be validated when UDP zero-checksum mode is used with IPv6), but it should be understood that failure to do so presupposes that there is effective destination-based (or a combination of source-based and destination-based) filtering at the boundaries. MPLS-based VPN services rely on a VPN label in the MPLS label stack to identify the VPN. Corruption of that label could leak traffic across VPN boundaries. Such leakage is highly undesirable when inter-VPN isolation is used for privacy or security reasons. When that is the case, UDP checksums SHOULD be used for MPLS-in-UDP with both IPv4 and IPv6, and in particular, UDP zero-checksum mode SHOULD NOT be used with IPv6. Each UDP checksum covers the VPN label, thereby providing increased assurance of isolation among VPNs.
本文档不要求解封装器验证隧道数据包的IP源地址（当IPv6使用UDP零校验和模式时，必须验证IPv6源地址除外），但应理解，如果不验证，则前提是存在有效的基于目的地的数据包（或基于源和基于目标的组合）边界过滤。基于MPLS的VPN服务依赖于MPLS标签堆栈中的VPN标签来标识VPN。该标签的损坏可能会泄漏跨VPN边界的流量。当出于隐私或安全原因使用VPN间隔离时，这种泄漏是极不可取的。在这种情况下，应为MPLS-i使用UDP校验和IPv4和IPv6同时使用的n-UDP，尤其是UDP零校验和模式不应与IPv6一起使用。每个UDP校验和都覆盖VPN标签，从而提高了VPN之间隔离的保证。
One UDP destination port number indicating MPLS has been allocated by IANA:
一个UDP目标端口号，指示IANA已分配MPLS：
Service Name: MPLS-UDP
服务名称：MPLS-UDP
Transport Protocol(s): UDP
传输协议：UDP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>.
联系人：IETF主席<chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels.
描述：在UDP隧道中封装MPLS数据包。
Reference: RFC 7510
参考：RFC 7510
Port Number: 6635
端口号：6635
One UDP destination port number indicating MPLS with DTLS has been allocated by IANA:
IANA已分配一个UDP目标端口号，指示带有DTLS的MPLS：
Service Name: MPLS-UDP-DTLS
服务名称：MPLS-UDP-DTLS
Transport Protocol(s): UDP
传输协议：UDP
Assignee: IESG <iesg@ietf.org>
Assignee: IESG <iesg@ietf.org>
Contact: IETF Chair <chair@ietf.org>.
联系人：IETF主席<chair@ietf.org>.
Description: Encapsulate MPLS packets in UDP tunnels with DTLS.
描述：使用DTL在UDP隧道中封装MPLS数据包。
Reference: RFC 7510
参考：RFC 7510
Port Number: 6636
端口号：6636
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC3032] Rosen, E., Tappan, D., Fedorkow, G., Rekhter, Y., Farinacci, D., Li, T., and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001, <http://www.rfc-editor.org/info/rfc3032>.
[RFC3032]Rosen，E.，Tappan，D.，Fedorkow，G.，Rekhter，Y.，Farinaci，D.，Li，T.，和A.Conta，“MPLS标签堆栈编码”，RFC 3032，2001年1月<http://www.rfc-editor.org/info/rfc3032>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC5332] Eckert, T., Rosen, E., Ed., Aggarwal, R., and Y. Rekhter, "MPLS Multicast Encapsulations", RFC 5332, August 2008, <http://www.rfc-editor.org/info/rfc5332>.
[RFC5332]Eckert，T.，Rosen，E.，Ed.，Aggarwal，R.，和Y.Rekhter，“MPLS多播封装”，RFC 5332，2008年8月<http://www.rfc-editor.org/info/rfc5332>.
[RFC5405] Eggert, L. and G. Fairhurst, "Unicast UDP Usage Guidelines for Application Designers", BCP 145, RFC 5405, November 2008, <http://www.rfc-editor.org/info/rfc5405>.
[RFC5405]Eggert，L.和G.Fairhurst，“应用程序设计者的单播UDP使用指南”，BCP 145，RFC 5405，2008年11月<http://www.rfc-editor.org/info/rfc5405>.
[RFC6347] Rescorla, E. and N. Modadugu, "Datagram Transport Layer Security Version 1.2", RFC 6347, January 2012, <http://www.rfc-editor.org/info/rfc6347>.
[RFC6347]Rescorla，E.和N.Modadugu，“数据报传输层安全版本1.2”，RFC 6347，2012年1月<http://www.rfc-editor.org/info/rfc6347>.
[RFC6935] Eubanks, M., Chimento, P., and M. Westerlund, "IPv6 and UDP Checksums for Tunneled Packets", RFC 6935, April 2013, <http://www.rfc-editor.org/info/rfc6935>.
[RFC6935]Eubanks，M.，Chimento，P.和M.Westerlund，“隧道数据包的IPv6和UDP校验和”，RFC 69352013年4月<http://www.rfc-editor.org/info/rfc6935>.
[RFC6936] Fairhurst, G. and M. Westerlund, "Applicability Statement for the Use of IPv6 UDP Datagrams with Zero Checksums", RFC 6936, April 2013, <http://www.rfc-editor.org/info/rfc6936>.
[RFC6936]Fairhurst，G.和M.Westerlund，“使用具有零校验和的IPv6 UDP数据报的适用性声明”，RFC 69362013年4月<http://www.rfc-editor.org/info/rfc6936>.
[CIRCUIT-BREAKER] Fairhurst, G., "Network Transport Circuit Breakers", Work in Progress, draft-ietf-tsvwg-circuit-breaker-01, April 2015.
[CIRCUIT-BREAKER]Fairhurst，G.，“网络传输断路器”，正在进行的工作，草稿-ietf-tsvwg-CIRCUIT-BREAKER-01，2015年4月。
[RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998, <http://www.rfc-editor.org/info/rfc2474>.
[RFC2474]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 24741998年12月<http://www.rfc-editor.org/info/rfc2474>.
[RFC2914] Floyd, S., "Congestion Control Principles", BCP 41, RFC 2914, September 2000, <http://www.rfc-editor.org/info/rfc2914>.
[RFC2914]Floyd，S.，“拥塞控制原则”，BCP 41，RFC 2914，2000年9月<http://www.rfc-editor.org/info/rfc2914>.
[RFC4023] Worster, T., Rekhter, Y., and E. Rosen, Ed., "Encapsulating MPLS in IP or Generic Routing Encapsulation (GRE)", RFC 4023, March 2005, <http://www.rfc-editor.org/info/rfc4023>.
[RFC4023]Worster，T.，Rekhter，Y.，和E.Rosen，编辑，“在IP或通用路由封装（GRE）中封装MPLS”，RFC 4023，2005年3月<http://www.rfc-editor.org/info/rfc4023>.
[RFC4817] Townsley, M., Pignataro, C., Wainner, S., Seely, T., and J. Young, "Encapsulation of MPLS over Layer 2 Tunneling Protocol Version 3", RFC 4817, March 2007, <http://www.rfc-editor.org/info/rfc4817>.
[RFC4817]Townsley，M.，Pignataro，C.，Wainner，S.，Seely，T.，和J.Young，“第2层隧道协议版本3上的MPLS封装”，RFC 48172007年3月<http://www.rfc-editor.org/info/rfc4817>.
[RFC5640] Filsfils, C., Mohapatra, P., and C. Pignataro, "Load-Balancing for Mesh Softwires", RFC 5640, August 2009, <http://www.rfc-editor.org/info/rfc5640>.
[RFC5640]Filsfils，C.，Mohapatra，P.，和C.Pignataro，“网状软电线的负载平衡”，RFC 56402009年8月<http://www.rfc-editor.org/info/rfc5640>.
[RFC6438] Carpenter, B. and S. Amante, "Using the IPv6 Flow Label for Equal Cost Multipath Routing and Link Aggregation in Tunnels", RFC 6438, November 2011, <http://www.rfc-editor.org/info/rfc6438>.
[RFC6438]Carpenter，B.和S.Amante，“在隧道中使用IPv6流标签进行等成本多路径路由和链路聚合”，RFC 6438，2011年11月<http://www.rfc-editor.org/info/rfc6438>.
Acknowledgements
致谢
Thanks to Shane Amante, Dino Farinacci, Keshava A K, Ivan Pepelnjak, Eric Rosen, Andrew G. Malis, Kireeti Kompella, Marshall Eubanks, George Swallow, Loa Andersson, Vivek Kumar, Stewart Bryant, Wen Zhang, Joel M. Halpern, Noel Chiappa, Scott Brim, Alia Atlas, Alexander Vainshtein, Joel Jaeggli, Edward Crabbe, Mark Tinka, Lars Eggert, Joe Touch, Lloyd Wood, Gorry Fairhurst, Weiguo Hao, Mark Szczesniak, Stephen Farrell, Martin Stiemerling, Zhenxiao Liu, and Xing Tong for their valuable comments and suggestions on this document.
感谢Shane Amante、Dino Farinaci、Keshava A K、Ivan Pepelnjak、Eric Rosen、Andrew G.Malis、Kireeti Kompella、Marshall Eubanks、George Swallow、Loa Andersson、Vivek Kumar、Stewart Bryant、Wen Zhang、Joel M.Halpern、Noel Chiappa、Scott Brim、Alia Atlas、Alexander Vainstein、Joel Jaeggli、Edward Crabbe、Mark Tinka、Lars Eggert、Joe Touch、，劳埃德·伍德、戈里·费尔赫斯特、魏国豪、马克·斯泽斯尼亚克、斯蒂芬·法雷尔、马丁·斯蒂梅林、刘振晓和邢彤对本文件提出了宝贵的意见和建议。
Special thanks to Alia Atlas for her insightful suggestion of adding an applicability statement.
特别感谢Alia Atlas提出的添加适用性声明的深刻建议。
Thanks to Daniel King, Gregory Mirsky, and Eric Osborne for their valuable MPLS-RT reviews on this document. Thanks to Charlie Kaufman for his SecDir review of this document. Thanks to Nevil Brownlee for the OPS-Dir review of this document. Thanks to Roni Even for the Gen-ART review of this document. Thanks to Pearl Liang for the IANA review of this document.
感谢Daniel King、Gregory Mirsky和Eric Osborne对本文档的宝贵MPLS-RT评论。感谢Charlie Kaufman对本文件的SecDir审查。感谢Nevil Brownlee对本文件的OPS Dir审查。感谢Roni对本文档的Gen ART评论。感谢Pearl Liang对本文件的IANA审查。
Contributors
贡献者
Note that contributors are listed in alphabetical order according to their last names.
请注意，贡献者按姓氏的字母顺序列出。
Yongbing Fan China Telecom EMail: fanyb@gsta.com
范永兵中国电信邮箱：fanyb@gsta.com
Adrian Farrel Juniper Networks EMail: adrian@olddog.co.uk
Adrian Farrel Juniper Networks电子邮件：adrian@olddog.co.uk
Zhenbin Li Huawei Technologies EMail: lizhenbin@huawei.com
李振斌华为技术电子邮件：lizhenbin@huawei.com
Carlos Pignataro Cisco Systems EMail: cpignata@cisco.com
Carlos Pignataro Cisco Systems电子邮件：cpignata@cisco.com
Curtis Villamizar Outer Cape Cod Network Consulting, LLC EMail: curtis@occnc.com
Curtis Villamizar Outer Cape Cod Network Consulting，LLC电子邮件：curtis@occnc.com
Authors' Addresses
作者地址
Xiaohu Xu Huawei Technologies No.156 Beiqing Rd Beijing 100095 China
中国北京市北青路156号华为科技有限公司徐晓虎100095
Phone: +86-10-60610041
EMail: xuxiaohu@huawei.com
Phone: +86-10-60610041
EMail: xuxiaohu@huawei.com
Nischal Sheth Juniper Networks 1194 N. Mathilda Ave Sunnyvale, CA 94089 United States
Nischal Sheth Juniper Networks 1194 N.Mathilda Ave Sunnyvale，加利福尼亚州94089
EMail: nsheth@juniper.net
EMail: nsheth@juniper.net
Lucy Yong Huawei USA
美国华为公司
EMail: Lucy.yong@huawei.com
EMail: Lucy.yong@huawei.com
Ross Callon Juniper Networks
Ross Callon Juniper网络
EMail: rcallon@juniper.net
EMail: rcallon@juniper.net
David Black EMC Corporation 176 South Street Hopkinton, MA 01748 United States
David Black EMC Corporation美国马萨诸塞州霍普金顿南街176号01748
EMail: david.black@emc.com
EMail: david.black@emc.com