Network Working Group R. Sparks
Request for Comments: 4321 Estacado Systems
Category: Informational January 2006
Network Working Group R. Sparks
Request for Comments: 4321 Estacado Systems
Category: Informational January 2006
Problems Identified Associated with the Session Initiation Protocol's (SIP) Non-INVITE Transaction
识别出与会话启动协议（SIP）的非邀请事务相关的问题
Status of This Memo
关于下段备忘
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
Abstract
摘要
This document describes several problems that have been identified with the Session Initiation Protocol's (SIP) non-INVITE transaction.
本文档描述了会话启动协议（SIP）的非邀请事务中发现的几个问题。
Table of Contents
目录
1. Problems under the Current Specifications .......................2
1.1. NITs must complete immediately or risk losing a race .......2
1.2. Provisional responses can delay recovery from lost
final responses ............................................3
1.3. Delayed responses will temporarily blacklist an element ....4
1.4. 408 for non-INVITE is not useful ...........................6
1.5. Non-INVITE timeouts doom forking proxies ...................7
1.6. Mismatched timer values make winning the race harder .......7
2. Security Considerations .........................................8
3. Acknowledgements ................................................8
4. Informative References ..........................................9
1. Problems under the Current Specifications .......................2
1.1. NITs must complete immediately or risk losing a race .......2
1.2. Provisional responses can delay recovery from lost
final responses ............................................3
1.3. Delayed responses will temporarily blacklist an element ....4
1.4. 408 for non-INVITE is not useful ...........................6
1.5. Non-INVITE timeouts doom forking proxies ...................7
1.6. Mismatched timer values make winning the race harder .......7
2. Security Considerations .........................................8
3. Acknowledgements ................................................8
4. Informative References ..........................................9
There are a number of unpleasant edge conditions created by the SIP non-INVITE transaction (NIT) model's fixed duration. The negative aspects of some of these are exacerbated by the effect that provisional responses have on the non-INVITE transaction state machines as currently defined.
SIP non INVITE transaction（NIT）模型的固定持续时间造成了许多令人不快的边缘条件。临时响应对当前定义的非INVITE事务状态机的影响加剧了其中一些负面影响。
The non-INVITE transaction defined in RFC 3261 [1] is designed to have a fixed and finite duration (dependent on T1). A consequence of this design is that participants must strive to complete the transaction as quickly as possible. Consider the race condition shown in Figure 1.
RFC 3261[1]中定义的非INVITE事务被设计为具有固定和有限的持续时间（取决于T1）。这种设计的结果是参与者必须努力尽快完成交易。考虑图1所示的竞争条件。
UAC UAS
| request |
--- |---. |
^ | `---. |
| | `-->| ---
| | | ^
| | | |
64*T1 | | |
| | | |
| | | 64*T1
| | | |
| | | |
v | | |
timeout <=== --- | 200 OK | |
| .---| v
| .---' | ---
|<--' |
UAC UAS
| request |
--- |---. |
^ | `---. |
| | `-->| ---
| | | ^
| | | |
64*T1 | | |
| | | |
| | | 64*T1
| | | |
| | | |
v | | |
timeout <=== --- | 200 OK | |
| .---| v
| .---' | ---
|<--' |
Figure 1: Non-Invite Race Condition
图1：非邀请竞争条件
The User Agent Server (UAS) in this figure believes it has responded to the request in time, and that the request succeeded. The User Agent Client (UAC), on the other hand, believes the request has timed-out, hence failed. No longer having a matching client transaction, the UAC core will ignore what it believes to be a spurious response. As far as the UAC is concerned, it received no response at all to its request. The ultimate result is that the UAS and UAC have conflicting views of the outcome of the transaction.
此图中的用户代理服务器（UAS）认为它已及时响应请求，并且请求成功。另一方面，用户代理客户端（UAC）认为请求已超时，因此失败。UAC核心不再有匹配的客户端事务，它将忽略它认为是虚假的响应。就UAC而言，它的请求根本没有得到任何回应。最终结果是，UAS和UAC对交易结果的看法存在冲突。
Therefore, a UAS cannot wait until the last possible moment to send a final response within a NIT. It must, instead, send its response so that it will arrive at the UAC before that UAC times out. Unfortunately, the UAS has no way to accurately measure the propagation time of the request or predict the propagation time of the response. The uncertainty it faces is compounded by each proxy that participates in the transaction. Thus, the UAS's only choice is to send its final response as soon as it possibly can and hope for the best.
因此，UAS不能等到最后一个可能的时刻才在NIT内发送最终响应。相反，它必须发送响应，以便在UAC超时之前到达UAC。不幸的是，UAS无法准确测量请求的传播时间或预测响应的传播时间。它所面临的不确定性因参与交易的每一位代理人而加剧。因此，UAS唯一的选择就是尽可能快地发送其最终响应，并希望得到最好的结果。
This result constrains the set of problems that can be solved with a single NIT. Any delay introduced during processing of a request increases the probability of losing the race. If the timing characteristics of that processing are not predictable and controllable, a single NIT is an inappropriate model for handling the request. One viable alternative is to accept the request with a 202 and send the ultimate results in a new request in the reciprocal direction.
这一结果限制了可以用单个NIT解决的一组问题。在处理请求过程中引入的任何延迟都会增加比赛失败的概率。如果处理的时间特性不可预测和控制，那么单个NIT是处理请求的不合适模型。一个可行的替代方案是使用202接受请求，并以相反的方向在新请求中发送最终结果。
In specialized networks, a UAS might have some reliable knowledge of inter-hop latency and could use that knowledge to determine if it has time to delay its final response in order to perform some processing such as a database lookup while mitigating its risk of losing the race in Figure 1. Establishing this knowledge across arbitrary networks (perhaps using resource reservation techniques and deterministic transports) is not currently feasible.
在专用网络中，UAS可能对跳间延迟有一些可靠的了解，并且可以使用这些知识来确定它是否有时间延迟其最终响应，以便执行一些处理，例如数据库查找，同时降低其在图1中失去竞争的风险。在任意网络中建立这种知识（可能使用资源保留技术和确定性传输）目前是不可行的。
The non-INVITE client transaction state machine provides reliability for NITs over unreliable transports (UDP) through retransmission of the request message. Timer E is set to T1 when a request is initially transmitted. As long as the machine remains in the Trying state, each time Timer E fires, it will be reset to twice its previous value (capping at T2) and the request is retransmitted.
非INVITE客户端事务状态机通过重新传输请求消息，通过不可靠传输（UDP）为NIT提供可靠性。最初发送请求时，定时器E设置为T1。只要机器保持在尝试状态，每次定时器E启动时，它将重置为其先前值的两倍（在T2处设置上限），请求将被重新传输。
If the non-INVITE client transaction state machine sees a provisional response, it transitions to the Proceeding state, where retransmission continues, but the algorithm for resetting Timer E is simply to use T2 instead of doubling at each firing. (Note that Timer E is not altered during the transition to Proceeding.)
如果非INVITE客户端事务状态机看到临时响应，它将转换到进行中的状态，其中重新传输继续，但是重置计时器E的算法只是使用T2，而不是在每次触发时加倍。（请注意，在过渡到继续的过程中，计时器E不会改变。）
Making the transition to the Proceeding state before Timer E is reset to T2 can cause recovery from a lost final response to take extra time. Figure 2 shows recovery from a lost final response with and without a provisional message during this window. Recovery occurs within 2*T1 in the case without the provisional. With the provisional, recovery is delayed until T2, which by default is 8*T1.
在定时器E重置为T2之前转换到继续状态可能会导致从丢失的最终响应中恢复需要额外的时间。图2显示了在此窗口期间从丢失的最终响应中恢复，包括临时消息和不包含临时消息。在没有临时性的情况下，恢复发生在2*T1范围内。对于临时值，恢复延迟到T2，默认情况下为8*T1。
In practical terms, a provisional response to a NIT in currently deployed networks can delay transaction completion by up to 3.5 seconds.
实际上，在当前部署的网络中，对NIT的临时响应最多可延迟事务完成3.5秒。
UAC UAS UAC UAS
| | | |
--- |----. | --- |----. |
^ | `-->| ^ | `--->|
E = T1 | | E = T1 | .-----|(provisional)
v | | v |<--' |
--- |----. | --- |----. |
^ | `-->| ^ | `--->|
| | X<----|(lost final) | | X<-----|(lost final)
| | | | | |
E = 2*T1 | | | | |
| | | | | |
| | | | | |
v | | | | |
--- |----. | | | |
| `-->| | | |
| .-----|(final) | | |
|<-' | | | |
| | | | |
\/\ /\/ /\/ /\/ /\/
E = T2
\/\ /\/ /\/ /\/ /\/
| | | | |
| | v | |
| | --- |----. |
| | | `--->|
| | | .-----|(final)
| | |<--' |
| | | |
UAC UAS UAC UAS
| | | |
--- |----. | --- |----. |
^ | `-->| ^ | `--->|
E = T1 | | E = T1 | .-----|(provisional)
v | | v |<--' |
--- |----. | --- |----. |
^ | `-->| ^ | `--->|
| | X<----|(lost final) | | X<-----|(lost final)
| | | | | |
E = 2*T1 | | | | |
| | | | | |
| | | | | |
v | | | | |
--- |----. | | | |
| `-->| | | |
| .-----|(final) | | |
|<-' | | | |
| | | | |
\/\ /\/ /\/ /\/ /\/
E = T2
\/\ /\/ /\/ /\/ /\/
| | | | |
| | v | |
| | --- |----. |
| | | `--->|
| | | .-----|(final)
| | |<--' |
| | | |
Figure 2: Provisionals Can Harm Recovery
图2：临时措施可能会损害恢复
No additional delay is introduced if the first provisional response is received after Timer E has reached its maximum reset interval of T2.
如果在定时器E达到其最大复位间隔T2后接收到第一个临时响应，则不会引入额外延迟。
A SIP element's use of DNS Service Record Resource Records [3] is specified in RFC 3263 [2]. That specification discusses how SIP ensures high availability by having upstream elements detect failure of downstream elements. It proceeds to define several types of failure detection and instructions for failover. Two of the behaviors it describes are important to this document:
RFC 3263[2]中指定了SIP元素对DNS服务记录资源记录[3]的使用。该规范讨论了SIP如何通过让上游元素检测下游元素的故障来确保高可用性。接下来将定义几种类型的故障检测和故障切换指令。它描述的两种行为对本文档很重要：
o Within a transaction, transport failure is detected either through an explicit report from the transport layer or through timeout. Note specifically that timeout will indicates transport failure regardless of the transport in use. When transport failure is detected, the request is retried at the next element from the sorted results of the SRV query.
o 在事务中，通过传输层的显式报告或超时来检测传输失败。请特别注意，无论使用何种传输，超时都表示传输失败。当检测到传输失败时，将在SRV查询的排序结果的下一个元素重试该请求。
o Between transactions, locations reporting temporary failure (through 503/Retry-After, for example) are not used until their requested black-out period expires.
o 在事务之间，报告临时故障的位置（例如，通过503/重试后）在其请求的中断期到期之前不会使用。
The specification notes the benefit of caching locations that are successfully contacted, but does not discuss how such a cache is maintained. It is unclear whether an element should stop using (temporarily blacklist) a location returned in the SRV query that results in a transport error. If it does, when should such a location be removed from the blacklist?
该规范注意到缓存成功联系的位置的好处，但没有讨论如何维护这样的缓存。不清楚元素是否应该停止使用（临时黑名单）SRV查询中返回的导致传输错误的位置。如果是的话，什么时候该从黑名单中删除该位置？
Without such a blacklist (or equivalent mechanism), the intended availability mechanism fails miserably. Consider traffic between two domains. Proxy pA in domain A needs to forward a sequence of non-INVITE requests to domain B. Through DNS SRV, pA discovers pB1 and pB2, and the ordering rules of [2] and [3] indicate it should use pB1 first. The first request to pB1 times out. Since pA is a proxy and a NIT has a fixed duration, pA has no opportunity to retry the request at pB2. If pA does not remember pB1's failure, the second request (and all subsequent non-INVITE requests until pB1 recovers) are doomed to the same failure. Caching would allow the subsequent requests to be tried at pB2.
如果没有这样一个黑名单（或同等机制），预期的可用性机制将惨遭失败。考虑两个域之间的流量。域A中的代理pA需要将一系列非INVITE请求转发到域B。pA通过DNS SRV发现pB1和pB2，[2]和[3]的排序规则表明它应该首先使用pB1。对pB1的第一个请求超时。由于pA是一个代理，NIT具有固定的持续时间，pA没有机会在pB2重试请求。如果pA不记得pB1的失败，则第二个请求（以及pB1恢复之前的所有后续非INVITE请求）注定会发生相同的失败。缓存将允许在pB2上尝试后续请求。
Since miserable failure is not acceptable in deployed networks, we should anticipate that elements will, in fact, cache timeout failures between transactions. Then the race in Figure 1 becomes important. If an element fails to respond "soon enough", it has effectively not responded at all and will be blacklisted at its peer for some period of time.
由于在已部署的网络中不可接受悲惨的故障，因此我们应该预计，实际上，元素将在事务之间缓存超时故障。然后，图1中的竞争变得很重要。如果一个元素未能“足够快”响应，那么它实际上根本没有响应，并将在一段时间内被列入其对等元素的黑名单。
(Note that even with caching, the first request timeout results in a timeout failure all the way back to the original submitter. The failover mechanisms in [2] work well to increase the resiliency of a given INVITE transaction, but do nothing for a given non-INVITE transaction.)
（请注意，即使使用缓存，第一个请求超时也会导致超时失败，一直返回到原始提交者。[2]中的故障切换机制可以很好地提高给定INVITE事务的弹性，但对给定的非INVITE事务不起任何作用。）
Consider the race condition in Figure 1 when the final response is 408 instead of 200. Under the current specification, the race is guaranteed to be lost. Most existing endpoints will emit a 408 for a non-INVITE request 64*T1 after receiving the request if they have not emitted an earlier final response. Such a 408 is guaranteed to arrive at the next upstream element too late to be useful. In fact, in the presence of proxies, these messages are even harmful. When the 408 arrives, each proxy will have already terminated its associated client transaction due to timeout. Therefore, each proxy must forward the 408 upstream statelessly. This, in turn, is guaranteed to arrive too late. As Figure 3 shows, this can ultimately result in bombarding the original requester with spurious 408s. (Note that the proxy's client transaction state machine never enters the Completed state, so Timer K does not enter into play.)
当最后响应为408而不是200时，考虑图1中的竞争条件。根据目前的规格，比赛是保证输掉的。大多数现有端点在接收到请求后，如果没有发出较早的最终响应，则它们将发出408用于非INVITE请求64*T1。这样的网络408被保证太晚到达下一个上游元素而没有用处。事实上，在存在代理的情况下，这些消息甚至是有害的。当408到达时，由于超时，每个代理将已经终止其关联的客户端事务。因此，每个代理必须无状态地转发408上行。反过来，这肯定会来得太迟。如图3所示，这最终可能导致用虚假408轰炸原始请求者。（请注意，代理的客户端事务状态机从未进入“完成”状态，因此计时器K不会进入运行状态。）
UAC P1 P2 P3 UAS
| | | | |
--- ===---. | | | |
^ | `-->===---. | | |
| | | `-->===---. | |
| | | | `-->===---. |
64*T1 | | | | `-->===
| | | | | |
| | | | | |
v | | | | |
(timeout) --- === | | | |
| .-408=== | | |
|<--' | .-408=== | |
| .-408-|<--' | .-408=== |
|<--' | .-408-|<--' | .-408===
| .-408-|<--' | .-408-|<--' |
|<--' | .-408-|<--' | |
| .-408-|<--' | | |
|<--' | | | |
| | | | |
UAC P1 P2 P3 UAS
| | | | |
--- ===---. | | | |
^ | `-->===---. | | |
| | | `-->===---. | |
| | | | `-->===---. |
64*T1 | | | | `-->===
| | | | | |
| | | | | |
v | | | | |
(timeout) --- === | | | |
| .-408=== | | |
|<--' | .-408=== | |
| .-408-|<--' | .-408=== |
|<--' | .-408-|<--' | .-408===
| .-408-|<--' | .-408-|<--' |
|<--' | .-408-|<--' | |
| .-408-|<--' | | |
|<--' | | | |
| | | | |
Figure 3: Late 408s to Non-INVITEs
图3:408晚至非邀请
This response bombardment is not limited to the 408 response, though it only exists when participating client transaction state machines are timing out. Figure 4 generalizes Figure 1 to include multiple hops. Note that even though the UAS responds "in time" to P3, the response is too late for P2, P1, and the UAC.
此响应轰击不限于408响应，尽管它仅在参与的客户端事务状态机超时时存在。图4概括了图1，包括多跳。请注意，尽管UAS“及时”响应P3，但对于P2、P1和UAC来说，响应太迟。
UAC P1 P2 P3 UAS
| | | | |
--- ===---. | | | |
^ | `-->===---. | | |
| | | `-->===---. | |
| | | | `-->===---. |
64*T1 | | | | `-->===
| | | | | |
| | | | | |
v | | | | |
(timeout) --- === | | | |
| .-408=== | | .-200-|
|<--' | .-408=== .-200-|<--' |
| .-408-|<--'.-200-|<--' === |
|<--'.-200-|<--' | | ===
|<--' | | | |
| | | | |
UAC P1 P2 P3 UAS
| | | | |
--- ===---. | | | |
^ | `-->===---. | | |
| | | `-->===---. | |
| | | | `-->===---. |
64*T1 | | | | `-->===
| | | | | |
| | | | | |
v | | | | |
(timeout) --- === | | | |
| .-408=== | | .-200-|
|<--' | .-408=== .-200-|<--' |
| .-408-|<--'.-200-|<--' === |
|<--'.-200-|<--' | | ===
|<--' | | | |
| | | | |
Figure 4: Additional Timeout-Related Error
图4：额外的超时相关错误
A single branch with a delayed or missing final response will dominate the processing at proxy that receives no 2xx responses to a forked non-INVITE request. This proxy is required to allow all of its client transactions to terminate before choosing a "best response". This forces the proxy's server transaction to lose the race in Figure 1. Any response it ultimately forwards (a 401, for example) will arrive at the upstream elements too late to be used. Thus, if no element among the branches would return a 2xx response, failure of a single element (or its transport) dooms the proxy to failure.
具有延迟或缺少最终响应的单个分支将主导代理的处理，该代理不接收对分叉非INVITE请求的2xx响应。在选择“最佳响应”之前，需要此代理允许其所有客户端事务终止。这将迫使代理服务器事务在图1中失去竞争。它最终转发的任何响应（例如401）都将太晚到达上游元素，无法使用。因此，如果分支中没有任何元素返回2xx响应，则单个元素（或其传输）的失败将使代理失败。
There are many failure scenarios due to misconfiguration or misbehavior that the SIP specification does not discuss. One is placing two elements with different configured values for T1 and T2 on the same network. Review of Figure 1 illustrates that the race failure is only made more likely in this misconfigured state (it may appear that shortening T1 at the element behaving as a UAS improves this particular situation, but remember that these elements may trade roles on the next request). Since the protocol provides no mechanism for discovering/negotiating a peer's timer values, exceptional care must be taken when deploying systems with non-defaults to ensure that they will never directly communicate with elements with default values.
由于错误配置或不当行为，SIP规范没有讨论许多故障场景。一种是在同一网络上放置两个具有不同T1和T2配置值的元件。对图1的回顾表明，在这种配置错误的状态下，竞争失败的可能性更大（在作为UAS的元素上缩短T1似乎可以改善这种特殊情况，但请记住，这些元素可能会在下一个请求中交换角色）。由于该协议没有提供发现/协商对等方计时器值的机制，因此在部署具有非默认值的系统时必须格外小心，以确保它们永远不会直接与具有默认值的元素通信。
This document describes some problems in the core SIP specification [1] related to the SIP non-INVITE requests, the messages other than INVITE that begin transactions. A few of the problems lead to flooding or forgery risk, and could possibly be exploited by an adversary in a denial of service attack. Solutions are defined in the companion document [4].
本文档描述了核心SIP规范[1]中与SIP非INVITE请求（开始事务的INVITE以外的消息）相关的一些问题。其中一些问题会导致洪水泛滥或伪造风险，并且可能会在拒绝服务攻击中被对手利用。配套文件[4]中定义了解决方案。
One solution there prohibits proxies and User Agents from sending 408 responses to non-INVITE transactions. Without this change, proxies automatically generate a storm of useless responses. An attacker could capitalize on this by enticing User Agents to send non-INVITE requests to a black hole (through social engineering or DNS poisoning) or by selectively dropping responses.
其中的一个解决方案禁止代理和用户代理向非邀请事务发送408响应。如果不进行此更改，代理将自动生成大量无用的响应。攻击者可以通过诱使用户代理将非邀请请求发送到黑洞（通过社会工程或DNS中毒）或有选择地丢弃响应来利用此漏洞。
Another solution prohibits proxies from forwarding late responses. Without this change, an attacker could easily forge messages which appear to be late responses. All proxies compliant with RFC 3261 are required to forward these responses, wasting bandwidth and CPU and potentially overwhelming target User Agents (especially those with low speed connections).
另一种解决方案禁止代理转发延迟响应。如果没有此更改，攻击者很容易伪造似乎是延迟响应的消息。所有符合RFC 3261的代理都需要转发这些响应，这会浪费带宽和CPU，并可能会压倒目标用户代理（尤其是那些具有低速连接的代理）。
This document captures many conversations about non-INVITE issues. Significant contributers include Ben Campbell, Gonzalo Camarillo, Steve Donovan, Rohan Mahy, Dan Petrie, Adam Roach, Jonathan Rosenberg, and Dean Willis.
本文档捕获了许多关于非邀请问题的对话。重要贡献者包括本·坎贝尔、冈萨洛·卡马里洛、史蒂夫·多诺万、罗汉·马伊、丹·佩特里、亚当·罗奇、乔纳森·罗森伯格和迪安·威利斯。
[1] Rosenberg, J., Schulzrinne, H., Camarillo, G., Johnston, A., Peterson, J., Sparks, R., Handley, M., and E. Schooler, "SIP: Session Initiation Protocol", RFC 3261, June 2002.
[1] Rosenberg，J.，Schulzrinne，H.，Camarillo，G.，Johnston，A.，Peterson，J.，Sparks，R.，Handley，M.，和E.Schooler，“SIP：会话启动协议”，RFC 3261，2002年6月。
[2] Rosenberg, J. and H. Schulzrinne, "Session Initiation Protocol (SIP): Locating SIP Servers", RFC 3263, June 2002.
[2] Rosenberg，J.和H.Schulzrinne，“会话启动协议（SIP）：定位SIP服务器”，RFC3263，2002年6月。
[3] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for specifying the location of services (DNS SRV)", RFC 2782, February 2000.
[3] Gulbrandsen，A.，Vixie，P.和L.Esibov，“用于指定服务位置（DNS SRV）的DNS RR”，RFC 2782，2000年2月。
[4] Sparks, R., "Actions Addressing Identified Issues with the Session Initiation Protocol's (SIP) Non-INVITE Transaction", RFC 4320, January 2006.
[4] Sparks，R.，“解决会话启动协议（SIP）非邀请事务已识别问题的措施”，RFC 4320，2006年1月。
Author's Address
作者地址
Robert J. Sparks Estacado Systems 17210 Campbell Road Suite 250 Dallas, TX 75252-4203
Robert J.Sparks Estacado Systems 17210坎贝尔路250号套房德克萨斯州达拉斯75252-4203
EMail: rjsparks@estacado.net
EMail: rjsparks@estacado.net
Full Copyright Statement
完整版权声明
Copyright (C) The Internet Society (2006).
版权所有（C）互联网协会（2006年）。
This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is provided by the IETF Administrative Support Activity (IASA).
RFC编辑器功能的资金由IETF行政支持活动（IASA）提供。