Network Working Group JP. Vasseur, Ed.
Request for Comments: 4971 N. Shen, Ed.
Category: Standards Track Cisco Systems, Inc.
R. Aggarwal, Ed.
Juniper Networks
July 2007
Network Working Group JP. Vasseur, Ed.
Request for Comments: 4971 N. Shen, Ed.
Category: Standards Track Cisco Systems, Inc.
R. Aggarwal, Ed.
Juniper Networks
July 2007
Intermediate System to Intermediate System (IS-IS) Extensions for Advertising Router Information
广告路由器信息的中间系统到中间系统（IS-IS）扩展
Status of This Memo
关于下段备忘
This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited.
本文件规定了互联网社区的互联网标准跟踪协议，并要求进行讨论和提出改进建议。有关本协议的标准化状态和状态，请参考当前版本的“互联网官方协议标准”（STD 1）。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This document defines a new optional Intermediate System to Intermediate System (IS-IS) TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain.
本文档定义了一个新的可选中间系统到中间系统（IS-IS）TLV命名功能，该功能由多个子TLV组成，允许路由器在IS-IS级别或整个路由域内宣布其功能。
Table of Contents
目录
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the
Capability TLV ..................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgment ..................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................8
1. Introduction ....................................................2
1.1. Conventions Used in This Document ..........................2
2. IS-IS Router CAPABILITY TLV .....................................3
3. Elements of Procedure ...........................................4
4. Interoperability with Routers Not Supporting the
Capability TLV ..................................................5
5. Security Considerations .........................................6
6. IANA Considerations .............................................6
7. Acknowledgment ..................................................6
8. References ......................................................6
8.1. Normative References .......................................6
8.2. Informative References .....................................8
There are several situations where it is useful for the IS-IS [IS-IS] [IS-IS-IP] routers to learn the capabilities of the other routers of their IS-IS level, area, or routing domain. For the sake of illustration, three examples related to MPLS Traffic Engineering (TE) are described here:
在一些情况下，is-is[is-is][is-is-IP]路由器了解其is-is级别、区域或路由域的其他路由器的能力是有用的。为了说明，这里描述了与MPLS流量工程（TE）相关的三个示例：
1. Mesh-group: the setting up of a mesh of TE Label Switched Paths (LSPs) [IS-IS-TE] requires some significant configuration effort. [AUTOMESH] proposes an auto-discovery mechanism whereby every Label Switching Router (LSR) of a mesh advertises its mesh-group membership by means of IS-IS extensions.
1. 网格组：设置TE标签交换路径（LSP）[IS-IS-TE]的网格需要一些重要的配置工作。[AUTOMESH]提出了一种自动发现机制，其中mesh的每个标签交换路由器（LSR）通过IS-IS扩展宣传其mesh组成员资格。
2. Point to Multipoint TE LSP (P2MP LSP). A specific sub-TLV ([TE-NODE-CAP]) allows an LSR to advertise its Point To Multipoint capabilities ([P2MP] and [P2MP-REQS]).
2. 点对多点TE LSP（P2MP LSP）。特定的子TLV（[TE-NODE-CAP]）允许LSR公布其点对多点能力（[P2MP]和[P2MP-REQS]）。
3. Inter-area traffic engineering: Advertisement of the IPv4 and/or the IPv6 Traffic Engineering Router IDs.
3. 区域间流量工程：公布IPv4和/或IPv6流量工程路由器ID。
The use of IS-IS for Path Computation Element (PCE) discovery may also be considered and will be discussed in the PCE WG.
也可考虑使用IS-IS进行路径计算元素（PCE）发现，并将在PCE工作组中讨论。
The capabilities mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
上述能力要求在本文件定义的能力TLV内配备新的子TLV规范。
Note that the examples above are provided for the sake of illustration. This document proposes a generic capability advertising mechanism that is not limited to MPLS Traffic Engineering.
请注意，以上示例仅用于说明。本文档提出了一种通用的能力广告机制，该机制不限于MPLS流量工程。
This document defines a new optional IS-IS TLV named CAPABILITY, formed of multiple sub-TLVs, which allows a router to announce its capabilities within an IS-IS level or the entire routing domain. The applications mentioned above require the specification of new sub-TLVs carried within the CAPABILITY TLV defined in this document.
本文档定义了一个新的可选IS-IS TLV命名功能，该功能由多个子TLV组成，允许路由器在IS-IS级别或整个路由域内宣布其功能。上述应用要求在本文件定义的TLV能力范围内配备新的子TLV规范。
Definition of these sub-TLVs is outside the scope of this document.
这些子TLV的定义不在本文件范围内。
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 [RFC-2119].
本文件中的关键词“必须”、“不得”、“要求”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照RFC 2119[RFC-2119]中的说明进行解释。
The IS-IS Router CAPABILITY TLV is composed of 1 octet for the type, 1 octet that specifies the number of bytes in the value field, and a variable length value field that starts with 4 octets of Router ID, indicating the source of the TLV, and followed by 1 octet of flags.
IS-IS路由器功能TLV由1个八位字节（表示类型）、1个八位字节（指定值字段中的字节数）和一个可变长度值字段组成，该字段以4个八位字节的路由器ID开头，表示TLV的源，后跟1个八位字节的标志。
A set of optional sub-TLVs may follow the flag field. Sub-TLVs are formatted as described in RFC 3784 [IS-IS-TE].
标志字段后面可能有一组可选的子TLV。子TLV的格式如RFC 3784[IS-IS-TE]所述。
TYPE: 242 LENGTH: from 5 to 255 VALUE: Router ID (4 octets) Flags (1 octet) Set of optional sub-TLVs (0-250 octets)
类型：242长度：从5到255值：路由器ID（4个八位字节）标志（1个八位字节）可选子TLV集（0-250个八位字节）
Flags
旗帜
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
0 1 2 3 4 5 6 7
+-+-+-+-+-+-+-+-+
| Reserved |D|S|
+-+-+-+-+-+-+-+-+
Currently two bit flags are defined.
目前定义了两位标志。
S bit (0x01): If the S bit is set(1), the IS-IS Router CAPABILITY TLV MUST be flooded across the entire routing domain. If the S bit is not set(0), the TLV MUST NOT be leaked between levels. This bit MUST NOT be altered during the TLV leaking.
S位（0x01）：如果设置了S位（1），则is-is路由器功能TLV必须覆盖整个路由域。如果未设置S位（0），则TLV不得在级别之间泄漏。TLV泄漏期间，不得更改该位。
D bit (0x02): When the IS-IS Router CAPABILITY TLV is leaked from level-2 to level-1, the D bit MUST be set. Otherwise, this bit MUST be clear. IS-IS Router capability TLVs with the D bit set MUST NOT be leaked from level-1 to level-2. This is to prevent TLV looping.
D位（0x02）：当IS-IS路由器功能TLV从2级泄漏到1级时，必须设置D位。否则，该位必须是清晰的。具有D位设置的IS-IS路由器功能TLV不得从1级泄漏到2级。这是为了防止TLV循环。
The Router CAPABILITY TLV is OPTIONAL. As specified in Section 3, more than one Router CAPABILITY TLV from the same source MAY be present.
路由器功能TLV是可选的。如第3节所述，可能存在来自同一来源的多个路由器能力TLV。
This document does not specify how an application may use the Router Capability TLV and such specification is outside the scope of this document.
本文档未指定应用程序如何使用路由器功能TLV，此类规范不在本文档范围内。
A router that generates a CAPABILITY TLV MUST have a Router ID that is a 32-bit number. The ID MUST be unique within the IS-IS area. If the router generates any capability TLVs with domain flooding scope, then the ID MUST also be unique within the IS-IS routing domain.
生成能力TLV的路由器必须具有32位的路由器ID。ID在IS-IS区域内必须是唯一的。如果路由器生成具有域泛洪作用域的任何功能TLV，则ID在IS-IS路由域中也必须是唯一的。
When advertising capabilities with different flooding scopes, a router MUST originate a minimum of two Router CAPABILITY TLVs, each TLV carrying the set of sub-TLVs with the same flooding scope. For instance, if a router advertises two sets of capabilities, C1 and C2, with an area/level scope and routing domain scope respectively, C1 and C2 being specified by their respective sub-TLV(s), the router will originate two Router CAPABILITY TLVs:
当使用不同泛洪作用域发布功能时，路由器必须至少发起两个路由器功能TLV，每个TLV承载具有相同泛洪作用域的子TLV集。例如，如果路由器播发两组功能C1和C2，其中区域/级别范围和路由域范围分别为C1和C2，C1和C2由各自的子TLV指定，则路由器将发起两个路由器功能TLV：
- One Router CAPABILITY TLV with the S flag cleared, carrying the sub-TLV(s) relative to C1. This Router CAPABILITY TLV will not be leaked into another level.
- 一个路由器功能TLV，清除S标志，携带相对于C1的子TLV。此路由器功能TLV不会泄漏到另一个级别。
- One Router CAPABILITY TLV with the S flag set, carrying the sub-TLV(s) relative to C2. This Router CAPABILITY TLV will be leaked into other IS-IS levels. When the TLV is leaked from level-2 to level-1, the D bit will be set in the level-1 LSP advertisement.
- 一个路由器能力TLV，带有S标志集，承载相对于C2的子TLV。此路由器功能TLV将泄漏到其他IS-IS级别。当TLV从2级泄漏到1级时，将在1级LSP播发中设置D位。
In order to prevent the use of stale capabilities, a system MUST NOT use a Capability TLV present in an LSP of a system that is not currently reachable via Level-x paths, where "x" is the level (1 or 2) in which the sending system advertised the TLV. This requirement applies regardless of whether or not the sending system is the originator of the Capabilities TLV. Note that leaking a Capabilities TLV is one of the uses that is prohibited under these conditions.
为了防止使用过时的功能，系统不得使用系统LSP中当前无法通过x级路径访问的功能TLV，其中“x”是发送系统播发TLV的级别（1或2）。无论发送系统是否为能力TLV的发起人，此要求均适用。请注意，泄漏TLV是这些条件下禁止的用途之一。
Example: If Level-1 router A generates a Capability TLV and floods it to two L1/L2 routers, S and T, they will flood it into the Level-2 domain. Now suppose the Level-1 area partitions, such that A and S are in one partition and T is in another. IP routing will still continue to work, but if A now issues a revised version of the CAP TLV, or decides to stop advertising it, S will follow suit, but T will continue to advertise the old version until the LSP times out.
示例：如果一级路由器A生成能力TLV并将其洪泛到两个L1/L2路由器S和T，则它们将其洪泛到二级域。现在假设1级区域分区，A和S在一个分区中，T在另一个分区中。IP路由仍将继续工作，但如果A现在发布CAP TLV的修订版本，或决定停止发布，S将跟进，但T将继续发布旧版本，直到LSP超时。
Routers in other areas have to choose whether to trust T's copy of A's capabilities or S's copy of A's information and, they have no reliable way to choose. By making sure that T stops leaking A's information, this removes the possibility that other routers will use stale information from A.
其他地区的路由器必须选择是信任T的A的能力副本还是信任s的A的信息副本，他们没有可靠的选择方法。通过确保T停止泄漏A的信息，这消除了其他路由器使用A的过时信息的可能性。
In IS-IS, the atomic unit of the update process is a TLV -- or more precisely, in the case of TLVs that allow multiple entries to appear in the value field (e.g., IS-neighbors), the atomic unit is an entry in the value field of a TLV. If an update to an entry in a TLV is advertised in an LSP fragment different from the LSP fragment associated with the old advertisement, the possibility exists that other systems can temporarily have either 0 copies of a particular advertisement or 2 copies of a particular advertisement, depending on the order in which new copies of the LSP fragment that had the old advertisement and the fragment that has the new advertisement arrive at other systems.
在IS-IS中，更新过程的原子单位是TLV——或者更准确地说，在TLV允许多个条目出现在值字段（例如，IS邻居）中的情况下，原子单位是TLV的值字段中的条目。如果在不同于与旧播发相关联的LSP片段的LSP片段中播发对TLV中的条目的更新，则存在其他系统可以临时具有特定播发的0个副本或特定播发的2个副本的可能性，取决于具有旧广告的LSP片段的新副本和具有新广告的片段到达其他系统的顺序。
Wherever possible, an implementation SHOULD advertise the update to a capabilities TLV in the same LSP fragment as the advertisement that it replaces. Where this is not possible, the two affected LSP fragments should be flooded as an atomic action.
在可能的情况下，实现应在与其替换的公告相同的LSP片段中公告对功能TLV的更新。在不可能的情况下，两个受影响的LSP片段应作为原子动作被淹没。
Systems that receive an update to an existing capability TLV can minimize the potential disruption associated with the update by employing a holddown time prior to processing the update so as to allow for the receipt of multiple LSP fragments associated with the same update prior to beginning processing.
接收对现有能力TLV的更新的系统可以通过在处理更新之前采用抑制时间来最小化与更新相关联的潜在中断，从而允许在开始处理之前接收与相同更新相关联的多个LSP片段。
Where a receiving system has two copies of a capabilities TLV from the same system that have different settings for a given attribute, the procedure used to choose which copy shall be used is undefined.
如果接收系统具有来自同一系统的两个能力TLV副本，且该系统对给定属性具有不同的设置，则用于选择应使用哪个副本的程序未定义。
Routers that do not support the Router CAPABILITY TLV MUST silently ignore the TLV(s) and continue processing other TLVs in the same LSP. Routers that do not support specific sub-TLVs carried within a Router CAPABILITY TLV MUST silently ignore the unsupported sub-TLVs and continue processing those sub-TLVs that are supported in the Router CAPABILITY TLV. How partial support may impact the operation of the capabilities advertised within the Router CAPABILITY TLV is outside the scope of this document.
不支持路由器功能TLV的路由器必须以静默方式忽略TLV，并继续在同一LSP中处理其他TLV。不支持路由器功能TLV中携带的特定子TLV的路由器必须静默忽略不支持的子TLV，并继续处理路由器功能TLV中支持的子TLV。部分支持如何影响路由器功能TLV中公布的功能的运行超出了本文档的范围。
In order for Router CAPABILITY TLVs with domain-wide scope originated by L1 Routers to be flooded across the entire domain, at least one L1/L2 Router in every area of the domain MUST support the Router CAPABILITY TLV.
为了使L1路由器发起的具有全域范围的路由器能力TLV在整个域中被淹没，域的每个区域中至少有一个L1/L2路由器必须支持路由器能力TLV。
If leaking of the CAPABILITY TLV is required, the entire CAPABILITY TLV MUST be leaked into another level even though it may contain some of the unsupported sub-TLVs.
如果需要泄漏能力TLV，则必须将整个能力TLV泄漏到另一个级别，即使它可能包含一些不受支持的子TLV。
Any new security issues raised by the procedures in this document depend upon the opportunity for LSPs to be snooped and modified, the ease/difficulty of which has not been altered. As the LSPs may now contain additional information regarding router capabilities, this new information would also become available to an attacker. Specifications based on this mechanism need to describe the security considerations around the disclosure and modification of their information. Note that an integrity mechanism, such as the one defined in [RFC-3567] or [IS-IS-HMAC], should be applied if there is high risk resulting from modification of capability information.
本文件中程序提出的任何新安全问题取决于LSP被窥探和修改的机会，其难易程度尚未改变。由于LSP现在可能包含有关路由器功能的其他信息，因此攻击者也可以使用这些新信息。基于此机制的规范需要描述有关信息披露和修改的安全注意事项。注意，如果修改能力信息导致高风险，则应采用完整性机制，如[RFC-3567]或[IS-IS-HMAC]中定义的机制。
IANA assigned a new IS-IS TLV code-point for the newly defined IS-IS TLV type named the IS-IS Router CAPABILITY TLV and defined in this document. The assigned value is 242.
IANA为新定义的IS-IS TLV类型分配了一个新的IS-IS TLV代码点，命名为IS-IS路由器能力TLV，并在本文档中定义。赋值为242。
The authors would like to thank Jean-Louis Le Roux, Paul Mabey, Andrew Partan, and Adrian Farrel for their useful comments.
作者要感谢让-路易斯·勒鲁、保罗·马比、安德鲁·帕坦和阿德里安·法雷尔的有用评论。
[RFC-2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[IS-IS] "Intermediate System to Intermediate System Intra-Domain Routeing Exchange Protocol for use in Conjunction with the Protocol for Providing the Connectionless-mode Network Service (ISO 8473)", ISO 10589.
[IS-IS]“与提供无连接模式网络服务的协议一起使用的中间系统到中间系统域内路由交换协议（ISO 8473）”，ISO 10589。
[RFC-3567] Li, T. and R. Atkinson, "Intermediate System to Intermediate System (IS-IS) Cryptographic Authentication", RFC 3567, July 2003.
[RFC-3567]Li，T.和R.Atkinson，“中间系统到中间系统（IS-IS）密码认证”，RFC 3567，2003年7月。
[IS-IS-IP] Callon, R., "Use of OSI IS-IS for routing in TCP/IP and dual environments", RFC 1195, December 1990.
[IS-IS-IP]Callon，R.，“OSI IS-IS在TCP/IP和双环境中的路由使用”，RFC1195，1990年12月。
[IS-IS-TE] Smit, H. and T. Li, "Intermediate System to Intermediate System (IS-IS) Extensions for Traffic Engineering (TE)", RFC 3784, June 2004.
[IS-IS-TE]Smit，H.和T.Li，“交通工程（TE）的中间系统到中间系统（IS-IS）扩展”，RFC 37842004年6月。
[AUTOMESH] Vasseur, JP., Ed., Le Roux, JL., Ed., Yasukawa, S., Previdi, S., Psenak, P., and P. Mabbey, "Routing extensions for Discovery of Multiprotocol (MPLS) Label Switch Router (LSR) Traffic Engineering (TE) Mesh Membership", RFC 4972, July 2007.
[AUTOMESH]Vasseur，JP.，Ed.，Le Roux，JL.，Ed.，Yasukawa，S.，Previdi，S.，Psenak，P.，和P.Mabbey，“发现多协议（MPLS）标签交换路由器（LSR）流量工程（TE）Mesh成员资格的路由扩展”，RFC 49722007年7月。
[TE-NODE-CAP] Vasseur, JP., Ed., and J.L. Le Roux, "Routing Extensions for Discovery of Traffic Engineering Node Capabilities", Work in Progress, April 2007.
[TE-NODE-CAP]Vasseur，JP.，Ed.，和J.L.Le Roux，“发现流量工程节点能力的路由扩展”，正在进行的工作，2007年4月。
[P2MP] Aggarwal, R., Ed., Papadimitriou, D., Ed., and S. Yasukawa, Ed., "Extensions to Resource Reservation Protocol - Traffic Engineering (RSVP-TE) for Point-to-Multipoint TE Label Switched Paths (LSPs)", RFC 4875, May 2007.
[P2MP]Aggarwal，R.，Ed.，Papadimitriou，D.，Ed.，和S.Yasukawa，Ed.，“资源预留协议的扩展-点对多点TE标签交换路径（LSP）的流量工程（RSVP-TE）”，RFC 4875，2007年5月。
[P2MP-REQS] Yasukawa, S., Ed., "Signaling Requirements for Point-to-Multipoint Traffic-Engineered MPLS Label Switched Paths (LSPs)", RFC 4461, April 2006.
[P2MP-REQS]Yasukawa，S.，Ed.“点对多点流量工程MPLS标签交换路径（LSP）的信令要求”，RFC 4461，2006年4月。
[IS-IS-HMAC] Bhatia, M., Ed. and V. Manral, Ed., "IS-IS Generic Cryptographic Authentication", Work in Progress, May 2007.
[IS-IS-HMAC]Bhatia，M.，Ed.和V.Manral，Ed.，“IS-IS通用密码认证”，正在进行的工作，2007年5月。
Authors' Addresses
作者地址
Jean-Philippe Vasseur CISCO Systems, Inc. 1414 Massachusetts Avenue Boxborough, MA 01719 USA EMail: jpv@cisco.com
Jean-Philippe Vasseur CISCO Systems，Inc.地址：美国马萨诸塞州伯斯堡马萨诸塞大道1414号邮编：01719电子邮件：jpv@cisco.com
Stefano Previdi CISCO Systems, Inc. Via Del Serafico 200 00142 - Roma ITALY EMail: sprevidi@cisco.com
Stefano Previdi CISCO Systems，Inc.通过Del Serafico 200 00142-意大利罗马电子邮件：sprevidi@cisco.com
Mike Shand Cisco Systems 250 Longwater Avenue, Reading, Berkshire, RG2 6GB UK EMail: mshand@cisco.com
Mike Shand Cisco Systems 250 Longwater Avenue，Reading，Berkshire，RG2 6GB英国电子邮件：mshand@cisco.com
Les Ginsberg Cisco Systems 510 McCarthy Blvd. Milpitas, Ca. 95035 USA EMail: ginsberg@cisco.com
莱斯金斯伯格思科系统公司，麦卡锡大道510号。加利福尼亚州米尔皮塔斯95035美国电子邮件：ginsberg@cisco.com
Acee Lindem Redback Networks 102 Carric Bend Court Cary, NC 27519 USA EMail: acee@redback.com
Acee Lindem Redback Networks 102美国北卡罗来纳州卡里克本德法院，邮编27519电子邮件：acee@redback.com
Naiming Shen Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA EMail: naiming@cisco.com
沈乃明思科系统225西塔斯曼大道圣何塞，加利福尼亚州95134美国电子邮件：naiming@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Avenue San Jose, CA 94089 USA EMail: rahul@juniper.net
Rahul Aggarwal Juniper Networks 1194 N.Mathilda Avenue San Jose，CA 94089美国电子邮件：rahul@juniper.net
Scott Shaffer EMail: sshaffer@bridgeport-networks.com
Scott Shaffer电子邮件：sshaffer@bridgeport-网络
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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。