Network Working Group L. Berger
Request for Comments: 5250 LabN
Obsoletes: 2370 I. Bryskin
Category: Standards Track Adva
A. Zinin
Alcatel-Lucent
R. Coltun
Acoustra Productions
July 2008
Network Working Group L. Berger
Request for Comments: 5250 LabN
Obsoletes: 2370 I. Bryskin
Category: Standards Track Adva
A. Zinin
Alcatel-Lucent
R. Coltun
Acoustra Productions
July 2008
The OSPF Opaque LSA Option
OSPF不透明LSA选项
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
摘要
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. Opaque LSAs consist of a standard LSA header followed by application-specific information. The information field may be used directly by OSPF or by other applications. Standard OSPF link-state database flooding mechanisms are used to distribute Opaque LSAs to all or some limited portion of the OSPF topology.
本文档定义了OSPF协议的增强功能，以支持称为不透明LSA的一类新的链路状态播发（LSA）。不透明LSA提供了一种通用机制，以允许OSPF未来的扩展性。不透明LSA由标准LSA头和应用程序特定信息组成。信息字段可由OSPF或其他应用程序直接使用。标准OSPF链路状态数据库泛洪机制用于将不透明LSA分发到OSPF拓扑的所有或某些有限部分。
This document replaces RFC 2370 and adds to it a mechanism to enable an OSPF router to validate Autonomous System (AS)-scope Opaque LSAs originated outside of the router's OSPF area.
本文档取代RFC 2370，并向其添加了一种机制，使OSPF路由器能够验证源自路由器OSPF区域之外的自治系统（AS）范围不透明LSA。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Organization of This Document ..............................3
1.2. Acknowledgments ............................................3
2. Conventions Used in This Document ...............................4
3. The Opaque LSA ..................................................4
3.1. Flooding Opaque LSAs .......................................5
3.2. Modifications to the Neighbor State Machine ................6
4. Protocol Data Structures ........................................7
4.1. Additions to the OSPF Neighbor Structure ...................8
5. Inter-Area Considerations .......................................8
6. Management Considerations .......................................9
7. Backward Compatibility ..........................................9
8. Security Considerations .........................................9
9. IANA Considerations ............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Appendix A. OSPF Data formats .....................................13
A.1. The Options Field .........................................13
A.2. The Opaque LSA ............................................14
1. Introduction ....................................................3
1.1. Organization of This Document ..............................3
1.2. Acknowledgments ............................................3
2. Conventions Used in This Document ...............................4
3. The Opaque LSA ..................................................4
3.1. Flooding Opaque LSAs .......................................5
3.2. Modifications to the Neighbor State Machine ................6
4. Protocol Data Structures ........................................7
4.1. Additions to the OSPF Neighbor Structure ...................8
5. Inter-Area Considerations .......................................8
6. Management Considerations .......................................9
7. Backward Compatibility ..........................................9
8. Security Considerations .........................................9
9. IANA Considerations ............................................11
10. References ....................................................12
10.1. Normative References .....................................12
10.2. Informative References ...................................12
Appendix A. OSPF Data formats .....................................13
A.1. The Options Field .........................................13
A.2. The Opaque LSA ............................................14
Over the last several years, the OSPF routing protocol [OSPF] has been widely deployed throughout the Internet. As a result of this deployment and the evolution of networking technology, OSPF has been extended to support many options; this evolution will obviously continue.
在过去的几年中，OSPF路由协议[OSPF]已经在整个互联网上广泛部署。由于这种部署和网络技术的发展，OSPF已经扩展到支持许多选项；这种演变显然将继续下去。
This document defines enhancements to the OSPF protocol to support a new class of link state advertisements (LSAs) called Opaque LSAs. Opaque LSAs provide a generalized mechanism to allow for the future extensibility of OSPF. The information contained in Opaque LSAs may be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The exact use of Opaque LSAs is beyond the scope of this document.
本文档定义了OSPF协议的增强功能，以支持称为不透明LSA的一类新的链路状态播发（LSA）。不透明LSA提供了一种通用机制，以允许OSPF未来的扩展性。不透明LSA中包含的信息可由OSPF直接使用，或由希望在整个OSPF域中分发信息的某些应用程序间接使用。不透明LSA的确切使用超出了本文档的范围。
Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific information field. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. The link-state type field of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the flooding scope.
不透明LSA由一个标准LSA头和一个32位对齐的应用程序特定信息字段组成。与任何其他LSA一样，不透明LSA使用链路状态数据库分发机制在整个拓扑中传播此信息。不透明LSA的链接状态类型字段标识LSA的拓扑分布范围。该范围称为泛洪范围。
It is envisioned that an implementation of the Opaque option provides an application interface for 1) encapsulating application-specific information in a specific Opaque type, 2) sending and receiving application-specific information, and 3) if required, informing the application of the change in validity of previously received information when topological changes are detected.
可以设想，不透明选项的实现提供了一个应用程序接口，用于1）将特定于应用程序的信息封装在特定的不透明类型中，2）发送和接收特定于应用程序的信息，以及3）如果需要，当检测到拓扑变化时，通知应用程序先前接收信息的有效性变化。
This document first defines the three types of Opaque LSAs followed by a description of OSPF packet processing. The packet processing sections include modifications to the flooding procedure and to the neighbor state machine. Appendix A then gives the packet formats.
本文档首先定义了三种不透明LSA，然后描述了OSPF数据包处理。分组处理部分包括对泛洪过程和相邻状态机的修改。附录A给出了数据包格式。
We would like to thank Acee Lindem for his detailed review and useful feedback. The handling of AS-scope Opaque LSAs described in this document is taken from "Validation of OSPF AS-scope opaque LSAs" (April 2006).
我们要感谢Acee Lindem的详细审查和有用的反馈。本文件中所述的范围不透明LSA的处理取自“OSPF范围不透明LSA的验证”（2006年4月）。
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 [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
Opaque LSAs are types 9, 10, and 11 link state advertisements. Opaque LSAs consist of a standard LSA header followed by a 32-bit aligned application-specific information field. Standard link-state database flooding mechanisms are used for distribution of Opaque LSAs. The range of topological distribution (i.e., the flooding scope) of an Opaque LSA is identified by its link-state type. This section documents the flooding of Opaque LSAs.
不透明LSA是类型9、10和11链路状态播发。不透明LSA由一个标准LSA头和一个32位对齐的应用程序特定信息字段组成。标准链路状态数据库泛洪机制用于不透明LSA的分发。不透明LSA的拓扑分布范围（即泛洪范围）由其链路状态类型确定。本节记录了不透明LSA的泛滥情况。
The flooding scope associated with each Opaque link-state type is defined as follows.
与每个不透明链接状态类型关联的泛洪范围定义如下。
o Link-state type-9 denotes a link-local scope. Type-9 Opaque LSAs are not flooded beyond the local (sub)network.
o 链路状态类型-9表示链路本地范围。9类不透明LSA不会淹没在本地（子）网络之外。
o Link-state type-10 denotes an area-local scope. Type-10 Opaque LSAs are not flooded beyond the borders of their associated area.
o 链路状态类型-10表示区域局部范围。10型不透明LSA不会淹没在其相关区域的边界之外。
o Link-state type-11 denotes that the LSA is flooded throughout the Autonomous System (AS). The flooding scope of type-11 LSAs are equivalent to the flooding scope of AS-External (type-5) LSAs. Specifically, type-11 Opaque LSAs are 1) flooded throughout all transit areas, 2) not flooded into stub areas or Not-So-Stubby Areas (NSSAs), see [NSSA], from the backbone, and 3) not originated by routers into their connected stub areas or NSSAs. As with type-5 LSAs, if a type-11 Opaque LSA is received in a stub area or NSSA from a neighboring router within the stub area or NSSA, the LSA is rejected.
o 链路状态类型-11表示LSA被淹没在整个自治系统（AS）中。11型LSA的泛洪范围相当于AS外部（5型）LSA的泛洪范围。具体而言，11型不透明LSA 1）淹没在所有传输区域，2）未淹没到存根区域或非存根区域（NSSA），参见[NSSA]，从主干，以及3）未由路由器发起到其连接的存根区域或NSSA。与5型LSA一样，如果在存根区域或NSSA中从存根区域或NSSA内的相邻路由器接收到11型不透明LSA，则LSA将被拒绝。
The link-state ID of the Opaque LSA is divided into an Opaque type field (the first 8 bits) and a type-specific ID (the remaining 24 bits). The packet format of the Opaque LSA is given in Appendix A. Section 7 describes Opaque type allocation and assignment.
不透明LSA的链路状态ID分为不透明类型字段（前8位）和特定类型ID（剩余24位）。不透明LSA的数据包格式见附录A。第7节描述了不透明类型分配和分配。
The responsibility for proper handling of the Opaque LSA's flooding scope is placed on both the sender and receiver of the LSA. The receiver must always store a valid received Opaque LSA in its link-state database. The receiver must not accept Opaque LSAs that violate the flooding scope (e.g., a type-11 (domain-wide) Opaque LSA
正确处理不透明LSA泛洪范围的责任由LSA的发送方和接收方承担。接收方必须始终在其链路状态数据库中存储有效的接收到的不透明LSA。接收方不得接受违反泛洪范围的不透明LSA（例如，类型11（域范围）不透明LSA
is not accepted in a stub area or NSSA). The flooding scope affects both the synchronization of the link-state database and the flooding procedure.
在存根区域或NSSA中不被接受）。泛洪范围影响链路状态数据库的同步和泛洪过程。
The following describes the modifications to these procedures that are necessary to insure conformance to the Opaque LSA's Scoping Rules.
以下描述了为确保符合不透明LSA的范围规则而对这些程序进行的必要修改。
The flooding of Opaque LSAs MUST follow the rules of flooding scope as specified in this section. Section 13 of [OSPF] describes the OSPF flooding procedure. Those procedures MUST be followed as defined except where modified in this section. The following describes the Opaque LSA's type-specific flooding restrictions.
不透明LSA的泛光必须遵循本节规定的泛光范围规则。[OSPF]第13节描述了OSPF注水程序。除非本节有修改，否则必须按照规定执行这些程序。下面介绍不透明LSA的特定类型泛洪限制。
o If the Opaque LSA is type-9 (the flooding scope is link-local) and the interface that the LSA was received on is not the same as the target interface (e.g., the interface associated with a particular target neighbor), the Opaque LSA MUST be discarded and not acknowledged. An implementation SHOULD keep track of the IP interface associated with each Opaque LSA having a link-local flooding scope.
o 如果不透明LSA的类型为9（泛洪作用域为链路本地），并且接收LSA的接口与目标接口（例如，与特定目标邻居关联的接口）不同，则必须丢弃不透明LSA，并且不确认。实现应该跟踪与具有链路本地泛洪作用域的每个不透明LSA关联的IP接口。
o If the Opaque LSA is type-10 (the flooding scope is area-local) and the area associated with the Opaque LSA (as identified during origination or from a received LSA's associated OSPF packet header) is not the same as the area associated with the target interface, the Opaque LSA MUST be discarded and not acknowledged. An implementation SHOULD keep track of the OSPF area associated with each Opaque LSA having an area-local flooding scope.
o 如果不透明LSA的类型为10（泛洪范围为区域本地），且与不透明LSA相关的区域（在发起期间或从接收到的LSA的相关OSPF数据包头中识别）与与与目标接口相关的区域不相同，则必须丢弃不透明LSA且不确认。实施应跟踪与具有区域局部泛洪范围的每个不透明LSA相关联的OSPF区域。
o If the Opaque LSA is type-11 (the LSA is flooded throughout the AS) and the target interface is associated with a stub area or NSSA, the Opaque LSA MUST NOT be flooded out the interface. A type-11 Opaque LSA that is received on an interface associated with a stub area or NSSA MUST be discarded and not acknowledged (the neighboring router has flooded the LSA in error).
o 如果不透明LSA为11型（LSA在整个AS中被淹没），且目标接口与存根区域或NSSA关联，则不透明LSA不得淹没在接口之外。在与存根区域或NSSA相关联的接口上接收到的11型不透明LSA必须丢弃且不确认（相邻路由器错误地淹没了LSA）。
When opaque-capable routers and non-opaque-capable OSPF routers are mixed together in a routing domain, the Opaque LSAs are typically not flooded to the non-opaque-capable routers. As a general design principle, optional OSPF advertisements are only flooded to those routers that understand them.
当在路由域中将具有不透明能力的路由器和具有非不透明能力的OSPF路由器混合在一起时，不透明LSA通常不会淹没到具有非不透明能力的路由器。作为一般的设计原则，可选的OSPF广告只会大量出现在理解它们的路由器上。
An opaque-capable router learns of its neighbor's opaque capability at the beginning of the "Database Exchange Process" (see Section 10.6 of [OSPF] regarding receiving Database Description packets from a
具有不透明功能的路由器在“数据库交换过程”开始时了解其邻居的不透明功能（参见[OSPF]第10.6节关于从路由器接收数据库描述数据包的内容）
neighbor in state ExStart). A neighbor is opaque-capable if and only if it sets the O-bit in the Options field of its Database Description packets; the O-bit SHOULD NOT be set and MUST be ignored when received in packets other than Database Description packets. Using the O-bit in OSPF packets other than Database Description packets will result in interoperability issues. The setting of the O-bit is a "SHOULD NOT" rather than a "MUST NOT" to remain compatible with earlier specifications.
邻居处于状态（ExStart）。当且仅当邻居在其数据库描述数据包的选项字段中设置O位时，该邻居才具有不透明能力；不应设置O位，并且在数据库描述数据包以外的数据包中接收时必须忽略O位。在OSPF数据包中使用O位而不是数据库描述数据包将导致互操作性问题。O位的设置为“不应”而非“不得”，以保持与早期规范兼容。
In the next step of the Database Exchange process, Opaque LSAs are included in the Database summary list that is sent to the neighbor (see Sections 3.2 below and 10.3 of [OSPF]) when the neighbor is opaque capable.
在数据库交换过程的下一步中，当邻居具有不透明能力时，不透明LSA将包含在发送给邻居的数据库摘要列表中（请参见下文第3.2节和[OSPF]第10.3节）。
When flooding Opaque LSAs to adjacent neighbors, an opaque-capable router looks at the neighbor's opaque capability. Opaque LSAs are only flooded to opaque-capable neighbors. To be more precise, in Section 13.3 of [OSPF], Opaque LSAs MUST be placed on the link-state retransmission lists of opaque-capable neighbors and MUST NOT be placed on the link-state retransmission lists of non-opaque-capable neighbors. However, when sending Link State Update packets as multicasts, a non-opaque-capable neighbor may (inadvertently) receive Opaque LSAs. The non-opaque-capable router will then simply discard the LSA (see Section 13 of [OSPF] regarding receiving LSAs having unknown LS types).
将不透明LSA泛洪到相邻邻居时，具有不透明功能的路由器会查看邻居的不透明功能。不透明LSA仅被淹没到具有不透明功能的邻居。更准确地说，在[OSPF]第13.3节中，不透明LSA必须放在不透明邻居的链路状态重传列表上，而不能放在非不透明邻居的链路状态重传列表上。然而，当作为多播发送链路状态更新包时，具有非不透明能力的邻居可能（无意中）接收不透明LSA。非不透明路由器随后将简单地丢弃LSA（参见[OSPF]关于接收具有未知LS类型的LSA的第13节）。
Information contained in received Opaque LSAs SHOULD only be used when the router originating the LSA is reachable. As mentioned in [OSPFv3], reachability validation MAY be done less frequently than every SPF calculation. Additionally, routers processing received Opaque LSAs MAY choose to give priority to processing base OSPF LSA types over Opaque LSA types.
接收到的不透明LSA中包含的信息应仅在发起LSA的路由器可访问时使用。如[OSPFv3]所述，可达性验证的频率可能低于每次SPF计算。此外，处理接收到的不透明LSA的路由器可以选择优先处理基本OSPF LSA类型而不是不透明LSA类型。
The state machine as it exists in Section 10.3 of [OSPF] remains unchanged except for the action associated with State: ExStart, Event: NegotiationDone, which is where the Database summary list is built. To incorporate the Opaque LSA in OSPF, this action is changed to the following.
[OSPF]第10.3节中存在的状态机保持不变，但与state:ExStart、Event:NegotiationDone关联的操作除外，该操作是构建数据库摘要列表的地方。要将不透明LSA合并到OSPF中，此操作更改为以下内容。
State(s): ExStart
国家：ExStart
Event: NegotiationDone
事件：协商完成
New state: Exchange
新国家：交易所
Action: The router MUST list the contents of its entire area link-state database in the neighbor Database summary list. The area link-state database consists of the Router LSAs, Network LSAs, Summary LSAs, type-9 Opaque LSAs, and type-10 Opaque LSAs contained in the area structure, along with AS External and type-11 Opaque LSAs contained in the global structure. AS External and type-11 Opaque LSAs MUST be omitted from a virtual neighbor's Database summary list. AS External LSAs and type-11 Opaque LSAs MUST be omitted from the Database summary list if the area has been configured as a stub area or NSSA (see Section 3.6 of [OSPF]).
措施：路由器必须在邻居数据库摘要列表中列出其整个区域链路状态数据库的内容。区域链路状态数据库包括区域结构中包含的路由器LSA、网络LSA、摘要LSA、类型9不透明LSA和类型10不透明LSA，以及全局结构中包含的外部LSA和类型11不透明LSA。必须从虚拟邻居的数据库摘要列表中省略AS External和type-11不透明LSA。如果该区域已配置为存根区域或NSSA（见[OSPF]第3.6节），则必须从数据库摘要列表中删除AS外部LSA和11型不透明LSA。
Type-9 Opaque LSAs MUST be omitted from the Database summary list if the interface associated with the neighbor is not the interface associated with the Opaque LSA (as noted upon reception).
如果与邻居关联的接口不是与不透明LSA关联的接口（如接收时所述），则必须从数据库摘要列表中省略类型9不透明LSA。
Any advertisement whose age is equal to MaxAge MUST be omitted from the Database summary list. It MUST instead be added to the neighbor's link-state retransmission list. A summary of the Database summary list will be sent to the neighbor in Database Description packets. Only one Database Description Packet is allowed to be outstanding at any one time. For more detail on the sending and receiving of Database Description packets, see Sections 10.6 and 10.8 of [OSPF].
必须从数据库摘要列表中删除其年龄等于MaxAge的任何播发。它必须添加到邻居的链路状态重传列表中。数据库摘要列表的摘要将在数据库描述数据包中发送给邻居。一次只允许有一个数据库描述数据包未完成。有关发送和接收数据库描述数据包的更多详细信息，请参阅[OSPF]第10.6节和第10.8节。
The Opaque option is described herein in terms of its operation on various protocol data structures. These data structures are included for explanatory uses only. They are not intended to constrain an implementation. In addition to the data structures listed below, this specification references the various data structures (e.g., OSPF neighbors) defined in [OSPF].
本文描述了不透明选项在各种协议数据结构上的操作。这些数据结构仅用于说明用途。它们不是为了约束实现。除了下面列出的数据结构外，本规范还引用了[OSPF]中定义的各种数据结构（例如，OSPF邻居）。
In an OSPF router, the following item is added to the list of global OSPF data structures described in Section 5 of [OSPF]:
在OSPF路由器中，以下项目添加到[OSPF]第5节中描述的全局OSPF数据结构列表中：
o Opaque capability. Indicates whether the router is running the Opaque option (i.e., capable of storing Opaque LSAs). Such a router will continue to interoperate with non-opaque-capable OSPF routers.
o 不透明能力。指示路由器是否正在运行不透明选项（即，能够存储不透明LSA）。这种路由器将继续与非不透明的OSPF路由器进行互操作。
The OSPF neighbor structure is defined in Section 10 of [OSPF]. In an opaque-capable router, the following items are added to the OSPF neighbor structure:
[OSPF]第10节定义了OSPF邻居结构。在具有不透明功能的路由器中，将以下项目添加到OSPF邻居结构中：
o Neighbor Options. This field was already defined in the OSPF specification. However, in opaque-capable routers, there is a new option that indicates the neighbor's Opaque capability. This new option is learned in the Database Exchange process through reception of the neighbor's Database Description packets and determines whether Opaque LSAs are flooded to the neighbor. For a more detailed explanation of the flooding of the Opaque LSA, see Section 3 of this document.
o 邻居选择。此字段已在OSPF规范中定义。然而，在具有不透明功能的路由器中，有一个新选项指示邻居的不透明功能。在数据库交换过程中，通过接收邻居的数据库描述数据包来学习这个新选项，并确定不透明LSA是否被淹没到邻居。有关不透明LSA泛洪的更详细解释，请参阅本文件第3节。
As defined above, link-state type-11 Opaque LSAs are flooded throughout the Autonomous System (AS). One issue related to such AS-scoped Opaque LSAs is that there must be a way for OSPF routers in remote areas to check availability of the LSA originator. Specifically, if an OSPF router originates a type-11 LSA and, after that, goes out of service, OSPF routers located outside of the originator's OSPF area have no way of detecting this fact and may use the stale information for a considerable period of time (up to 60 minutes). This could prove to be suboptimal for some applications and may result in others not functioning.
如上所述，链路状态类型11不透明LSA被淹没在整个自治系统（As）中。与作用域不透明LSA相关的一个问题是，远程区域的OSPF路由器必须有一种方法来检查LSA发起者的可用性。具体地说，如果OSPF路由器发起11型LSA，然后停止服务，则位于发起人的OSPF区域之外的OSPF路由器无法检测到这一事实，并且可能会在相当长的一段时间（最多60分钟）内使用陈旧信息。对于某些应用程序，这可能被证明是次优的，并可能导致其他应用程序无法运行。
Type-9 Opaque LSAs and type-10 Opaque LSAs do not have this problem as a receiving router can detect if the advertising router is reachable within the LSA's respective flooding scope. In the case of type-9 LSAs, the originating router must be an OSPF neighbor in Exchange state or greater. In the case of type-10 Opaque LSAs, the intra-area SPF calculation will determine the advertising router's reachability.
类型9不透明LSA和类型10不透明LSA没有这个问题，因为接收路由器可以检测到广告路由器是否在LSA各自的泛洪范围内可到达。对于9型LSA，发起路由器必须是处于交换状态或更高状态的OSPF邻居。在10型不透明LSA的情况下，区域内SPF计算将确定广告路由器的可达性。
There is a parallel issue in OSPF for the AS-scoped AS External LSAs (type-5 LSAs). OSPF addresses this by using AS border information advertised in AS boundary router (ASBR) Summary LSAs (type-4 LSAs); see Section 16.4 of [OSPF]. This same mechanism is reused by this document for type-11 Opaque LSAs.
对于作用域为外部LSA（类型5 LSA）的AS，OSPF中存在一个并行问题。OSPF通过使用AS边界路由器（ASBR）摘要LSA（类型4 LSA）中公布的作为边界信息来解决此问题；见[OSPF]第16.4节。本文档对11型不透明LSA重复使用了相同的机制。
To enable OSPF routers in remote areas to check availability of the originator of link-state type-11 Opaque LSAs, the originators advertise themselves as ASBRs. This will enable routers to track the reachability of the LSA originator either directly via the SPF calculation (for routers in the same area) or indirectly via type-4 LSAs originated by ABRs (for routers in other areas). It is
为了使远程地区的OSPF路由器能够检查链路状态类型11不透明LSA的发起人的可用性，发起人将自己宣传为ASBR。这将使路由器能够直接通过SPF计算（针对同一区域的路由器）或间接通过ABR发起的4型LSA（针对其他区域的路由器），跟踪LSA发起人的可达性。它是
important to note that per [OSPF], this solution does not apply to OSPF stub areas or NSSAs as AS-scoped Opaque LSAs are not flooded into these area types.
重要的是要注意，根据[OSPF]，此解决方案不适用于OSPF存根区域或NSSA，因为作用域不透明LSA不会淹没到这些区域类型中。
The procedures related to inter-area Opaque LSAs are as follows:
与区域间不透明LSA相关的程序如下：
(1) An OSPF router that is configured to originate AS-scope opaque LSAs will advertise itself as an ASBR and MUST follow the requirements related to setting of the Options field E-bit in OSPF LSA headers as specified in [OSPF].
(1) 配置为作为作用域不透明LSA发起的OSPF路由器将作为ASBR进行宣传，并且必须遵循[OSPF]中规定的与OSPF LSA报头中选项字段E位设置相关的要求。
(2) When processing a received type-11 Opaque LSA, the router MUST look up the routing table entries (potentially one per attached area) for the ASBR that originated the LSA. If no entries exist for the ASBR (i.e., the ASBR is unreachable), the router MUST do nothing with this LSA. It also MUST discontinue using all Opaque LSAs injected into the network by the same originator whenever it is detected that the originator is unreachable.
(2) 当处理接收到的11型不透明LSA时，路由器必须为发起LSA的ASBR查找路由表条目（可能每个连接区域一个）。如果ASBR不存在条目（即ASBR不可访问），路由器不得对此LSA执行任何操作。当检测到无法联系到发起人时，它还必须停止使用由同一发起人注入网络的所有不透明LSA。
The updated OSPF MIB, [RFC4750], provides explicit support for Opaque LSAs and SHOULD be used to support implementations of this document. See Section 12.3 of [RFC4750] for details. In addition to that section, implementations supporting [RFC4750] will also include Opaque LSAs in all appropriate generic LSA objects, e.g., ospfOriginateNewLsas and ospfLsdbTable.
更新的OSPF MIB[RFC4750]提供了对不透明LSA的明确支持，应用于支持本文档的实现。详见[RFC4750]第12.3节。除此之外，支持[RFC4750]的实现还将在所有适当的通用LSA对象中包括不透明LSA，例如OSPForiginateNEWLSA和ospfLsdbTable。
The solution proposed in this document introduces no interoperability issues. In the case that a non-opaque-capable neighbor receives Opaque LSAs, per [OSPF], the non-opaque-capable router will simply discard the LSA.
本文档中提出的解决方案不会引入互操作性问题。在非不透明邻居根据[OSPF]接收不透明LSA的情况下，非不透明路由器将简单地丢弃LSA。
Note that OSPF routers that implement [RFC2370] will continue using stale type-11 LSAs even when the LSA originator implements the inter-area procedures described in Section 6 of this document.
请注意，即使LSA发起人实施本文件第6节所述的区域间程序，实施[RFC2370]的OSPF路由器仍将继续使用过时的11型LSA。
There are two types of issues that need be addressed when looking at protecting routing protocols from misconfigurations and malicious attacks. The first is authentication and certification of routing protocol information. The second is denial-of-service attacks resulting from repetitive origination of the same router advertisement or origination of a large number of distinct advertisements resulting in database overflow. Note that both of
在研究如何保护路由协议免受错误配置和恶意攻击时，有两类问题需要解决。首先是路由协议信息的身份验证和认证。第二种是拒绝服务攻击，这是由于重复发起同一路由器广告或发起大量不同的广告导致数据库溢出而造成的。请注意，这两个
these concerns exist independently of a router's support for the Opaque option.
这些问题独立于路由器对不透明选项的支持而存在。
To address the authentication concerns, OSPF protocol exchanges are authenticated. OSPF supports multiple types of authentication; the type of authentication in use can be configured on a per-network-segment basis. One of OSPF's authentication types, namely the Cryptographic authentication option, is believed to be secure against passive attacks and provide significant protection against active attacks. When using the Cryptographic authentication option, each router appends a "message digest" to its transmitted OSPF packets. Receivers then use the shared secret key and received digest to verify that each received OSPF packet is authentic.
为了解决身份验证问题，对OSPF协议交换进行身份验证。OSPF支持多种类型的认证；可以基于每个网段配置使用中的身份验证类型。OSPF的一种身份验证类型，即加密身份验证选项，被认为对被动攻击是安全的，并对主动攻击提供重要保护。当使用加密身份验证选项时，每个路由器在其传输的OSPF数据包中附加一个“消息摘要”。然后，接收器使用共享密钥和接收摘要来验证每个接收到的OSPF数据包是真实的。
The quality of the security provided by the Cryptographic authentication option depends completely on the strength of the message digest algorithm (MD5 is currently the only message digest algorithm specified), the strength of the key being used, and the correct implementation of the security mechanism in all communicating OSPF implementations. It also requires that all parties maintain the secrecy of the shared secret key. None of the standard OSPF authentication types provide confidentiality. Nor do they protect against traffic analysis. For more information on the standard OSPF security mechanisms, see Sections 8.1, 8.2, and Appendix D of [OSPF].
加密身份验证选项提供的安全性质量完全取决于消息摘要算法的强度（MD5目前是唯一指定的消息摘要算法）、所用密钥的强度以及所有通信OSPF实现中安全机制的正确实现。它还要求各方维护共享密钥的保密性。标准的OSPF身份验证类型都不提供机密性。它们也不能防止流量分析。有关标准OSPF安全机制的更多信息，请参见[OSPF]第8.1、8.2节和附录D。
Repetitive origination of advertisements is addressed by OSPF by mandating a limit on the frequency that new instances of any particular LSA can be originated and accepted during the flooding procedure. The frequency at which new LSA instances may be originated is set equal to once every MinLSInterval seconds, whose value is 5 seconds (see Section 12.4 of [OSPF]). The frequency at which new LSA instances are accepted during flooding is once every MinLSArrival seconds, whose value is set to 1 (see Section 13, Appendix B, and G.5 of [OSPF]).
OSPF通过强制规定在泛洪程序期间可以发起和接受任何特定LSA的新实例的频率限制来解决广告的重复发起问题。新LSA实例产生的频率设置为每分钟间隔秒一次，其值为5秒（见[OSPF]第12.4节）。泛洪期间接受新LSA实例的频率为每分钟LSA到达秒一次，其值设置为1（见[OSPF]第13节附录B和G.5）。
Proper operation of the OSPF protocol requires that all OSPF routers maintain an identical copy of the OSPF link-state database. However, when the size of the link-state database becomes very large, some routers may be unable to keep the entire database due to resource shortages; we term this "database overflow". When database overflow is anticipated, the routers with limited resources can be accommodated by configuring OSPF stub areas and NSSAs. [OVERFLOW] details a way of gracefully handling unanticipated database overflows.
OSPF协议的正确运行要求所有OSPF路由器维护OSPF链路状态数据库的相同副本。然而，当链路状态数据库的大小变得非常大时，一些路由器可能由于资源短缺而无法保留整个数据库；我们称之为“数据库溢出”。当预期数据库溢出时，可以通过配置OSPF存根区域和NSSA来适应资源有限的路由器。[OVERFLOW]详细介绍了一种优雅地处理意外数据库溢出的方法。
In the case of type-11 Opaque LSAs, this document reuses an ASBR tracking mechanism that is already employed in basic OSPF for type-5 LSAs. Therefore, applying it to type-11 Opaque LSAs does not create any threats that are not already known for type-5 LSAs.
在11型不透明LSA的情况下，本文档重用了ASBR跟踪机制，该机制已在5型LSA的基本OSPF中使用。因此，将其应用于11型不透明LSA不会产生任何5型LSA未知的威胁。
This document updates the requirements for the OSPF Opaque LSA type registry. Three following changes have been made:
本文件更新了OSPF不透明LSA类型注册表的要求。进行了以下三项更改：
1. References to [RFC2370] have been replaced with references to this document.
1. 参考文献[RFC2370]已替换为本文件参考文献。
2. The Opaque type values in the range of 128-255 have been reserved for "Private Use" as defined in [RFC5226].
2. 128-255范围内的不透明类型值已保留为[RFC5226]中定义的“专用”。
3. The reference for Opaque type registry value 1, Traffic Engineering LSA, has been updated to [RFC3630].
3. 不透明类型注册表值1“流量工程LSA”的参考已更新为[RFC3630]。
The registry now reads:
注册表现在显示：
Open Shortest Path First (OSPF) Opaque Link-State Advertisements (LSA) Option Types
开放最短路径优先（OSPF）不透明链路状态播发（LSA）选项类型
Registries included below: - Opaque Link-State Advertisements (LSA) Option Types
下面包含的注册表：-不透明链接状态播发（LSA）选项类型
Registry Name: Opaque Link-State Advertisements (LSA) Option Types
Reference: [RFC5250]
Range Registration Procedures Notes
-------- ------------------------------------------ --------
0-127 IETF Consensus
128-255 Private Use
Registry Name: Opaque Link-State Advertisements (LSA) Option Types
Reference: [RFC5250]
Range Registration Procedures Notes
-------- ------------------------------------------ --------
0-127 IETF Consensus
128-255 Private Use
Registry:
Value Opaque Type Reference
------- ------------------------------------------ ---------
1 Traffic Engineering LSA [RFC3630]
2 Sycamore Optical Topology Descriptions [Moy]
3 grace-LSA [RFC3623]
4 Router Information (RI) [RFC4970]
5-127 Unassigned
128-255 Private Use
Registry:
Value Opaque Type Reference
------- ------------------------------------------ ---------
1 Traffic Engineering LSA [RFC3630]
2 Sycamore Optical Topology Descriptions [Moy]
3 grace-LSA [RFC3623]
4 Router Information (RI) [RFC4970]
5-127 Unassigned
128-255 Private Use
[DEMD] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[DEMD]Moy，J.，“扩展OSPF以支持需求电路”，RFC 1793，1995年4月。
[OSPF] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPF]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[RFC2119] Bradner, S., "Key words for use in RFCs to indicate requirements levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, December 2006.
[RFC4750]Joyal，D.，Ed.，Galecki，P.，Ed.，Giacalone，S.，Ed.，Coltun，R.，和F.Baker，“OSPF版本2管理信息库”，RFC 47502006年12月。
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008.
[RFC5226]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF]Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[NSSA] Murphy P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA]Murphy P.，“OSPF不那么短的区域（NSSA）选项”，RFC 3101，2003年1月。
[OSPF-MT] Psenak, P., Mirtorabi, S., Roy, A., Nguyen, L., and P. Pillay-Esnault, "Multi-Topology (MT) Routing in OSPF", RFC 4915, June 2007.
[OSPF-MT]Psenak，P.，Mirtorabi，S.，Roy，A.，Nguyen，L.，和P.Pillay Esnault，“OSPF中的多拓扑（MT）路由”，RFC 4915，2007年6月。
[OSPFv3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, Ed., "OSPF for IPv6", Work in Progress, May 2008.
[OSPFv3]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，Ed.，“用于IPv6的OSPF”，正在进行的工作，2008年5月。
[OVERFLOW] Moy, J., "OSPF Database Overflow", RFC 1765, March 1995.
[OVERFLOW]Moy，J.，“OSPF数据库溢出”，RFC17651995年3月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[RFC2370]Coltun，R.，“OSPF不透明LSA选项”，RFC 23701998年7月。
[RFC3630] Katz, D., Kompella, K., and D. Yeund, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeund，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[RFC4576]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“使用链路状态公告（LSA）选项位防止BGP/MPLS IP虚拟专用网络（VPN）中的循环”，RFC 45762006年6月。
This appendix describes the format of the Options Field followed by the packet format of the Opaque LSA.
本附录描述了选项字段的格式以及不透明LSA的数据包格式。
The OSPF Options field is present in OSPF Hello packets, Database Description packets, and all link state advertisements. The Options field enables OSPF routers to support (or not support) optional capabilities, and to communicate their capability level to other OSPF routers. Through this mechanism, routers of differing capabilities can be mixed within an OSPF routing domain.
OSPF选项字段出现在OSPF Hello数据包、数据库描述数据包和所有链路状态播发中。选项字段使OSPF路由器能够支持（或不支持）可选功能，并将其功能级别与其他OSPF路由器进行通信。通过这种机制，不同功能的路由器可以在OSPF路由域中混合使用。
When used in Hello packets, the Options field allows a router to reject a neighbor because of a capability mismatch. Alternatively, when capabilities are exchanged in Database Description packets a router can choose not to flood certain link state advertisements to a neighbor because of its reduced functionality. Lastly, listing capabilities in link state advertisements allows routers to forward traffic around reduced functionality routers by excluding them from parts of the routing table calculation.
当在Hello数据包中使用时，Options字段允许路由器因为功能不匹配而拒绝邻居。或者，当在数据库描述数据包中交换功能时，路由器可以选择不向邻居发送某些链路状态播发，因为其功能降低。最后，在链路状态播发中列出功能允许路由器转发功能减少的路由器周围的流量，方法是将它们排除在路由表计算的部分之外。
All 8 bits of the OSPF Options field have been assigned, although only the O-bit is described completely by this document. Each bit is described briefly below. Routers SHOULD reset (i.e., clear) unrecognized bits in the Options field when sending Hello packets or Database Description packets and when originating link state advertisements. Conversely, routers encountering unrecognized Option bits in received Hello Packets, Database Description packets, or link state advertisements SHOULD ignore the capability and process the packet/advertisement normally.
OSPF选项字段的所有8位都已分配，尽管本文档仅完整描述了O位。下面简要描述每个位。在发送Hello数据包或数据库描述数据包以及发起链路状态播发时，路由器应重置（即清除）选项字段中未识别的位。相反，在收到的Hello数据包、数据库描述数据包或链路状态播发中遇到无法识别的选项位的路由器应忽略该功能，并正常处理数据包/播发。
+--------------------------------------+
| DN | O | DC | EA | N/P | MC | E | MT |
+--------------------------------------+
+--------------------------------------+
| DN | O | DC | EA | N/P | MC | E | MT |
+--------------------------------------+
The Options Field
选项字段
MT-bit This bit describes the router's multi-topology link-excluding capability, as described in [OSPF-MT].
MT位该位描述路由器的多拓扑链路排除能力，如[OSPF-MT]中所述。
E-bit This bit describes the way AS-External LSAs are flooded, as described in Sections 3.6, 9.5, 10.8, and 12.1.2 of [OSPF].
E位该位描述了外部LSA被淹没的方式，如[OSPF]第3.6、9.5、10.8和12.1.2节所述。
MC-bit This bit describes whether IP multicast datagrams are forwarded according to the specifications in [MOSPF].
MC位该位描述是否根据[MOSPF]中的规范转发IP多播数据报。
N/P-bit This bit describes the handling of Type-7 LSAs, as specified in [NSSA].
N/P位该位描述了[NSSA]中规定的7型LSA的处理。
DC-bit This bit describes the router's handling of demand circuits, as specified in [DEMD].
DC位该位描述了[DEMD]中规定的路由器对需求电路的处理。
EA-bit This bit describes the router's willingness to receive and forward External-Attributes-LSAs. While defined, the documents specifying this bit have all expired. The use of this bit may be deprecated in the future.
EA位该位描述路由器接收和转发外部属性LSA的意愿。定义时，指定此位的文档都已过期。将来可能不推荐使用此位。
O-bit This bit describes the router's willingness to receive and forward Opaque LSAs as specified in this document.
O位该位描述路由器是否愿意接收和转发本文件中规定的不透明LSA。
DN-bit This bit is used to prevent looping in BGP/MPLS IP VPNs, as specified in [RFC4576].
DN位此位用于防止BGP/MPLS IP VPN中的循环，如[RFC4576]中所述。
Opaque LSAs are Type 9, 10, and 11 link state advertisements. These advertisements MAY be used directly by OSPF or indirectly by some application wishing to distribute information throughout the OSPF domain. The function of the Opaque LSA option is to provide for future OSPF extensibility.
不透明LSA是类型9、10和11链路状态播发。这些广告可以由OSPF直接使用，也可以由希望在整个OSPF域中分发信息的某些应用程序间接使用。不透明LSA选项的功能是为将来的OSPF扩展提供支持。
Opaque LSAs contain some number of octets (of application-specific data) padded to 32-bit alignment. Like any other LSA, the Opaque LSA uses the link-state database distribution mechanism for flooding this information throughout the topology. However, the Opaque LSA has a flooding scope associated with it so that the scope of flooding may be link-local (type-9), area-local (type-10), or the entire OSPF routing domain (type-11). Section 3 of this document describes the flooding procedures for the Opaque LSA.
不透明LSA包含一定数量的八位字节（特定于应用程序的数据），填充为32位对齐。与任何其他LSA一样，不透明LSA使用链路状态数据库分发机制在整个拓扑中传播此信息。然而，不透明LSA具有与其相关联的泛洪范围，使得泛洪范围可以是链路本地（type-9）、区域本地（type-10）或整个OSPF路由域（type-11）。本文件第3节描述了不透明LSA的泛洪程序。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS age | Options | 9, 10, or 11 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Opaque Type | Opaque ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+ +
| Opaque Information |
+ +
| ... |
Link-State Type
链路状态类型
The link-state type of the Opaque LSA identifies the LSA's range of topological distribution. This range is referred to as the flooding scope. The following explains the flooding scope of each of the link-state types.
不透明LSA的链接状态类型标识LSA的拓扑分布范围。该范围称为泛洪范围。下面解释了每种链路状态类型的泛洪范围。
o A value of 9 denotes a link-local scope. Opaque LSAs with a link-local scope MUST NOT be flooded beyond the local (sub)network.
o 值9表示链接本地范围。具有链路本地作用域的不透明LSA不得淹没在本地（子）网络之外。
o A value of 10 denotes an area-local scope. Opaque LSAs with an area-local scope MUST NOT be flooded beyond their area of origin.
o 值10表示区域局部范围。具有区域局部范围的不透明LSA不得淹没在其原始区域之外。
o A value of 11 denotes that the LSA is flooded throughout the Autonomous System (e.g., has the same scope as type-5 LSAs). Opaque LSAs with AS-wide scope MUST NOT be flooded into stub areas or NSSAs.
o 值11表示LSA在整个自治系统中被淹没（例如，与5型LSA具有相同的范围）。具有同样宽范围的不透明LSA不得淹没到存根区域或NSSA中。
Syntax of the Opaque LSA's Link-State ID
不透明LSA的链接状态ID的语法
The link-state ID of the Opaque LSA is divided into an Opaque Type field (the first 8 bits) and an Opaque ID (the remaining 24 bits). See section 7 of this document for a description of Opaque type allocation and assignment.
不透明LSA的链路状态ID分为不透明类型字段（前8位）和不透明ID（其余24位）。有关不透明类型分配和赋值的说明，请参见本文档第7节。
Authors' Addresses
作者地址
Lou Berger LabN Consulting, L.L.C. EMail: lberger@labn.net
Lou Berger LabN Consulting，L.L.C.电子邮件：lberger@labn.net
Igor Bryskin ADVA Optical Networking Inc 7926 Jones Branch Drive Suite 615 McLean, VA 22102 EMail: ibryskin@advaoptical.com
Igor Bryskin ADVA光纤网络公司7926 Jones Branch Drive Suite 615 McLean，弗吉尼亚州22102电子邮件：ibryskin@advaoptical.com
Alex Zinin Alcatel-Lucent 750D Chai Chee Rd #06-06 Technopark@ChaiChee Singapore, 469004 EMail: alex.zinin@alcatel-lucent.com
Alex Zinin Alcatel-Lucent柴子路750D#06-06Technopark@ChaiChee新加坡，469004电子邮件：alex。zinin@alcatel-朗讯网
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA
Rob Coltun Auditora Productions 3204布鲁克草坪露台雪佛兰蔡斯，美国马里兰州20815
Full Copyright Statement
完整版权声明
Copyright (C) The IETF Trust (2008).
版权所有（C）IETF信托基金（2008年）。
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.