Network Working Group K. Kompella
Request for Comments: 4940 Juniper Networks
BCP: 130 B. Fenner
Category: Best Current Practice AT&T Labs--Research
June 2007
Network Working Group K. Kompella
Request for Comments: 4940 Juniper Networks
BCP: 130 B. Fenner
Category: Best Current Practice AT&T Labs--Research
June 2007
IANA Considerations for OSPF
OSPF的IANA考虑因素
Status of This Memo
关于下段备忘
This document specifies an Internet Best Current Practices for the Internet Community, and requests discussion and suggestions for improvements. Distribution of this memo is unlimited.
本文件规定了互联网社区的最佳现行做法，并要求进行讨论和提出改进建议。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The IETF Trust (2007).
版权所有（C）IETF信托基金（2007年）。
Abstract
摘要
This memo creates a number of OSPF registries and provides guidance to IANA for assignment of code points within these registries.
本备忘录创建了许多OSPF注册中心，并为IANA在这些注册中心内分配代码点提供指导。
Table of Contents
目录
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. OSPF Registries .................................................4
2.1. OSPFv2 Options .............................................4
2.2. OSPFv3 Options .............................................4
2.3. OSPF Packet Type (Both v2 and v3) ..........................4
2.3.1. OSPF Authentication Type ............................5
2.4. OSPFv2 Link State (LS) Type ................................5
2.4.1. OSPFv2 Router LSA Link Type .........................5
2.4.2. OSPFv2 Router Properties ............................6
2.5. OSPFv3 LSA Function Code ...................................6
2.5.1. OSPFv3 Prefix Options ...............................6
2.5.2. OSPFv3 Router LSA Link Type .........................6
2.6. OSPFv2 Opaque LSA Type .....................................7
2.6.1. OSPFv2 Grace LSA Top Level TLVs .....................7
3. Acknowledgments .................................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
5.1. OSPFv2 Options Registry ....................................8
5.2. OSPFv3 Options Registry ....................................8
5.3. OSPF Packet Type Registry ..................................9
5.4. OSPF Authentication Type Registry ..........................9
5.5. OSPFv2 Link State Type Registry ............................9
5.6. OSPFv2 Router LSA Link Type Registry ......................10
5.7. OSPFv2 Router Properties Registry .........................10
5.8. OSPFv3 LSA Function Code Registry .........................11
5.9. OSPFv3 Prefix Options Registry ............................12
5.10. OSPFv3 Router LSA Link Type Registry .....................12
5.11. OSPFv2 Opaque LSA Type Registry ..........................13
5.12. OSPFv2 Grace LSA Top Level TLV Registry ..................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................14
1. Introduction ....................................................3
1.1. Conventions Used in This Document ..........................4
2. OSPF Registries .................................................4
2.1. OSPFv2 Options .............................................4
2.2. OSPFv3 Options .............................................4
2.3. OSPF Packet Type (Both v2 and v3) ..........................4
2.3.1. OSPF Authentication Type ............................5
2.4. OSPFv2 Link State (LS) Type ................................5
2.4.1. OSPFv2 Router LSA Link Type .........................5
2.4.2. OSPFv2 Router Properties ............................6
2.5. OSPFv3 LSA Function Code ...................................6
2.5.1. OSPFv3 Prefix Options ...............................6
2.5.2. OSPFv3 Router LSA Link Type .........................6
2.6. OSPFv2 Opaque LSA Type .....................................7
2.6.1. OSPFv2 Grace LSA Top Level TLVs .....................7
3. Acknowledgments .................................................8
4. Security Considerations .........................................8
5. IANA Considerations .............................................8
5.1. OSPFv2 Options Registry ....................................8
5.2. OSPFv3 Options Registry ....................................8
5.3. OSPF Packet Type Registry ..................................9
5.4. OSPF Authentication Type Registry ..........................9
5.5. OSPFv2 Link State Type Registry ............................9
5.6. OSPFv2 Router LSA Link Type Registry ......................10
5.7. OSPFv2 Router Properties Registry .........................10
5.8. OSPFv3 LSA Function Code Registry .........................11
5.9. OSPFv3 Prefix Options Registry ............................12
5.10. OSPFv3 Router LSA Link Type Registry .....................12
5.11. OSPFv2 Opaque LSA Type Registry ..........................13
5.12. OSPFv2 Grace LSA Top Level TLV Registry ..................13
6. References .....................................................13
6.1. Normative References ......................................13
6.2. Informative References ....................................14
This memo defines various OSPF registries for IANA to set up and maintain for OSPF code points. In some cases, this memo defines ranges of code point values within these registries; each such range has a different assignment policy.
本备忘录定义了IANA为OSPF代码点设置和维护的各种OSPF注册表。在某些情况下，此备忘录定义了这些注册表中的代码点值范围；每个这样的范围都有不同的分配策略。
The terms used in describing the assignment policies are as follows:
描述派遣政策时使用的术语如下：
o Standards Action
o 标准行动
o Experimentation
o 实验
o Vendor Private Use
o 供应商私人使用
o Reserved
o 含蓄的
Standards Action means that assignments in that range MUST only be made for Standards Track RFCs (as defined in [RFC2434]).
标准行动意味着只能为标准跟踪RFC（定义见[RFC2434]）进行该范围内的分配。
Some of the registries defined below reserve a range of values for Experimentation. For guidelines regarding the use of such values see [RFC3692]. Values from this range MUST NOT be assigned by IANA. Further guidance on the use of the Experimentation range may be found in paragraphs 4, 5, and 6 of [RFC3692]. An implementation MAY choose to not support values from the Experimentation range. In such a case, the protocol data structure with a code point from the Experimentation range is ignored, unless other protocol machinery says how to deal with it. "Ignored" in this context means that the associated data structure is removed from the received packet before further processing, including flooding.
下面定义的一些注册表为实验保留了一系列值。有关使用此类值的指南，请参见[RFC3692]。IANA不得分配此范围内的值。[RFC3692]第4、5和6段中提供了关于试验范围使用的进一步指导。实现可以选择不支持实验范围内的值。在这种情况下，除非其他协议机制说明如何处理，否则忽略带有实验范围内代码点的协议数据结构。在此上下文中，“忽略”意味着在进一步处理（包括泛洪）之前从接收的分组中移除相关联的数据结构。
Values set aside as Vendor Private Use MUST NOT be assigned by IANA. A protocol data structure whose code point falls in this range MUST have a disambiguating field identifying the Vendor. This identifier consists of four octets of the Vendor's SMI (Structure of Management Information) enterprise code (see [ENTERPRISE-NUMBERS]) in network byte order; the location of this code must be well-defined per data structure. An implementation that encounters a Vendor Private code point SHOULD check whether the enterprise code is one that it recognizes; if so, the implementation MAY choose to interpret the code point and data structure. Otherwise, it SHOULD ignore the code point, unless the protocol machinery says how to deal with the data structure (as defined in the previous paragraph). This allows multiple vendor private extensions to coexist in a network.
IANA不得分配作为供应商专用的值。代码点在此范围内的协议数据结构必须具有识别供应商的消歧字段。该标识符由供应商SMI（管理信息结构）企业代码（见[企业编号]）的四个八位字节组成，按网络字节顺序排列；此代码的位置必须根据数据结构进行良好定义。遇到供应商私有代码点的实现应检查企业代码是否为其识别的代码；如果是这样，实现可以选择解释代码点和数据结构。否则，它应该忽略代码点，除非协议机制说明如何处理数据结构（如前一段中定义的）。这允许多个供应商专用扩展在网络中共存。
Values in the Reserved range MUST NOT be assigned until a Standards Track or Best Common Practices RFC is published defining the
在发布定义保留范围的标准跟踪或最佳通用做法RFC之前，不得指定保留范围中的值
assignment policy for that range. This RFC MUST be the product of the OSPF Working Group; if the OSPF WG is terminated, then it MUST be reviewed by an Expert Reviewer designated by the IESG.
该范围的分配策略。该RFC必须是OSPF工作组的产品；如果OSPF工作组终止，则必须由IESG指定的专家评审员进行评审。
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]中所述进行解释。
This section lists the various registries for OSPF protocol code points. Note that some of these are for OSPF, and some are specific to a particular version of OSPF; also, some registries predate this memo.
本节列出了OSPF协议代码点的各种注册表。请注意，其中有些是针对OSPF的，有些是针对特定版本的OSPF的；此外，一些登记处早于本备忘录。
Registries that are specific to one version of OSPF reflect the version number in the registry name (e.g., OSPFv2 Options). A registry whose name does not mention a version number applies to both OSPFv2 and OSPFv3 (e.g., OSPF Packet Type).
特定于一个OSPF版本的注册表在注册表名称中反映版本号（例如，OSPFv2选项）。名称未提及版本号的注册表同时适用于OSPFv2和OSPFv3（例如，OSPF数据包类型）。
(Defined in Section A.2 of [RFC2328], updated in Section A.1 of [RFC2370]. See also [RFC3101].)
（定义见[RFC2328]第A.2节，更新见[RFC2370]第A.1节。另请参见[RFC3101]。）
Assignment policy: Standards Action.
分配政策：标准行动。
(Defined in Section A.2 of [RFC2740])
（定义见[RFC2740]第A.2节）
Assignment policy: Standards Action.
分配政策：标准行动。
(Defined in Section A.3.1 of [RFC2328])
（定义见[RFC2328]第A.3.1节）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-5 | Already assigned |
| 6-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-5 | Already assigned |
| 6-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
(Defined in Section A.3.1 of [RFC2328])
（定义见[RFC2328]第A.3.1节）
(Note: this registry is called "OSPF AUTHENTICATION CODES" by IANA.)
（注：IANA将此注册表称为“OSPF认证码”。）
+-------------+-------------------+
| Range | Assignment Policy |
+-------------+-------------------+
| 0-2 | Already assigned |
| 3-247 | Standards Action |
| 248-65519 | Reserved |
| 65520-65535 | Experimentation |
+-------------+-------------------+
+-------------+-------------------+
| Range | Assignment Policy |
+-------------+-------------------+
| 0-2 | Already assigned |
| 3-247 | Standards Action |
| 248-65519 | Reserved |
| 65520-65535 | Experimentation |
+-------------+-------------------+
(Defined in Section A.4.1 of [RFC2328])
（定义见[RFC2328]第A.4.1节）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-11 | Already assigned |
| 12-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-11 | Already assigned |
| 12-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
If a new LS Type is documented, the documentation MUST say how the Link State ID is to be filled in, what the flooding scope of the LSA (Link State Advertisement) is, and how backward compatibility is maintained.
如果记录了新的LS类型，文档必须说明如何填写链接状态ID、LSA（链接状态公告）的泛洪范围以及如何保持向后兼容性。
(Defined in Section A.4.2 of [RFC2328])
（定义见[RFC2328]第A.4.2节）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor.
没有供供应商私人使用的范围，因为没有用于标识供应商的企业代码的空间。
No Experimental range is defined, due to possible backwards compatibility issues.
由于可能存在向后兼容性问题，未定义任何实验范围。
If a new Router LSA Link Type is documented, the documentation SHOULD say how the Link State ID, Link ID, and Link Data fields are to be filled in, and how backward compatibility is maintained.
如果记录了一个新的路由器LSA链路类型，文档中应说明如何填写链路状态ID、链路ID和链路数据字段，以及如何保持向后兼容性。
(Defined in Section A.4.2 of [RFC2328], updated in [RFC3101])
（在[RFC2328]第A.4.2节中定义，在[RFC3101]中更新）
This 8-bit field in the Router LSA is unnamed; it is the field immediately following the Router LSA length.
路由器LSA中的8位字段未命名；它是紧跟在路由器LSA长度之后的字段。
Assignment policy: Standards Action.
分配政策：标准行动。
This registry is created by [OSPF-CAP]. This document provides the values to be populated for values defined in Section A.4.2.1 of [RFC2740].
此注册表由[OSPF-CAP]创建。本文件提供了[RFC2740]第A.4.2.1节中定义的值的填充值。
(Defined in Section A.4.1.1 of [RFC2740])
（定义见[RFC2740]第A.4.1.1节）
Assignment policy: Standards Action.
分配政策：标准行动。
(Defined in Section A.4.3 of [RFC2740])
（定义见[RFC2740]第A.4.3节）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-4 | Already assigned |
| 5-127 | Standards Action |
| 128-255 | Reserved |
+---------+--------------------+
There is no range for Vendor Private Use, as there is no space for an enterprise code to identify the Vendor.
没有供供应商私人使用的范围，因为没有用于标识供应商的企业代码的空间。
No Experimental range is defined, due to possible backwards compatibility issues.
由于可能存在向后兼容性问题，未定义任何实验范围。
(Defined in Section A.2 of [RFC2370])
（定义见[RFC2370]第A.2节）
(Note: this registry is called "OSPF Opaque LSA Option" by IANA. See also [RFC3630].)
（注：IANA将此注册表称为“OSPF不透明LSA选项”。另请参见[RFC3630]。）
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-127 | Standards Action |
| 128-247 | Reserved |
| 248-251 | Experimentation |
| 252-255 | Vendor Private Use |
+---------+--------------------+
+---------+--------------------+
| Range | Assignment Policy |
+---------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-127 | Standards Action |
| 128-247 | Reserved |
| 248-251 | Experimentation |
| 252-255 | Vendor Private Use |
+---------+--------------------+
In an OSPFv2 Opaque LSA with Opaque LSA Type in the Vendor Private Use range, the first four octets of Opaque Information MUST be the Vendor enterprise code.
在供应商专用范围内具有不透明LSA类型的OSPFv2不透明LSA中，不透明信息的前四个八位字节必须是供应商企业代码。
A document defining a new Standards Track Opaque LSA with TLVs and sub-TLVs MUST describe ranges and assignment policies for these TLVs.
定义具有TLV和子TLV的新标准LSA的文件必须描述这些TLV的范围和分配策略。
(Defined in Appendix A of [RFC3623])
（定义见[RFC3623]附录A）
+-------------+--------------------+
| Range | Assignment Policy |
+-------------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-255 | Standards Action |
| 256-65519 | Reserved |
| 65520-65527 | Experimentation |
| 65528-65535 | Vendor Private Use |
+-------------+--------------------+
+-------------+--------------------+
| Range | Assignment Policy |
+-------------+--------------------+
| 0 | Not to be assigned |
| 1-3 | Already assigned |
| 4-255 | Standards Action |
| 256-65519 | Reserved |
| 65520-65527 | Experimentation |
| 65528-65535 | Vendor Private Use |
+-------------+--------------------+
In a Grace LSA, if a top-level TLV has a Type from the Vendor Private Use range, the Length MUST be at least four, and the first four octets of the Value field MUST be the Vendor enterprise code.
在Grace LSA中，如果顶级TLV的类型来自供应商专用范围，则长度必须至少为四个，并且值字段的前四个八位字节必须是供应商企业代码。
Many thanks to Adrian Farrel and Acee Lindem for their review and comments.
非常感谢Adrian Farrel和Acee Lindem的审查和评论。
The lack of adequate IANA guidelines may be viewed as an avenue for Denial of Service attacks on IETF protocols (in this case, OSPFv2 and OSPFv3), and on the IETF Standards Process in general. This memo attempts to close this loophole for OSPFv2 and OSPFv3.
缺乏适当的IANA指南可能被视为对IETF协议（在本例中为OSPFv2和OSPFv3）和IETF标准过程进行拒绝服务攻击的一种途径。本备忘录试图填补OSPFv2和OSPFv3的这一漏洞。
Authors contemplating extensions to OSPF SHOULD examine such extensions carefully, and consider whether new registries are needed, and if so, allocation policies within each registry.
考虑扩展OSPF的作者应该仔细检查这些扩展，并考虑是否需要新的注册表，如果是，则在每个注册表中分配策略。
This document specifies assignment policy for several existing IANA registries and creates several more.
本文档指定了几个现有IANA注册中心的分配策略，并创建了多个。
Section 2.1 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 6 are already assigned. The initial registry contents are given below.
第2.1节将从该注册表分配位的策略定义为“标准行动”。该字段中只有8位，已经分配了6位。初始注册表内容如下所示。
OSPFv2 Options Registry (Section 2.1)
OSPFv2选项注册表（第2.1节）
Value Description Reference
----- ----------- ---------
0x02 E-bit [RFC2328]
0x04 MC-bit [RFC1584]
0x08 N/P-bit [RFC3101]
0x10 Reserved
0x20 DC-bit [RFC1793]
0x40 O-bit [RFC2370]
Value Description Reference
----- ----------- ---------
0x02 E-bit [RFC2328]
0x04 MC-bit [RFC1584]
0x08 N/P-bit [RFC3101]
0x10 Reserved
0x20 DC-bit [RFC1793]
0x40 O-bit [RFC2370]
Section 2.2 defines the policy for allocation of bits from this registry as "Standards Action". There are 24 bits in this field, and 6 are assigned. The initial registry contents are given below.
第2.2节将从该注册表分配位的策略定义为“标准行动”。该字段中有24位，分配了6位。初始注册表内容如下所示。
OSPFv3 Options Registry (Section 2.2)
OSPFv3期权登记册（第2.2节）
Value Description Reference
-------- ----------- ---------
0x000001 V6-bit [RFC2740]
0x000002 E-bit [RFC2328]
0x000004 MC-bit [RFC1584]
0x000008 N-bit [RFC3101]
0x000010 R-Bit [RFC2740]
0x000020 DC-bit [RFC1793]
Value Description Reference
-------- ----------- ---------
0x000001 V6-bit [RFC2740]
0x000002 E-bit [RFC2328]
0x000004 MC-bit [RFC1584]
0x000008 N-bit [RFC3101]
0x000010 R-Bit [RFC2740]
0x000020 DC-bit [RFC1793]
Section 2.3 defines the policy for allocation of values from this registry for different ranges. The initial registry contents are given below.
第2.3节定义了将此注册表中的值分配给不同范围的策略。初始注册表内容如下所示。
OSPF Packet Type (Section 2.3)
OSPF数据包类型（第2.3节）
Value Description Reference
----- -------------------- ---------
1 Hello [RFC2328]
2 Database Description [RFC2328]
3 Link State Request [RFC2328]
4 Link State Update [RFC2328]
5 Link State Ack [RFC2328]
Value Description Reference
----- -------------------- ---------
1 Hello [RFC2328]
2 Database Description [RFC2328]
3 Link State Request [RFC2328]
4 Link State Update [RFC2328]
5 Link State Ack [RFC2328]
This registry already exists at IANA, called "ospf-authentication-codes". Section 2.3.1 defines the policy for allocation from this registry for different ranges.
IANA中已经存在此注册表，称为“ospf身份验证代码”。第2.3.1节定义了从该注册表分配不同范围的策略。
Section 2.4 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
第2.4节定义了针对不同范围从该注册表分配的策略。初始注册表内容如下所示。
OSPFv2 Link State (LS) Type (Section 2.4)
OSPFv2链路状态（LS）类型（第2.4节）
Value Description Reference
----- ------------------------ ---------
1 Router-LSA [RFC2328]
2 Network-LSA [RFC2328]
3 Summary-LSA (IP network) [RFC2328]
4 Summary-LSA (ASBR) [RFC2328]
5 AS-external-LSA [RFC2328]
6 Group-membership-LSA [RFC1584]
7 NSSA AS-external LSA [RFC3101]
8 Reserved
9 Link-local Opaque LSA [RFC2370]
10 Area-local Opaque LSA [RFC2370]
11 Opaque LSA [RFC2370]
Value Description Reference
----- ------------------------ ---------
1 Router-LSA [RFC2328]
2 Network-LSA [RFC2328]
3 Summary-LSA (IP network) [RFC2328]
4 Summary-LSA (ASBR) [RFC2328]
5 AS-external-LSA [RFC2328]
6 Group-membership-LSA [RFC1584]
7 NSSA AS-external LSA [RFC3101]
8 Reserved
9 Link-local Opaque LSA [RFC2370]
10 Area-local Opaque LSA [RFC2370]
11 Opaque LSA [RFC2370]
Section 2.4.1 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
第2.4.1节定义了针对不同范围从该注册表分配的策略。初始注册表内容如下所示。
OSPFv2 Router LSA Link Type (Section 2.4.1)
OSPFv2路由器LSA链路类型（第2.4.1节）
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2328]
2 Transit Network [RFC2328]
3 Stub Network [RFC2328]
4 Virtual Link [RFC2328]
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2328]
2 Transit Network [RFC2328]
3 Stub Network [RFC2328]
4 Virtual Link [RFC2328]
Section 2.4.2 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 5 are already assigned. The initial registry contents are given below.
第2.4.2节将从该注册表分配位的策略定义为“标准行动”。该字段中只有8位，已经分配了5位。初始注册表内容如下所示。
OSPFv2 Options Registry (Section 2.1)
OSPFv2选项注册表（第2.1节）
Value Description Reference
----- ----------- ---------
0x01 B-bit [RFC2328]
0x02 W-bit [RFC2328]
0x04 V-bit [RFC2328]
0x08 W-bit [RFC1584]
0x10 Nt-bit [RFC3101]
Value Description Reference
----- ----------- ---------
0x01 B-bit [RFC2328]
0x02 W-bit [RFC2328]
0x04 V-bit [RFC2328]
0x08 W-bit [RFC1584]
0x10 Nt-bit [RFC3101]
This registry is created by [OSPF-CAP], which also defines the registration policy. This section contains values that belong in this registry that were defined by [RFC2740].
此注册表由[OSPF-CAP]创建，它还定义了注册策略。本节包含由[RFC2740]定义的属于此注册表的值。
As defined in [RFC2740], the first 3 bits of the LSA Function
Code are the U, S1, and S2 bits. A given function code implies a
specific setting for the U, S1, and S2 bits as shown in the "LS Type"
column.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
As defined in [RFC2740], the first 3 bits of the LSA Function
Code are the U, S1, and S2 bits. A given function code implies a
specific setting for the U, S1, and S2 bits as shown in the "LS Type"
column.
1 1 1 1 1 1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
The U bit indicates how the LSA should be handled by a router which does not recognize the LSA's function code. Its values are:
U位表示不识别LSA功能代码的路由器应如何处理LSA。其价值是：
U-bit LSA Handling
----- ----------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA, as if type understood
U-bit LSA Handling
----- ----------------------------------------------------
0 Treat the LSA as if it had link-local flooding scope
1 Store and flood the LSA, as if type understood
The S1 and S2 bits indicate the flooding scope of the LSA. The values are:
S1和S2位表示LSA的泛洪范围。这些数值是：
S1 S2 Flooding Scope
-- -- --------------------------------------------------------------
0 0 Link-Local Scoping. Flooded only on link it is originated on
0 1 Area Scoping. Flooded to all routers in the originating area
1 0 AS Scoping. Flooded to all routers in the AS
1 1 Reserved
S1 S2 Flooding Scope
-- -- --------------------------------------------------------------
0 0 Link-Local Scoping. Flooded only on link it is originated on
0 1 Area Scoping. Flooded to all routers in the originating area
1 0 AS Scoping. Flooded to all routers in the AS
1 1 Reserved
The initial registry contents are given below.
初始注册表内容如下所示。
OSPFv3 LSA Function Code (Section 2.5)
OSPFv3 LSA功能代码（第2.5节）
LSA Function Code LS Type Description Reference
----------------- ------- --------------------- ---------
1 0x2001 Router-LSA [RFC2740]
2 0x2002 Network-LSA [RFC2740]
3 0x2003 Inter-Area-Prefix-LSA [RFC2740]
4 0x2004 Inter-Area-Router-LSA [RFC2740]
5 0x4005 AS-External-LSA [RFC2740]
6 0x2006 Group-membership-LSA [RFC2740]
7 0x2007 Type-7-LSA [RFC2740]
8 0x0008 Link-LSA [RFC2740]
9 0x2009 Intra-Area-Prefix-LSA [RFC2740]
LSA Function Code LS Type Description Reference
----------------- ------- --------------------- ---------
1 0x2001 Router-LSA [RFC2740]
2 0x2002 Network-LSA [RFC2740]
3 0x2003 Inter-Area-Prefix-LSA [RFC2740]
4 0x2004 Inter-Area-Router-LSA [RFC2740]
5 0x4005 AS-External-LSA [RFC2740]
6 0x2006 Group-membership-LSA [RFC2740]
7 0x2007 Type-7-LSA [RFC2740]
8 0x0008 Link-LSA [RFC2740]
9 0x2009 Intra-Area-Prefix-LSA [RFC2740]
Section 2.5.1 defines the policy for allocation of bits from this registry as "Standards Action". There are only 8 bits in this field, and 4 are already assigned. The initial registry contents are given below.
第2.5.1节将从该注册表分配位的策略定义为“标准行动”。该字段中只有8位，已经分配了4位。初始注册表内容如下所示。
OSPFv3 Prefix Options Registry (Section 2.5.1)
OSPFv3前缀选项注册表（第2.5.1节）
Value Description Reference
----- ----------- ---------
0x01 NU-bit [RFC2740]
0x02 LA-bit [RFC2740]
0x04 MC-bit [RFC2740]
0x08 P-bit [RFC2740]
Value Description Reference
----- ----------- ---------
0x01 NU-bit [RFC2740]
0x02 LA-bit [RFC2740]
0x04 MC-bit [RFC2740]
0x08 P-bit [RFC2740]
Section 2.5.2 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
第2.5.2节定义了针对不同范围从该注册表分配的策略。初始注册表内容如下所示。
OSPFv3 Router LSA Link Type (Section 2.5.2)
OSPFv3路由器LSA链路类型（第2.5.2节）
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2740]
2 Transit Network [RFC2740]
3 Reserved [RFC2740]
4 Virtual Link [RFC2740]
Value Description Reference
----- ------------------------------------------- ---------
1 Point-to-Point connection to another router [RFC2740]
2 Transit Network [RFC2740]
3 Reserved [RFC2740]
4 Virtual Link [RFC2740]
This registry already exists at IANA, called "ospf-opaque-types". Section 2.6 defines the policy for allocation from this registry for different ranges.
IANA中已经存在此注册表，称为“ospf不透明类型”。第2.6节定义了从该注册表为不同范围分配的策略。
Section 2.6.1 defines the policy for allocations from this registry for different ranges. The initial registry contents are given below.
第2.6.1节定义了针对不同范围从该注册表分配的策略。初始注册表内容如下所示。
OSPFv2 Grace LSA Top Level TLV (Section 2.6.1)
OSPFv2宽限LSA顶级TLV（第2.6.1节）
Value Description Reference
----- ----------------------- ---------
1 Grace Period [RFC3623]
2 Graceful Restart reason [RFC3623]
3 IP Interface Address [RFC3623]
Value Description Reference
----- ----------------------- ---------
1 Grace Period [RFC3623]
2 Graceful Restart reason [RFC3623]
3 IP Interface Address [RFC3623]
[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月。
[RFC1584] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[RFC1584]Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[RFC1793] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[RFC1793]莫伊，J.，“扩展OSPF以支持需求电路”，RFC1793，1995年4月。
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，1998年4月。
[RFC2370] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[RFC2370]Coltun，R.，“OSPF不透明LSA选项”，RFC 23701998年7月。
[RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.
[RFC2434]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 2434，1998年10月。
[RFC2740] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[RFC2740]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[RFC3101] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[RFC3101]Murphy，P.，“OSPF不那么短的区域（NSSA）选项”，RFC 31012003年1月。
[RFC3623] Moy, J., Pillay-Esnault, P., and A. Lindem, "Graceful OSPF Restart", RFC 3623, November 2003.
[RFC3623]Moy，J.，Pillay Esnault，P.，和A.Lindem，“OSPF的优雅重启”，RFC 36232003年11月。
[RFC3630] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003.
[RFC3630]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月。
[RFC3692] Narten, T., "Assigning Experimental and Testing Numbers Considered Useful", BCP 82, RFC 3692, January 2004.
[RFC3692]Narten，T.，“分配被认为有用的实验和测试数字”，BCP 82，RFC 3692，2004年1月。
[ENTERPRISE-NUMBERS] "PRIVATE ENTERPRISE NUMBERS", http://www.iana.org/assignments/enterprise-numbers.
[企业编号]“私营企业编号”，http://www.iana.org/assignments/enterprise-numbers.
[OSPF-CAP] Lindem, A., "Extensions to OSPF for Advertising Optional Router Capabilities", Work in Progress, May 2007.
[OSPF-CAP]Lindem，A.，“用于宣传可选路由器功能的OSPF扩展”，正在进行的工作，2007年5月。
Authors' Addresses
作者地址
Kireeti Kompella Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 US
Kireeti Kompella Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州，美国94089
EMail: kireeti@juniper.net
EMail: kireeti@juniper.net
Bill Fenner AT&T Labs--Research 1 River Oaks Place San Jose, CA 95134 US
比尔·芬纳AT&T实验室——美国加利福尼亚州圣何塞河橡树广场研究1号，邮编95134
Phone: +1 (408) 493-8505
EMail: fenner@research.att.com
Phone: +1 (408) 493-8505
EMail: fenner@research.att.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.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。