Network Working Group V. Gill
Request for Comments: 5082 J. Heasley
Obsoletes: 3682 D. Meyer
Category: Standards Track P. Savola, Ed.
C. Pignataro
October 2007
Network Working Group V. Gill
Request for Comments: 5082 J. Heasley
Obsoletes: 3682 D. Meyer
Category: Standards Track P. Savola, Ed.
C. Pignataro
October 2007
The Generalized TTL Security Mechanism (GTSM)
广义TTL安全机制（GTSM）
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）。本备忘录的分发不受限制。
Abstract
摘要
The use of a packet's Time to Live (TTL) (IPv4) or Hop Limit (IPv6) to verify whether the packet was originated by an adjacent node on a connected link has been used in many recent protocols. This document generalizes this technique. This document obsoletes Experimental RFC 3682.
使用数据包的生存时间（TTL）（IPv4）或跃点限制（IPv6）来验证数据包是否是由连接链路上的相邻节点发起的已在许多最近的协议中使用。本文档概括了这种技术。本文件淘汰了实验性RFC 3682。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3
2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7
5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8
5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9
5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11
5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 3682 . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Assumptions Underlying GTSM . . . . . . . . . . . . . . . . . 3
2.1. GTSM Negotiation . . . . . . . . . . . . . . . . . . . . . 4
2.2. Assumptions on Attack Sophistication . . . . . . . . . . . 4
3. GTSM Procedure . . . . . . . . . . . . . . . . . . . . . . . . 5
4. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 6
5. Security Considerations . . . . . . . . . . . . . . . . . . . 6
5.1. TTL (Hop Limit) Spoofing . . . . . . . . . . . . . . . . . 7
5.2. Tunneled Packets . . . . . . . . . . . . . . . . . . . . . 7
5.2.1. IP Tunneled over IP . . . . . . . . . . . . . . . . . 8
5.2.2. IP Tunneled over MPLS . . . . . . . . . . . . . . . . 9
5.3. Onlink Attackers . . . . . . . . . . . . . . . . . . . . . 11
5.4. Fragmentation Considerations . . . . . . . . . . . . . . . 11
5.5. Multi-Hop Protocol Sessions . . . . . . . . . . . . . . . 12
6. Applicability Statement . . . . . . . . . . . . . . . . . . . 12
6.1. Backwards Compatibility . . . . . . . . . . . . . . . . . 12
7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
7.1. Normative References . . . . . . . . . . . . . . . . . . . 13
7.2. Informative References . . . . . . . . . . . . . . . . . . 14
Appendix A. Multi-Hop GTSM . . . . . . . . . . . . . . . . . . . 15
Appendix B. Changes Since RFC 3682 . . . . . . . . . . . . . . . 15
The Generalized TTL Security Mechanism (GTSM) is designed to protect a router's IP-based control plane from CPU-utilization based attacks. In particular, while cryptographic techniques can protect the router-based infrastructure (e.g., BGP [RFC4271], [RFC4272]) from a wide variety of attacks, many attacks based on CPU overload can be prevented by the simple mechanism described in this document. Note that the same technique protects against other scarce-resource attacks involving a router's CPU, such as attacks against processor-line card bandwidth.
广义TTL安全机制（GTSM）旨在保护路由器基于IP的控制平面免受基于CPU利用率的攻击。特别是，尽管密码技术可以保护基于路由器的基础设施（例如，BGP[RFC4271]、[RFC4272]）免受各种攻击，但许多基于CPU过载的攻击可以通过本文档中描述的简单机制来防止。请注意，相同的技术可以防止涉及路由器CPU的其他稀缺资源攻击，例如针对处理器线路卡带宽的攻击。
GTSM is based on the fact that the vast majority of protocol peerings are established between routers that are adjacent. Thus, most protocol peerings are either directly between connected interfaces or, in the worst case, are between loopback and loopback, with static routes to loopbacks. Since TTL spoofing is considered nearly impossible, a mechanism based on an expected TTL value can provide a simple and reasonably robust defense from infrastructure attacks based on forged protocol packets from outside the network. Note, however, that GTSM is not a substitute for authentication mechanisms. In particular, it does not secure against insider on-the-wire attacks, such as packet spoofing or replay.
GTSM基于这样一个事实，即绝大多数协议对等是在相邻路由器之间建立的。因此，大多数协议对等要么直接在连接的接口之间，要么在最坏的情况下在环回和环回之间，通过静态路由到环回。由于TTL欺骗被认为几乎是不可能的，因此基于预期TTL值的机制可以提供一种简单而合理的健壮防御，以抵御基于来自网络外部的伪造协议包的基础设施攻击。但是，请注意，GTSM不能替代身份验证机制。特别是，它不能防止内部在线攻击，如数据包欺骗或重播。
Finally, the GTSM mechanism is equally applicable to both TTL (IPv4) and Hop Limit (IPv6), and from the perspective of GTSM, TTL and Hop Limit have identical semantics. As a result, in the remainder of this document the term "TTL" is used to refer to both TTL or Hop Limit (as appropriate).
最后，GTSM机制同样适用于TTL（IPv4）和跃点限制（IPv6），并且从GTSM的角度来看，TTL和跃点限制具有相同的语义。因此，在本文件的其余部分中，术语“TTL”用于指TTL或跃点限制（视情况而定）。
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]中所述进行解释。
GTSM is predicated upon the following assumptions:
GTSM基于以下假设：
1. The vast majority of protocol peerings are between adjacent routers.
1. 绝大多数协议对等是在相邻路由器之间进行的。
2. Service providers may or may not configure strict ingress filtering [RFC3704] on non-trusted links. If maximal protection is desired, such filtering is necessary as described in Section 2.2.
2. 服务提供商可能会也可能不会在不受信任的链路上配置严格的入口过滤[RFC3704]。如果需要最大程度的保护，则有必要进行第2.2节所述的过滤。
3. Use of GTSM is OPTIONAL, and can be configured on a per-peer (group) basis.
3. GTSM的使用是可选的，可以在每个对等（组）的基础上进行配置。
4. The peer routers both implement GTSM.
4. 对等路由器都实现GTSM。
5. The router supports a method to use separate resource pools (e.g., queues, processing quotas) for differently classified traffic.
5. 路由器支持为不同分类的流量使用单独的资源池（例如，队列、处理配额）的方法。
Note that this document does not prescribe further restrictions that a router may apply to packets not matching the GTSM filtering rules, such as dropping packets that do not match any configured protocol session and rate-limiting the rest. This document also does not suggest the actual means of resource separation, as those are hardware and implementation-specific.
注意，本文档没有规定路由器可应用于不匹配GTSM过滤规则的数据包的进一步限制，例如丢弃不匹配任何已配置协议会话的数据包以及对其余数据包进行速率限制。本文档也没有建议实际的资源分离方法，因为这些方法是硬件和实现特定的。
However, the possibility of denial-of-service (DoS) attack prevention is based on the assumption that classification of packets and separation of their paths are done before the packets go through a scarce resource in the system. In practice, the closer GTSM processing is done to the line-rate hardware, the more resistant the system is to DoS attacks.
然而，拒绝服务（DoS）攻击预防的可能性是基于这样的假设：在数据包通过系统中的稀缺资源之前，对数据包进行分类并分离其路径。实际上，GTSM处理越接近线路速率硬件，系统就越能抵抗DoS攻击。
This document assumes that, when used with existing protocols, GTSM will be manually configured between protocol peers. That is, no automatic GTSM capability negotiation, such as is provided by RFC 3392 [RFC3392], is assumed or defined.
本文档假设，当与现有协议一起使用时，GTSM将在协议对等方之间手动配置。也就是说，未假设或定义RFC 3392[RFC3392]提供的自动GTSM能力协商。
If a new protocol is designed with built-in GTSM support, then it is recommended that procedures are always used for sending and validating received protocol packets (GTSM is always on, see for example [RFC2461]). If, however, dynamic negotiation of GTSM support is necessary, protocol messages used for such negotiation MUST be authenticated using other security mechanisms to prevent DoS attacks.
如果新协议设计有内置的GTSM支持，则建议始终使用程序发送和验证接收到的协议包（GTSM始终打开，请参见示例[RFC2461]）。但是，如果需要对GTSM支持进行动态协商，则必须使用其他安全机制对用于此类协商的协议消息进行身份验证，以防止DoS攻击。
Also note that this specification does not offer a generic GTSM capability negotiation mechanism, so messages of the protocol augmented with the GTSM behavior will need to be used if dynamic negotiation is deemed necessary.
还要注意的是，本规范并没有提供通用的GTSM能力协商机制，所以若认为有必要进行动态协商，则需要使用添加了GTSM行为的协议消息。
Throughout this document, we assume that potential attackers have evolved in both sophistication and access to the point that they can send control traffic to a protocol session, and that this traffic appears to be valid control traffic (i.e., it has the source/ destination of configured peer routers).
在本文档中，我们假设潜在攻击者在复杂度和访问能力方面都有所发展，他们可以向协议会话发送控制流量，并且该流量似乎是有效的控制流量（即，它具有配置的对等路由器的源/目的地）。
We also assume that each router in the path between the attacker and the victim protocol speaker decrements TTL properly (clearly, if either the path or the adjacent peer is compromised, then there are worse problems to worry about).
我们还假设攻击者和受害者协议说话人之间的路径中的每个路由器都会适当地减少TTL（显然，如果路径或相邻对等方受到破坏，那么就有更糟糕的问题需要担心）。
For maximal protection, ingress filtering should be applied before the packet goes through the scarce resource. Otherwise an attacker directly connected to one interface could disturb a GTSM-protected session on the same or another interface. Interfaces that aren't configured with this filtering (e.g., backbone links) are assumed to not have such attackers (i.e., are trusted).
为了获得最大的保护，应该在数据包通过稀缺资源之前应用入口过滤。否则，直接连接到一个接口的攻击者可能会干扰同一个或另一个接口上受GTSM保护的会话。假定未配置此过滤的接口（例如主干链路）不存在此类攻击者（即受信任的）。
As a specific instance of such interfaces, we assume that tunnels are not a back-door for allowing TTL-spoofing on protocol packets to a GTSM-protected peering session with a directly connected neighbor. We assume that: 1) there are no tunneled packets terminating on the router, 2) tunnels terminating on the router are assumed to be secure and endpoints are trusted, 3) tunnel decapsulation includes source address spoofing prevention [RFC3704], or 4) the GTSM-enabled session does not allow protocol packets coming from a tunnel.
作为此类接口的一个具体实例，我们假设隧道不是允许TTL欺骗协议数据包到GTSM保护的与直接连接的邻居的对等会话的后门。我们假设：1）路由器上没有终止的隧道数据包，2）路由器上终止的隧道被认为是安全的，端点是可信的，3）隧道解封装包括源地址欺骗预防[RFC3704]，或4）启用GTSM的会话不允许来自隧道的协议数据包。
Since the vast majority of peerings are between adjacent routers, we can set the TTL on the protocol packets to 255 (the maximum possible for IP) and then reject any protocol packets that come in from configured peers that do NOT have an inbound TTL of 255.
由于绝大多数对等是在相邻路由器之间进行的，因此我们可以将协议数据包上的TTL设置为255（IP的最大可能值），然后拒绝来自未具有入站TTL 255的已配置对等的任何协议数据包。
GTSM can be disabled for applications such as route-servers and other multi-hop peerings. In the event that an attack comes in from a compromised multi-hop peering, that peering can be shut down.
对于路由服务器和其他多跳对等应用程序，可以禁用GTSM。如果攻击来自受损的多跳对等，则可以关闭该对等。
If GTSM is not built into the protocol and is used as an additional feature (e.g., for BGP, LDP, or MSDP), it SHOULD NOT be enabled by default in order to remain backward-compatible with the unmodified protocol. However, if the protocol defines a built-in dynamic capability negotiation for GTSM, a protocol peer MAY suggest the use of GTSM provided that GTSM would only be enabled if both peers agree to use it.
如果GTSM未内置在协议中，并且用作附加功能（例如，对于BGP、LDP或MSDP），则默认情况下不应启用GTSM，以便与未修改的协议保持向后兼容。然而，如果协议为GTSM定义了内置的动态能力协商，则协议对等方可以建议使用GTSM，前提是只有当两个对等方都同意使用GTSM时，才会启用GTSM。
If GTSM is enabled for a protocol session, the following steps are added to the IP packet sending and reception procedures:
如果为协议会话启用了GTSM，则IP数据包发送和接收过程将添加以下步骤：
Sending protocol packets:
发送协议数据包：
The TTL field in all IP packets used for transmission of messages associated with GTSM-enabled protocol sessions MUST be set to 255. This also applies to the related ICMP error handling messages.
用于传输与启用GTSM的协议会话相关的消息的所有IP数据包中的TTL字段必须设置为255。这也适用于相关的ICMP错误处理消息。
On some architectures, the TTL of control plane originated traffic is under some configurations decremented in the forwarding plane. The TTL of GTSM-enabled sessions MUST NOT be decremented.
在某些体系结构上，控制平面发起的业务的TTL在某些配置下在转发平面中递减。GTSM启用会话的TTL不得减少。
Receiving protocol packets:
接收协议包：
The GTSM packet identification step associates each received packet addressed to the router's control plane with one of the following three trustworthiness categories:
GTSM数据包识别步骤将寻址到路由器控制平面的每个接收数据包与以下三个可信类别之一相关联：
+ Unknown: these are packets that cannot be associated with any registered GTSM-enabled session, and hence GTSM cannot make any judgment on the level of risk associated with them.
+ 未知：这些数据包无法与任何已注册的启用GTSM的会话相关联，因此GTSM无法对与其相关的风险级别做出任何判断。
+ Trusted: these are packets that have been identified as belonging to one of the GTSM-enabled sessions, and their TTL values are within the expected range.
+ 受信任：这些数据包已被标识为属于启用GTSM的会话之一，且其TTL值在预期范围内。
+ Dangerous: these are packets that have been identified as belonging to one of the GTSM-enabled sessions, but their TTL values are NOT within the expected range, and hence GTSM believes there is a risk that these packets have been spoofed.
+ 危险：这些数据包已被识别为属于启用GTSM的会话之一，但其TTL值不在预期范围内，因此GTSM认为这些数据包存在被欺骗的风险。
The exact policies applied to packets of different classifications are not postulated in this document and are expected to be configurable. Configurability is likely necessary in particular with the treatment of related messages (ICMP errors). It should be noted that fragmentation may restrict the amount of information available for classification.
本文档中未假设适用于不同分类数据包的确切策略，且预期可配置。可配置性可能是必要的，尤其是在处理相关消息（ICMP错误）时。应注意的是，碎片化可能会限制可用于分类的信息量。
However, by default, the implementations:
但是，默认情况下，实现：
+ SHOULD ensure that packets classified as Dangerous do not compete for resources with packets classified as Trusted or Unknown.
+ 应确保分类为危险的数据包不会与分类为受信任或未知的数据包竞争资源。
+ MUST NOT drop (as part of GTSM processing) packets classified as Trusted or Unknown.
+ 不得丢弃（作为GTSM处理的一部分）分类为受信任或未知的数据包。
+ MAY drop packets classified as Dangerous.
+ 可能丢弃分类为危险的数据包。
The use of the TTL field to protect BGP originated with many different people, including Paul Traina and Jon Stewart. Ryan McDowell also suggested a similar idea. Steve Bellovin, Jay Borkenhagen, Randy Bush, Alfred Hoenes, Vern Paxon, Robert Raszuk, and Alex Zinin also provided useful feedback on earlier versions of this document. David Ward provided insight on the generalization of the original BGP-specific idea. Alex Zinin, Alia Atlas, and John Scudder provided a significant amount of feedback for the newer versions of the document. During and after the IETF Last Call, useful comments were provided by Francis Dupont, Sam Hartman, Lars Eggert, and Ross Callon.
使用TTL字段保护BGP起源于许多不同的人，包括保罗·特拉纳和乔恩·斯图尔特。Ryan McDowell也提出了类似的想法。Steve Bellovin、Jay Borkenhagen、Randy Bush、Alfred Hoenes、Vern Paxon、Robert Raszuk和Alex Zinin也对本文档的早期版本提供了有用的反馈。David Ward就BGP最初的具体想法的概括提供了见解。Alex Zinin、Alia Atlas和John Scudder为新版本的文档提供了大量反馈。在IETF上次通话期间和之后，Francis Dupont、Sam Hartman、Lars Eggert和Ross Callon提供了有用的评论。
GTSM is a simple procedure that protects single-hop protocol sessions, except in those cases in which the peer has been compromised. In particular, it does not protect against the wide range of on-the-wire attacks; protection from these attacks requires more rigorous security mechanisms.
GTSM是一个保护单跳协议会话的简单过程，但对等方受到损害的情况除外。特别是，它不能防止广泛的在线攻击；防范这些攻击需要更严格的安全机制。
The approach described here is based on the observation that a TTL (or Hop Limit) value of 255 is non-trivial to spoof, since as the packet passes through routers towards the destination, the TTL is decremented by one per router. As a result, when a router receives a packet, it may not be able to determine if the packet's IP address is valid, but it can determine how many router hops away it is (again, assuming none of the routers in the path are compromised in such a way that they would reset the packet's TTL).
这里描述的方法基于这样的观察，即TTL（或跃点限制）值255对于欺骗来说是非常重要的，因为当数据包通过路由器到达目的地时，每个路由器的TTL减少一个。因此，当路由器接收到数据包时，它可能无法确定该数据包的IP地址是否有效，但它可以确定该数据包的跳转次数（同样，假设路径中的所有路由器都不会以重置数据包的TTL的方式受损）。
Note, however, that while engineering a packet's TTL such that it has a particular value when sourced from an arbitrary location is difficult (but not impossible), engineering a TTL value of 255 from non-directly connected locations is not possible (again, assuming none of the directly connected neighbors are compromised, the packet has not been tunneled to the decapsulator, and the intervening routers are operating in accordance with RFC 791 [RFC0791]).
然而，请注意，虽然设计数据包的TTL以使其在来源于任意位置时具有特定值是困难的（但并非不可能），但从非直接连接位置设计255的TTL值是不可能的（同样，假设没有任何直接连接的邻居受到损害，则数据包没有通过隧道传输到解封装器，并且中间路由器按照RFC 791[RFC0791]进行操作）。
The security of any tunneling technique depends heavily on authentication at the tunnel endpoints, as well as how the tunneled packets are protected in flight. Such mechanisms are, however, beyond the scope of this memo.
任何隧道技术的安全性在很大程度上取决于隧道端点的身份验证，以及隧道数据包在飞行中的保护方式。然而，此类机制超出了本备忘录的范围。
An exception to the observation that a packet with TTL of 255 is difficult to spoof may occur when a protocol packet is tunneled and the tunnel is not integrity-protected (i.e., the lower layer is compromised).
当协议数据包被隧道化且隧道未受到完整性保护（即，较低层受到破坏）时，可能会出现TTL为255的数据包难以欺骗这一观察结果的例外情况。
When the protocol packet is tunneled directly to the protocol peer (i.e., the protocol peer is the decapsulator), the GTSM provides some limited added protection as the security depends entirely on the integrity of the tunnel.
当协议数据包直接通过隧道传输到协议对等方（即，协议对等方是解封装器）时，GTSM提供一些有限的附加保护，因为安全性完全取决于隧道的完整性。
For protocol adjacencies over a tunnel, if the tunnel itself is deemed secure (i.e., the underlying infrastructure is deemed secure, and the tunnel offers degrees of protection against spoofing such as keys or cryptographic security), the GTSM can serve as a check that the protocol packet did not originate beyond the head-end of the tunnel. In addition, if the protocol peer can receive packets for the GTSM-protected protocol session from outside the tunnel, the GTSM can help thwart attacks from beyond the adjacent router.
对于隧道上的协议邻接，如果隧道本身被认为是安全的（即，底层基础设施被认为是安全的，并且隧道提供一定程度的防欺骗保护，例如密钥或密码安全），则GTSM可以用作检查协议包是否起源于隧道前端之外。此外，如果协议对等方可以从隧道外部接收GTSM保护协议会话的数据包，则GTSM可以帮助阻止来自相邻路由器之外的攻击。
When the tunnel tail-end decapsulates the protocol packet and then IP-forwards the packet to a directly connected protocol peer, the TTL is decremented as described below. This means that the tunnel
当隧道尾端解除对协议分组的封装，然后IP将该分组转发给直接连接的协议对等方时，TTL如下文所述减小。这意味着隧道
decapsulator is the penultimate node from the GTSM-protected protocol peer's perspective. As a result, the GTSM check protects from attackers encapsulating packets to your peers. However, specific cases arise when the connection from the tunnel decapsulator node to the protocol peer is not an IP forwarding hop, where TTL-decrementing does not happen (e.g., layer-2 tunneling, bridging, etc). In the IPsec architecture [RFC4301], another example is the use of Bump-in-the-Wire (BITW) [BITW].
从GTSM保护协议对等方的角度来看，decapsulator是倒数第二个节点。因此，GTSM检查可防止攻击者将数据包封装到您的对等方。然而，当从隧道解封装器节点到协议对等方的连接不是IP转发跃点时，会出现特定情况，其中不会发生TTL递减（例如，第2层隧道、桥接等）。在IPsec体系结构[RFC4301]中，另一个示例是使用线内凹凸（BITW）[BITW]。
Protocol packets may be tunneled over IP directly to a protocol peer, or to a decapsulator (tunnel endpoint) that then forwards the packet to a directly connected protocol peer. Examples of tunneling IP over IP include IP-in-IP [RFC2003], GRE [RFC2784], and various forms of IPv6-in-IPv4 (e.g., [RFC4213]). These cases are depicted below.
协议分组可以通过IP直接隧道传输到协议对等方，或者传输到解封装器（隧道端点），该解封装器随后将分组转发到直接连接的协议对等方。IP上隧道IP的示例包括IP中的IP[RFC2003]、GRE[RFC2784]和各种形式的IPv6-in-IPv4（例如[RFC4213]）。这些案例描述如下。
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at processing]
Peer router ---------- Tunnel endpoint router and peer
TTL=255 [tunnel] [TTL=255 at ingress]
[TTL=255 at processing]
Peer router -------- Tunnel endpoint router ----- On-link peer
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
[TTL=254 at egress]
Peer router -------- Tunnel endpoint router ----- On-link peer
TTL=255 [tunnel] [TTL=255 at ingress] [TTL=254 at ingress]
[TTL=254 at egress]
In both cases, the encapsulator (origination tunnel endpoint) is the (supposed) sending protocol peer. The TTL in the inner IP datagram can be set to 255, since RFC 2003 specifies the following behavior:
在这两种情况下，封装器（发起隧道端点）是（假定的）发送协议对等方。内部IP数据报中的TTL可以设置为255，因为RFC 2003指定了以下行为：
When encapsulating a datagram, the TTL in the inner IP header is decremented by one if the tunneling is being done as part of forwarding the datagram; otherwise, the inner header TTL is not changed during encapsulation.
当封装数据报时，如果作为转发数据报的一部分正在进行隧道传输，则内部IP报头中的TTL减小1；否则，内部标头TTL在封装期间不会更改。
In the first case, the encapsulated packet is tunneled directly to the protocol peer (also a tunnel endpoint), and therefore the encapsulated packet's TTL can be received by the protocol peer with an arbitrary value, including 255.
在第一种情况下，被封装的分组被直接隧道到协议对等方（也是隧道端点），因此被封装分组的TTL可以由协议对等方以任意值（包括255）接收。
In the second case, the encapsulated packet is tunneled to a decapsulator (tunnel endpoint), which then forwards it to a directly connected protocol peer. For IP-in-IP tunnels, RFC 2003 specifies the following decapsulator behavior:
在第二种情况下，封装的数据包通过隧道传输到解封装器（隧道端点），然后由解封装器将其转发给直接连接的协议对等方。对于IP隧道中的IP，RFC 2003指定了以下解封装器行为：
The TTL in the inner IP header is not changed when decapsulating. If, after decapsulation, the inner datagram has TTL = 0, the decapsulator MUST discard the datagram. If, after decapsulation, the decapsulator forwards the datagram to one of its network
解除封装时，内部IP标头中的TTL不会更改。如果在解除封装后，内部数据报的TTL=0，则解除封装器必须丢弃该数据报。如果在解除封装后，解除封装器将数据报转发到其网络之一
interfaces, it will decrement the TTL as a result of doing normal IP forwarding. See also Section 4.4.
接口，它将由于执行正常的IP转发而减少TTL。另见第4.4节。
And similarly, for GRE tunnels, RFC 2784 specifies the following decapsulator behavior:
同样，对于GRE隧道，RFC 2784规定了以下去封装器行为：
When a tunnel endpoint decapsulates a GRE packet which has an IPv4 packet as the payload, the destination address in the IPv4 payload packet header MUST be used to forward the packet and the TTL of the payload packet MUST be decremented.
当隧道端点解除对具有IPv4数据包作为有效负载的GRE数据包的封装时，必须使用IPv4有效负载数据包报头中的目标地址转发该数据包，并且必须减小有效负载数据包的TTL。
Hence the inner IP packet header's TTL, as seen by the decapsulator, can be set to an arbitrary value (in particular, 255). If the decapsulator is also the protocol peer, it is possible to deliver the protocol packet to it with a TTL of 255 (first case). On the other hand, if the decapsulator needs to forward the protocol packet to a directly connected protocol peer, the TTL will be decremented (second case).
因此，如去封装器所示，内部IP包头的TTL可以设置为任意值（特别是255）。如果解封装器也是协议对等方，则可以使用255的TTL（第一种情况）将协议数据包传送给它。另一方面，如果解封装器需要将协议分组转发到直接连接的协议对等方，则TTL将减小（第二种情况）。
Protocol packets may also be tunneled over MPLS Label Switched Paths (LSPs) to a protocol peer. The following diagram depicts the topology.
协议分组也可以通过MPLS标签交换路径（lsp）隧道传输到协议对等方。下图描述了拓扑结构。
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]
Peer router -------- LSP Termination router and peer
TTL=255 MPLS LSP [TTL=x at ingress]
MPLS LSPs can operate in Uniform or Pipe tunneling models. The TTL handling for these models is described in RFC 3443 [RFC3443] that updates RFC 3032 [RFC3032] in regards to TTL processing in MPLS networks. RFC 3443 specifies the TTL processing in both Uniform and Pipe Models, which in turn can used with or without penultimate hop popping (PHP). The TTL processing in these cases results in different behaviors, and therefore are analyzed separately. Please refer to Section 3.1 through Section 3.3 of RFC 3443.
MPLS LSP可以在统一或管道隧道模型中运行。RFC 3443[RFC3443]中描述了这些型号的TTL处理，该文件针对MPLS网络中的TTL处理更新了RFC 3032[RFC3032]。RFC3443在统一模型和管道模型中都指定了TTL处理，这反过来可以使用倒数第二跳弹出（PHP）或不使用倒数第二跳弹出（PHP）。在这些情况下，TTL处理会导致不同的行为，因此将分别进行分析。请参考RFC 3443第3.1节至第3.3节。
The main difference from a TTL processing perspective between Uniform and Pipe Models at the LSP termination node resides in how the incoming TTL (iTTL) is determined. The tunneling model determines the iTTL: For Uniform Model LSPs, the iTTL is the value of the TTL field from the popped MPLS header (encapsulating header), whereas for Pipe Model LSPs, the iTTL is the value of the TTL field from the exposed header (encapsulated header).
从TTL处理的角度来看，LSP终端节点的统一模型和管道模型之间的主要区别在于如何确定传入TTL（iTTL）。隧道模型确定iTTL：对于统一模型LSP，iTTL是弹出MPLS报头（封装报头）中TTL字段的值，而对于管道模型LSP，iTTL是暴露报头（封装报头）中TTL字段的值。
For Uniform Model LSPs, RFC 3443 states that at ingress:
对于统一型号LSP，RFC 3443规定入口：
For each pushed Uniform Model label, the TTL is copied from the label/IP-packet immediately underneath it.
对于每个推送的统一型号标签，TTL从其正下方的标签/IP数据包复制。
From this point, the inner TTL (i.e., the TTL of the tunneled IP datagram) represents non-meaningful information, and at the egress node or during PHP, the ingress TTL (iTTL) is equal to the TTL of the popped MPLS header (see Section 3.1 of RFC 3443). In consequence, for Uniform Model LSPs of more than one hop, the TTL at ingress (iTTL) will be less than 255 (x <= 254), and as a result the check described in Section 3 of this document will fail.
从这一点来看，内部TTL（即隧道IP数据报的TTL）表示无意义的信息，并且在出口节点或PHP期间，入口TTL（iTTL）等于弹出的MPLS报头的TTL（参见RFC 3443第3.1节）。因此，对于多跳的统一型号LSP，入口的TTL（iTTL）将小于255（x<=254），因此，本文件第3节中描述的检查将失败。
The TTL treatment is identical between Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only). For these cases, RFC 3443 states that:
不含PHP的短管模型LSP和管道模型LSP（仅含PHP）之间的TTL处理是相同的。对于这些情况，RFC 3443规定：
For each pushed Pipe Model or Short Pipe Model label, the TTL field is set to a value configured by the network operator. In most implementations, this value is set to 255 by default.
对于每个推送管道模型或短管模型标签，TTL字段设置为网络运营商配置的值。在大多数实现中，此值默认设置为255。
In these models, the forwarding treatment at egress is based on the tunneled packet as opposed to the encapsulation packet. The ingress TTL (iTTL) is the value of the TTL field of the header that is exposed, that is the tunneled IP datagram's TTL. The protocol packet's TTL as seen by the LSP termination can therefore be set to an arbitrary value (including 255). If the LSP termination router is also the protocol peer, it is possible to deliver the protocol packet with a TTL of 255 (x = 255).
在这些模型中，出口处的转发处理基于隧道包而不是封装包。入口TTL（iTTL）是公开的报头的TTL字段的值，即隧道IP数据报的TTL。因此，LSP终端可以将协议包的TTL设置为任意值（包括255）。如果LSP终端路由器也是协议对等方，则可以使用255（x=255）的TTL发送协议数据包。
Finally, for Short Pipe Model LSPs with PHP, the TTL of the tunneled packet is unchanged after the PHP operation. Therefore, the same conclusions drawn regarding the Short Pipe Model LSPs without PHP and Pipe Model LSPs (without PHP only) apply to this case. For Short Pipe Model LSPs, the TTL at egress has the same value with or without PHP.
最后，对于使用PHP的短管模型LSP，在PHP操作之后，隧道数据包的TTL保持不变。因此，关于不含PHP的短管模型LSP和管道模型LSP（仅含PHP）得出的相同结论也适用于这种情况。对于短管模型LSP，出口处的TTL在有或没有PHP时具有相同的值。
In conclusion, GTSM checks are possible for IP tunneled over Pipe model LSPs, but not for IP tunneled over Uniform model LSPs. Additionally, for all tunneling modes, if the LSP termination router needs to forward the protocol packet to a directly connected protocol peer, it is not possible to deliver the protocol packet to the protocol peer with a TTL of 255. If the packet is further forwarded, the outgoing TTL (oTTL) is calculated by decrementing iTTL by one.
总之，GTSM检查适用于管道模型LSP上的IP隧道，但不适用于均匀模型LSP上的IP隧道。此外，对于所有隧道模式，如果LSP终端路由器需要将协议分组转发给直接连接的协议对等方，则不可能以255的TTL将协议分组交付给协议对等方。如果进一步转发分组，则通过将iTTL减1来计算出发TTL（oTTL）。
As described in Section 2, an attacker directly connected to one interface can disturb a GTSM-protected session on the same or another interface (by spoofing a GTSM peer's address) unless ingress filtering has been applied on the connecting interface. As a result, interfaces that do not include such protection need to be trusted not to originate attacks on the router.
如第2节所述，直接连接到一个接口的攻击者可以干扰同一接口或另一接口上受GTSM保护的会话（通过欺骗GTSM对等方的地址），除非在连接接口上应用了入口过滤。因此，需要信任不包含此类保护的接口，以免对路由器发起攻击。
As mentioned, fragmentation may restrict the amount of information available for classification. Since non-initial IP fragments do not contain Layer 4 information, it is highly likely that they cannot be associated with a registered GTSM-enabled session. Following the receiving protocol procedures described in Section 3, non-initial IP fragments would likely be classified with Unknown trustworthiness. And since the IP packet would need to be reassembled in order to be processed, the end result is that the initial-fragment of a GTSM-enabled session effectively receives the treatment of an Unknown-trustworthiness packet, and the complete reassembled packet receives the aggregate of the Unknowns.
如上所述，碎片可能会限制可用于分类的信息量。由于非初始IP片段不包含第4层信息，因此它们很可能无法与已注册的启用GTSM的会话相关联。按照第3节中描述的接收协议程序，非初始IP片段可能会被分类为未知可信。并且，由于IP分组需要重新组装以便进行处理，最终结果是，启用GTSM的会话的初始片段有效地接收未知可信分组的处理，并且完整的重新组装分组接收未知的集合。
In principle, an implementation could remember the TTL of all received fragments. Then when reassembling the packet, verify that the TTL of all fragments match the required value for an associated GTSM-enabled session. In the likely common case that the implementation does not do this check on all fragments, then it is possible for a legitimate first fragment (which passes the GTSM check) to be combined with spoofed non-initial fragments, implying that the integrity of the received packet is unknown and unprotected. If this check is performed on all fragments at reassembly, and some fragment does not pass the GTSM check for a GTSM-enabled session, the reassembled packet is categorized as a Dangerous-trustworthiness packet and receives the corresponding treatment.
原则上，实现可以记住所有接收片段的TTL。然后，在重新组装数据包时，验证所有片段的TTL是否与相关GTSM启用会话的所需值匹配。在实现没有对所有片段执行此检查的可能常见情况下，合法的第一个片段（通过GTSM检查）可能与伪造的非初始片段组合，这意味着接收到的数据包的完整性未知且不受保护。如果在重新组装时对所有片段执行此检查，并且某些片段未通过启用GTSM会话的GTSM检查，则重新组装的数据包被归类为危险的可信数据包，并接受相应的处理。
Further, reassembly requires to wait for all the fragments and therefore likely invalidates or weakens the fifth assumption presented in Section 2: it may not be possible to classify non-initial fragments before going through a scarce resource in the system, when fragments need to be buffered for reassembly and later processed by a CPU. That is, when classification cannot be done with the required granularity, non-initial fragments of GTSM-enabled session packets would not use different resource pools.
此外，重新组装需要等待所有碎片，因此可能会使第2节中提出的第五个假设失效或减弱：当碎片需要缓冲以进行重新组装并随后由CPU处理时，在系统中使用稀缺资源之前，可能无法对非初始碎片进行分类。也就是说，当无法按要求的粒度进行分类时，启用GTSM的会话数据包的非初始片段将不会使用不同的资源池。
Consequently, to get practical protection from fragment attacks, operators may need to rate-limit or discard all received fragments. As such, it is highly RECOMMENDED for GTSM-protected protocols to
因此，为了从碎片攻击中获得实际保护，操作员可能需要限制速率或丢弃所有接收到的碎片。因此，强烈建议GTSM保护的协议
avoid fragmentation and reassembly by manual MTU tuning, using adaptive measures such as Path MTU Discovery (PMTUD), or any other available method [RFC1191], [RFC1981], or [RFC4821].
使用路径MTU发现（PMTUD）或任何其他可用方法[RFC1191]、[RFC1981]或[RFC4821]等自适应措施，通过手动MTU调优避免碎片化和重新组装。
GTSM could possibly offer some small, though difficult to quantify, degree of protection when used with multi-hop protocol sessions (see Appendix A). In order to avoid having to quantify the degree of protection and the resulting applicability of multi-hop, we only describe the single-hop case because its security properties are clearer.
当与多跳协议会话一起使用时，GTSM可能会提供一些小的、但难以量化的保护程度（见附录A）。为了避免量化多跳的保护程度和由此产生的适用性，我们只描述单跳情况，因为它的安全属性更清晰。
GTSM is only applicable to environments with inherently limited topologies (and is most effective in those cases where protocol peers are directly connected). In particular, its application should be limited to those cases in which protocol peers are directly connected.
GTSM仅适用于具有固有有限拓扑的环境（并且在协议对等点直接连接的情况下最有效）。特别是，其应用应限于协议对等方直接连接的情况。
GTSM will not protect against attackers who are as close to the protected station as its legitimate peer. For example, if the legitimate peer is one hop away, GTSM will not protect from attacks from directly connected devices on the same interface (see Section 2.2 for more).
GTSM不会保护攻击者，因为攻击者与其合法对等方一样接近受保护的站点。例如，如果合法对等点距离一跳，则GTSM将无法防止来自同一接口上直接连接设备的攻击（更多信息，请参阅第2.2节）。
Experimentation on GTSM's applicability and security properties is needed in multi-hop scenarios. The multi-hop scenarios where GTSM might be applicable is expected to have the following characteristics: the topology between peers is fairly static and well-known, and in which the intervening network (between the peers) is trusted.
在多跳场景中，需要对GTSM的适用性和安全性进行实验。GTSM可能适用的多跳场景预计具有以下特征：对等点之间的拓扑是相当静态和众所周知的，并且（对等点之间的）中间网络是可信的。
RFC 3682 [RFC3682] did not specify how to handle "related messages" (ICMP errors). This specification mandates setting and verifying TTL=255 of those as well as the main protocol packets.
RFC 3682[RFC3682]未指定如何处理“相关消息”（ICMP错误）。本规范要求设置和验证其中的TTL=255以及主协议数据包。
Setting TTL=255 in related messages does not cause issues for RFC 3682 implementations.
在相关消息中设置TTL=255不会导致RFC 3682实现出现问题。
Requiring TTL=255 in related messages may have impact with RFC 3682 implementations, depending on which default TTL the implementation uses for originated packets; some implementations are known to use 255, while 64 or other values are also used. Related messages from the latter category of RFC 3682 implementations would be classified
在相关消息中要求TTL=255可能会对RFC 3682实现产生影响，具体取决于该实现对原始数据包使用的默认TTL；一些实现已知使用255，同时也使用64或其他值。来自后一类RFC 3682实现的相关消息将被分类
as Dangerous and treated as described in Section 3. This is not believed to be a significant problem because protocols do not depend on related messages (e.g., typically having a protocol exchange for closing the session instead of doing a TCP-RST), and indeed the delivery of related messages is not reliable. As such, related messages typically provide an optimization to shorten a protocol keepalive timeout. Regardless of these issues, given that related messages provide a significant attack vector to e.g., reset protocol sessions, making this further restriction seems sensible.
如第3节所述，视为危险和处理。这不被认为是一个重大问题，因为协议不依赖于相关消息（例如，通常有一个协议交换来关闭会话，而不是执行TCP-RST），而且相关消息的传递确实不可靠。因此，相关消息通常提供一种优化，以缩短协议保持生存超时。不管这些问题，假定相关消息提供了重要的攻击向量，例如重置协议会话，使得这种进一步的限制似乎是明智的。
[RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[RFC0791]Postel，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[RFC2003] Perkins, C., "IP Encapsulation within IP", RFC 2003, October 1996.
[RFC2003]Perkins，C.，“IP内的IP封装”，RFC 2003，1996年10月。
[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月。
[RFC2461] Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery for IP Version 6 (IPv6)", RFC 2461, December 1998.
[RFC2461]Narten，T.，Nordmark，E.，和W.Simpson，“IP版本6（IPv6）的邻居发现”，RFC2461，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月。
[RFC3392] Chandra, R. and J. Scudder, "Capabilities Advertisement with BGP-4", RFC 3392, November 2002.
[RFC3392]Chandra，R.和J.Scudder，“BGP-4的能力广告”，RFC 3392，2002年11月。
[RFC3443] Agarwal, P. and B. Akyol, "Time To Live (TTL) Processing in Multi-Protocol Label Switching (MPLS) Networks", RFC 3443, January 2003.
[RFC3443]Agarwal，P.和B.Akyol，“多协议标签交换（MPLS）网络中的生存时间（TTL）处理”，RFC 3443，2003年1月。
[RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
[RFC4213]Nordmark，E.和R.Gilligan，“IPv6主机和路由器的基本转换机制”，RFC 4213，2005年10月。
[RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, January 2006.
[RFC4271]Rekhter，Y.，Li，T.，和S.Hares，“边境网关协议4（BGP-4）”，RFC 42712006年1月。
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[BITW] "Thread: 'IP-in-IP, TTL decrementing when forwarding and BITW' on int-area list, Message-ID: <Pine.LNX.4.64.0606020830220.12705@netcore.fi>", June 2006, <http://www1.ietf.org/mail-archive/web/ int-area/current/msg00267.html>.
[BITW]“线程：IP中的IP，转发时TTL递减，int区域列表中的BITW”，消息ID:<Pine.LNX.4.64.0606020830220。12705@netcore.fi>“，2006年6月<http://www1.ietf.org/mail-archive/web/ int area/current/msg00267.html>。
[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月。
[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月。
[RFC3682] Gill, V., Heasley, J., and D. Meyer, "The Generalized TTL Security Mechanism (GTSM)", RFC 3682, February 2004.
[RFC3682]Gill，V.，Heasley，J.，和D.Meyer，“广义TTL安全机制（GTSM）”，RFC 3682，2004年2月。
[RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004.
[RFC3704]Baker，F.和P.Savola，“多宿网络的入口过滤”，BCP 84，RFC 37042004年3月。
[RFC4272] Murphy, S., "BGP Security Vulnerabilities Analysis", RFC 4272, January 2006.
[RFC4272]Murphy，S.，“BGP安全漏洞分析”，RFC 4272，2006年1月。
[RFC4821] Mathis, M. and J. Heffner, "Packetization Layer Path MTU Discovery", RFC 4821, March 2007.
[RFC4821]Mathis，M.和J.Heffner，“打包层路径MTU发现”，RFC 48212007年3月。
NOTE: This is a non-normative part of the specification.
注：这是本规范的非规范性部分。
The main applicability of GTSM is for directly connected peers. GTSM could be used for non-directly connected sessions as well, where the recipient would check that the TTL is within a configured number of hops from 255 (e.g., check that packets have 254 or 255). As such deployment is expected to have a more limited applicability and different security implications, it is not specified in this document.
GTSM主要适用于直接连接的对等点。GTSM也可用于非直接连接的会话，其中接收方将检查TTL是否在255的配置跳数范围内（例如，检查数据包是否有254或255）。由于预计此类部署的适用性更为有限，安全影响也各不相同，因此本文件未对其进行详细说明。
o Bring the work on the Standards Track (RFC 3682 was Experimental).
o 将工作纳入标准轨道（RFC3682是实验性的）。
o New text on GTSM applicability and use in new and existing protocols.
o 关于GTSM在新协议和现有协议中的适用性和使用的新文本。
o Restrict the scope to not specify multi-hop scenarios.
o 将范围限制为不指定多跳方案。
o Explicitly require that related messages (ICMP errors) must also be sent and checked to have TTL=255. See Section 6.1 for discussion on backwards compatibility.
o 明确要求还必须发送和检查相关消息（ICMP错误），以使TTL=255。有关向后兼容性的讨论，请参见第6.1节。
o Clarifications relating to fragmentation, security with tunneling, and implications of ingress filtering.
o 关于碎片、隧道安全和入口过滤含义的澄清。
o A significant number of editorial improvements and clarifications.
o 大量的编辑改进和澄清。
Authors' Addresses
作者地址
Vijay Gill EMail: vijay@umbc.edu
Vijay Gill电子邮件：vijay@umbc.edu
John Heasley EMail: heas@shrubbery.net
约翰·希斯利电子邮件：heas@shrubbery.net
David Meyer EMail: dmm@1-4-5.net
David Meyer电子邮件：dmm@1-4-5.net
Pekka Savola (editor) Espoo Finland EMail: psavola@funet.fi
佩卡·萨沃拉（编辑）埃斯波芬兰电子邮件：psavola@funet.fi
Carlos Pignataro EMail: cpignata@cisco.com
卡洛斯·皮格纳塔罗电子邮件：cpignata@cisco.com
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
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, THE IETF TRUST 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.
本文件及其包含的信息以“原样”为基础提供，贡献者、他/她所代表或赞助的组织（如有）、互联网协会、IETF信托基金和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
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.