Network Working Group R. Coltun
Request for Comments: 5340 Acoustra Productions
Obsoletes: 2740 D. Ferguson
Category: Standards Track Juniper Networks
J. Moy
Sycamore Networks, Inc
A. Lindem, Ed.
Redback Networks
July 2008
Network Working Group R. Coltun
Request for Comments: 5340 Acoustra Productions
Obsoletes: 2740 D. Ferguson
Category: Standards Track Juniper Networks
J. Moy
Sycamore Networks, Inc
A. Lindem, Ed.
Redback Networks
July 2008
OSPF for IPv6
IPv6的OSPF
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 describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, Short Path First (SPF) calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
本文档描述了对OSPF的修改，以支持Internet协议（IPv6）版本6。OSPF的基本机制（泛洪、指定路由器（DR）选择、区域支持、短路径优先（SPF）计算等）保持不变。然而，由于IPv4和IPv6之间协议语义的变化，或者仅仅为了处理IPv6地址大小的增加，一些更改是必要的。这些修改需要将协议版本从版本2增加到版本3。IPv6的OSPF也称为OSPF版本3（OSPFv3）。
Changes between OSPF for IPv4, OSPF Version 2, and OSPF for IPv6 as described herein include the following. Addressing semantics have been removed from OSPF packets and the basic Link State Advertisements (LSAs). New LSAs have been created to carry IPv6 addresses and prefixes. OSPF now runs on a per-link basis rather than on a per-IP-subnet basis. Flooding scope for LSAs has been generalized. Authentication has been removed from the OSPF protocol and instead relies on IPv6's Authentication Header and Encapsulating Security Payload (ESP).
如本文所述，用于IPv4的OSPF、OSPF版本2和用于IPv6的OSPF之间的更改包括以下内容。从OSPF数据包和基本链路状态播发（LSA）中删除了寻址语义。已创建新的LSA以承载IPv6地址和前缀。OSPF现在是基于每条链路而不是基于每个IP子网运行的。LSA的泛洪范围已得到推广。身份验证已从OSPF协议中删除，而是依赖于IPv6的身份验证头和封装安全负载（ESP）。
Even with larger IPv6 addresses, most packets in OSPF for IPv6 are almost as compact as those in OSPF for IPv4. Most fields and packet-size limitations present in OSPF for IPv4 have been relaxed. In addition, option handling has been made more flexible.
即使使用更大的IPv6地址，用于IPv6的OSPF中的大多数数据包几乎与用于IPv4的OSPF中的数据包一样紧凑。IPv4的OSPF中存在的大多数字段和数据包大小限制都已放宽。此外，选项处理变得更加灵活。
All of OSPF for IPv4's optional capabilities, including demand circuit support and Not-So-Stubby Areas (NSSAs), are also supported in OSPF for IPv6.
OSPF for IPv4的所有可选功能，包括按需电路支持和非短截区（NSSA），也在OSPF for IPv6中得到支持。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . . 5
2.1. Protocol Processing Per-Link, Not Per-Subnet . . . . . . . 5
2.2. Removal of Addressing Semantics . . . . . . . . . . . . . 5
2.3. Addition of Flooding Scope . . . . . . . . . . . . . . . . 6
2.4. Explicit Support for Multiple Instances per Link . . . . . 6
2.5. Use of Link-Local Addresses . . . . . . . . . . . . . . . 7
2.6. Authentication Changes . . . . . . . . . . . . . . . . . . 7
2.7. Packet Format Changes . . . . . . . . . . . . . . . . . . 8
2.8. LSA Format Changes . . . . . . . . . . . . . . . . . . . . 9
2.9. Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 11
3.1. Support for Multiple Interfaces on the Same Link . . . . . 11
3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 12
3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 12
3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
3.6. LSA Options and Prefix Options Updates . . . . . . . . . . 13
3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 13
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 13
4.1. Protocol Data Structures . . . . . . . . . . . . . . . . . 14
4.1.1. The Area Data Structure . . . . . . . . . . . . . . . 15
4.1.2. The Interface Data Structure . . . . . . . . . . . . . 15
4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 16
4.2. Protocol Packet Processing . . . . . . . . . . . . . . . . 17
4.2.1. Sending Protocol Packets . . . . . . . . . . . . . . . 17
4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 18
4.2.1.2. Sending Database Description Packets . . . . . . . 19
4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . . 19
4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 21
4.3. The Routing table Structure . . . . . . . . . . . . . . . 22
4.3.1. Routing Table Lookup . . . . . . . . . . . . . . . . . 23
4.4. Link State Advertisements . . . . . . . . . . . . . . . . 23
4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . . 23
4.4.2. The Link-State Database . . . . . . . . . . . . . . . 24
4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . . 25
4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 27
4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 27
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 4
1.2. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Differences from OSPF for IPv4 . . . . . . . . . . . . . . . . 5
2.1. Protocol Processing Per-Link, Not Per-Subnet . . . . . . . 5
2.2. Removal of Addressing Semantics . . . . . . . . . . . . . 5
2.3. Addition of Flooding Scope . . . . . . . . . . . . . . . . 6
2.4. Explicit Support for Multiple Instances per Link . . . . . 6
2.5. Use of Link-Local Addresses . . . . . . . . . . . . . . . 7
2.6. Authentication Changes . . . . . . . . . . . . . . . . . . 7
2.7. Packet Format Changes . . . . . . . . . . . . . . . . . . 8
2.8. LSA Format Changes . . . . . . . . . . . . . . . . . . . . 9
2.9. Handling Unknown LSA Types . . . . . . . . . . . . . . . . 10
2.10. Stub/NSSA Area Support . . . . . . . . . . . . . . . . . . 11
2.11. Identifying Neighbors by Router ID . . . . . . . . . . . . 11
3. Differences with RFC 2740 . . . . . . . . . . . . . . . . . . 11
3.1. Support for Multiple Interfaces on the Same Link . . . . . 11
3.2. Deprecation of MOSPF for IPv6 . . . . . . . . . . . . . . 12
3.3. NSSA Specification . . . . . . . . . . . . . . . . . . . . 12
3.4. Stub Area Unknown LSA Flooding Restriction Deprecated . . 12
3.5. Link LSA Suppression . . . . . . . . . . . . . . . . . . . 12
3.6. LSA Options and Prefix Options Updates . . . . . . . . . . 13
3.7. IPv6 Site-Local Addresses . . . . . . . . . . . . . . . . 13
4. Implementation Details . . . . . . . . . . . . . . . . . . . . 13
4.1. Protocol Data Structures . . . . . . . . . . . . . . . . . 14
4.1.1. The Area Data Structure . . . . . . . . . . . . . . . 15
4.1.2. The Interface Data Structure . . . . . . . . . . . . . 15
4.1.3. The Neighbor Data Structure . . . . . . . . . . . . . 16
4.2. Protocol Packet Processing . . . . . . . . . . . . . . . . 17
4.2.1. Sending Protocol Packets . . . . . . . . . . . . . . . 17
4.2.1.1. Sending Hello Packets . . . . . . . . . . . . . . 18
4.2.1.2. Sending Database Description Packets . . . . . . . 19
4.2.2. Receiving Protocol Packets . . . . . . . . . . . . . . 19
4.2.2.1. Receiving Hello Packets . . . . . . . . . . . . . 21
4.3. The Routing table Structure . . . . . . . . . . . . . . . 22
4.3.1. Routing Table Lookup . . . . . . . . . . . . . . . . . 23
4.4. Link State Advertisements . . . . . . . . . . . . . . . . 23
4.4.1. The LSA Header . . . . . . . . . . . . . . . . . . . . 23
4.4.2. The Link-State Database . . . . . . . . . . . . . . . 24
4.4.3. Originating LSAs . . . . . . . . . . . . . . . . . . . 25
4.4.3.1. LSA Options . . . . . . . . . . . . . . . . . . . 27
4.4.3.2. Router-LSAs . . . . . . . . . . . . . . . . . . . 27
4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . . 29
4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
4.4.3.6. AS-External-LSAs . . . . . . . . . . . . . . . . . 32
4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 33
4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 34
4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 40
4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1. Receiving Link State Update Packets . . . . . . . . . 40
4.5.2. Sending Link State Update Packets . . . . . . . . . . 41
4.5.3. Installing LSAs in the Database . . . . . . . . . . . 43
4.6. Definition of Self-Originated LSAs . . . . . . . . . . . . 43
4.7. Virtual Links . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Routing Table Calculation . . . . . . . . . . . . . . . . 44
4.8.1. Calculating the Shortest-Path Tree for an Area . . . . 45
4.8.2. The Next-Hop Calculation . . . . . . . . . . . . . . . 44
4.8.3. Calculating the Inter-Area Routes . . . . . . . . . . 47
4.8.4. Examining Transit Areas' Summary-LSAs . . . . . . . . 48
4.8.5. Calculating AS External and NSSA Routes . . . . . . . 48
4.9. Multiple Interfaces to a Single Link . . . . . . . . . . . 48
4.9.1. Standby Interface State . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Manageability Considerations . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
A.1. Encapsulation of OSPF Packets . . . . . . . . . . . . . . 57
A.2. The Options Field . . . . . . . . . . . . . . . . . . . . 58
A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 60
A.3.1. The OSPF Packet Header . . . . . . . . . . . . . . . . 60
A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . . 62
A.3.3. The Database Description Packet . . . . . . . . . . . 63
A.3.4. The Link State Request Packet . . . . . . . . . . . . 65
A.3.5. The Link State Update Packet . . . . . . . . . . . . . 66
A.3.6. The Link State Acknowledgment Packet . . . . . . . . . 67
A.4. LSA Formats . . . . . . . . . . . . . . . . . . . . . . . 68
A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . . 69
A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . . 69
A.4.2. The LSA Header . . . . . . . . . . . . . . . . . . . . 70
A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . . 72
A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 73
A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77
4.4.3.3. Network-LSAs . . . . . . . . . . . . . . . . . . . 29
4.4.3.4. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . 30
4.4.3.5. Inter-Area-Router-LSAs . . . . . . . . . . . . . . 31
4.4.3.6. AS-External-LSAs . . . . . . . . . . . . . . . . . 32
4.4.3.7. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . 33
4.4.3.8. Link-LSAs . . . . . . . . . . . . . . . . . . . . 34
4.4.3.9. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . 36
4.4.4. Future LSA Validation . . . . . . . . . . . . . . . . 40
4.5. Flooding . . . . . . . . . . . . . . . . . . . . . . . . . 40
4.5.1. Receiving Link State Update Packets . . . . . . . . . 40
4.5.2. Sending Link State Update Packets . . . . . . . . . . 41
4.5.3. Installing LSAs in the Database . . . . . . . . . . . 43
4.6. Definition of Self-Originated LSAs . . . . . . . . . . . . 43
4.7. Virtual Links . . . . . . . . . . . . . . . . . . . . . . 44
4.8. Routing Table Calculation . . . . . . . . . . . . . . . . 44
4.8.1. Calculating the Shortest-Path Tree for an Area . . . . 45
4.8.2. The Next-Hop Calculation . . . . . . . . . . . . . . . 44
4.8.3. Calculating the Inter-Area Routes . . . . . . . . . . 47
4.8.4. Examining Transit Areas' Summary-LSAs . . . . . . . . 48
4.8.5. Calculating AS External and NSSA Routes . . . . . . . 48
4.9. Multiple Interfaces to a Single Link . . . . . . . . . . . 48
4.9.1. Standby Interface State . . . . . . . . . . . . . . . 50
5. Security Considerations . . . . . . . . . . . . . . . . . . . 52
6. Manageability Considerations . . . . . . . . . . . . . . . . . 52
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 52
7.1. MOSPF for OSPFv3 Deprecation IANA Considerations . . . . . 53
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 53
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 55
9.1. Normative References . . . . . . . . . . . . . . . . . . . 55
9.2. Informative References . . . . . . . . . . . . . . . . . . 56
Appendix A. OSPF Data Formats . . . . . . . . . . . . . . . . . . 57
A.1. Encapsulation of OSPF Packets . . . . . . . . . . . . . . 57
A.2. The Options Field . . . . . . . . . . . . . . . . . . . . 58
A.3. OSPF Packet Formats . . . . . . . . . . . . . . . . . . . 60
A.3.1. The OSPF Packet Header . . . . . . . . . . . . . . . . 60
A.3.2. The Hello Packet . . . . . . . . . . . . . . . . . . . 62
A.3.3. The Database Description Packet . . . . . . . . . . . 63
A.3.4. The Link State Request Packet . . . . . . . . . . . . 65
A.3.5. The Link State Update Packet . . . . . . . . . . . . . 66
A.3.6. The Link State Acknowledgment Packet . . . . . . . . . 67
A.4. LSA Formats . . . . . . . . . . . . . . . . . . . . . . . 68
A.4.1. IPv6 Prefix Representation . . . . . . . . . . . . . . 69
A.4.1.1. Prefix Options . . . . . . . . . . . . . . . . . . 69
A.4.2. The LSA Header . . . . . . . . . . . . . . . . . . . . 70
A.4.2.1. LSA Type . . . . . . . . . . . . . . . . . . . . . 72
A.4.3. Router-LSAs . . . . . . . . . . . . . . . . . . . . . 73
A.4.4. Network-LSAs . . . . . . . . . . . . . . . . . . . . . 76
A.4.5. Inter-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 77
A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
A.4.7. AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
Appendix B. Architectural Constants . . . . . . . . . . . . . . . 86
Appendix C. Configurable Constants . . . . . . . . . . . . . . . 86
C.1. Global Parameters . . . . . . . . . . . . . . . . . . . . 86
C.2. Area Parameters . . . . . . . . . . . . . . . . . . . . . 87
C.3. Router Interface Parameters . . . . . . . . . . . . . . . 88
C.4. Virtual Link Parameters . . . . . . . . . . . . . . . . . 90
C.5. NBMA Network Parameters . . . . . . . . . . . . . . . . . 91
C.6. Point-to-Multipoint Network Parameters . . . . . . . . . . 92
C.7. Host Route Parameters . . . . . . . . . . . . . . . . . . 92
A.4.6. Inter-Area-Router-LSAs . . . . . . . . . . . . . . . . 78
A.4.7. AS-External-LSAs . . . . . . . . . . . . . . . . . . . 79
A.4.8. NSSA-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.9. Link-LSAs . . . . . . . . . . . . . . . . . . . . . . 82
A.4.10. Intra-Area-Prefix-LSAs . . . . . . . . . . . . . . . . 84
Appendix B. Architectural Constants . . . . . . . . . . . . . . . 86
Appendix C. Configurable Constants . . . . . . . . . . . . . . . 86
C.1. Global Parameters . . . . . . . . . . . . . . . . . . . . 86
C.2. Area Parameters . . . . . . . . . . . . . . . . . . . . . 87
C.3. Router Interface Parameters . . . . . . . . . . . . . . . 88
C.4. Virtual Link Parameters . . . . . . . . . . . . . . . . . 90
C.5. NBMA Network Parameters . . . . . . . . . . . . . . . . . 91
C.6. Point-to-Multipoint Network Parameters . . . . . . . . . . 92
C.7. Host Route Parameters . . . . . . . . . . . . . . . . . . 92
This document describes the modifications to OSPF to support version 6 of the Internet Protocol (IPv6). The fundamental mechanisms of OSPF (flooding, Designated Router (DR) election, area support, (Shortest Path First) SPF calculations, etc.) remain unchanged. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6. These modifications will necessitate incrementing the protocol version from version 2 to version 3. OSPF for IPv6 is also referred to as OSPF version 3 (OSPFv3).
本文档描述了对OSPF的修改，以支持Internet协议（IPv6）版本6。OSPF的基本机制（泛洪、指定路由器（DR）选择、区域支持、（最短路径优先）SPF计算等）保持不变。然而，由于IPv4和IPv6之间协议语义的变化，或者仅仅为了处理IPv6地址大小的增加，一些更改是必要的。这些修改需要将协议版本从版本2增加到版本3。IPv6的OSPF也称为OSPF版本3（OSPFv3）。
This document is organized as follows. Section 2 describes the differences between OSPF for IPv4 (OSPF version 2) and OSPF for IPv6 (OSPF version 3) in detail. Section 3 describes the difference between RFC 2740 and this document. Section 4 provides implementation details for the changes. Appendix A gives the OSPF for IPv6 packet and Link State Advertisement (LSA) formats. Appendix B lists the OSPF architectural constants. Appendix C describes configuration parameters.
本文件的组织结构如下。第2节详细描述了用于IPv4的OSPF（OSPF版本2）和用于IPv6的OSPF（OSPF版本3）之间的差异。第3节描述了RFC 2740与本文件之间的差异。第4节提供了变更的实施细节。附录A给出了IPv6数据包和链路状态公告（LSA）格式的OSPF。附录B列出了OSPF体系结构常数。附录C描述了配置参数。
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-KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-关键词]中所述进行解释。
This document attempts to use terms from both the OSPF for IPv4 specification ([OSPFV2]) and the IPv6 protocol specifications ([IPV6]). This has produced a mixed result. Most of the terms used both by OSPF and IPv6 have roughly the same meaning (e.g.,
本文档试图使用OSPF for IPv4规范（[OSPFV2]）和IPv6协议规范（[IPv6]）中的术语。这产生了好坏参半的结果。OSPF和IPv6使用的大多数术语的含义大致相同（例如。，
interfaces). However, there are a few conflicts. IPv6 uses "link" similarly to IPv4 OSPF's "subnet" or "network". In this case, we have chosen to use IPv6's "link" terminology. "Link" replaces OSPF's "subnet" and "network" in most places in this document, although OSPF's network-LSA remains unchanged (and possibly unfortunately, a new link-LSA has also been created).
接口）。然而，也存在一些冲突。IPv6使用的“链路”类似于IPv4 OSPF的“子网”或“网络”。在本例中，我们选择使用IPv6的“链接”术语。虽然OSPF的网络LSA保持不变（可能不幸的是，还创建了一个新的链路LSA），但在本文档的大多数地方，“链路”取代了OSPF的“子网”和“网络”。
The names of some of the OSPF LSAs have also changed. See Section 2.8 for details.
一些OSPF LSA的名称也发生了变化。详见第2.8节。
In the context of this document, an OSPF instance is a separate protocol instance complete with its own protocol data structures (e.g., areas, interfaces, neighbors), link-state database, protocol state machines, and protocol processing (e.g., SPF calculation).
在本文档的上下文中，OSPF实例是一个单独的协议实例，具有自己的协议数据结构（例如，区域、接口、邻居）、链路状态数据库、协议状态机和协议处理（例如，SPF计算）。
Most of the algorithms from OSPF for IPv4 [OSPFV2] have been preserved in OSPF for IPv6. However, some changes have been necessary, either due to changes in protocol semantics between IPv4 and IPv6, or simply to handle the increased address size of IPv6.
来自OSPF for IPv4[OSPFV2]的大多数算法都保存在OSPF for IPv6中。然而，由于IPv4和IPv6之间协议语义的变化，或者仅仅为了处理IPv6地址大小的增加，一些更改是必要的。
The following subsections describe the differences between this document and [OSPFV2].
以下小节描述了本文件与[OSPFV2]之间的差异。
IPv6 uses the term "link" to indicate "a communication facility or medium over which nodes can communicate at the link layer" ([IPV6]). "Interfaces" connect to links. Multiple IPv6 subnets can be assigned to a single link, and two nodes can talk directly over a single link, even if they do not share a common IPv6 subnet (IPv6 prefix).
IPv6使用术语“链路”表示“节点可在链路层进行通信的通信设施或介质”（[IPv6]）。“接口”连接到链接。可以将多个IPv6子网分配给单个链路，两个节点可以通过单个链路直接通信，即使它们不共享公共IPv6子网（IPv6前缀）。
For this reason, OSPF for IPv6 runs per-link instead of the IPv4 behavior of per-IP-subnet. The terms "network" and "subnet" used in the IPv4 OSPF specification ([OSPFV2]) should generally be replaced by link. Likewise, an OSPF interface now connects to a link instead of an IP subnet.
由于这个原因，IPv6的OSPF在每个链路上运行，而不是在每个IP子网上运行IPv4行为。IPv4 OSPF规范（[OSPFV2]）中使用的术语“网络”和“子网”通常应替换为链路。同样，OSPF接口现在连接到链路而不是IP子网。
This change affects the receiving of OSPF protocol packets, the contents of Hello packets, and the contents of network-LSAs.
此更改会影响OSPF协议数据包的接收、Hello数据包的内容和网络LSA的内容。
In OSPF for IPv6, addressing semantics have been removed from the OSPF protocol packets and the main LSA types, leaving a network-protocol-independent core. In particular:
在用于IPv6的OSPF中，从OSPF协议包和主要LSA类型中删除了寻址语义，留下了独立于网络协议的核心。特别地：
o IPv6 addresses are not present in OSPF packets, except in LSA payloads carried by the Link State Update packets. See Section 2.7 for details.
o IPv6地址不存在于OSPF数据包中，链路状态更新数据包携带的LSA有效负载除外。详见第2.7节。
o Router-LSAs and network-LSAs no longer contain network addresses, but simply express topology information. See Section 2.8 for details.
o 路由器LSA和网络LSA不再包含网络地址，而是简单地表示拓扑信息。详见第2.8节。
o OSPF Router IDs, Area IDs, and LSA Link State IDs remain at the IPv4 size of 32 bits. They can no longer be assigned as (IPv6) addresses.
o OSPF路由器ID、区域ID和LSA链路状态ID保持在32位的IPv4大小。它们不能再被分配为（IPv6）地址。
o Neighboring routers are now always identified by Router ID. Previously, they had been identified by an IPv4 address on broadcast, NBMA (Non-Broadcast Multi-Access), and point-to-multipoint links.
o 相邻路由器现在总是通过路由器ID进行标识。以前，它们是通过广播上的IPv4地址、NBMA（非广播多址）和点对多点链路进行标识的。
Flooding scope for LSAs has been generalized and is now explicitly coded in the LSA's LS type field. There are now three separate flooding scopes for LSAs:
LSA的泛洪作用域已被推广，现在在LSA的LS类型字段中显式编码。LSA现在有三个独立的泛洪作用域：
o Link-local scope. LSA is only flooded on the local link and no further. Used for the new link-LSA. See Section 4.4.3.8 for details.
o 链接本地范围。LSA仅在本地链路上被淹没，没有进一步扩展。用于新链路LSA。详见第4.4.3.8节。
o Area scope. LSA is only flooded throughout a single OSPF area. Used for router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs.
o 区域范围。LSA仅淹没在整个OSPF区域内。用于路由器LSA、网络LSA、区域间前缀LSA、区域间路由器LSA和区域内前缀LSA。
o AS scope. LSA is flooded throughout the routing domain. Used for AS-external-LSAs. A router that originates AS scoped LSAs is considered an AS Boundary Router (ASBR) and will set its E-bit in router-LSAs for regular areas.
o 作为范围。LSA被淹没在整个路由域中。用作外部LSA。作为作用域LSA发起的路由器被视为AS边界路由器（ASBR），并将在常规区域的路由器LSA中设置其E位。
OSPF now supports the ability to run multiple OSPF protocol instances on a single link. For example, this may be required on a NAP segment shared between several providers. Providers may be supporting separate OSPF routing domains that wish to remain separate even though they have one or more physical network segments (i.e., links) in common. In OSPF for IPv4, this was supported in a haphazard fashion using the authentication fields in the OSPF for IPv4 header.
OSPF现在支持在单个链路上运行多个OSPF协议实例。例如，在多个提供者之间共享的NAP段上可能需要这样做。提供商可能支持希望保持独立的单独OSPF路由域，即使它们有一个或多个共同的物理网段（即链路）。在OSPF for IPv4中，使用OSPF for IPv4报头中的身份验证字段以随意的方式支持这一点。
Another use for running multiple OSPF instances is if you want, for one reason or another, to have a single link belong to two or more OSPF areas.
运行多个OSPF实例的另一个用途是，出于这样或那样的原因，如果您希望一条链路属于两个或多个OSPF区域。
Support for multiple protocol instances on a link is accomplished via an "Instance ID" contained in the OSPF packet header and OSPF interface data structures. Instance ID solely affects the reception of OSPF packets and applies to normal OSPF interfaces and virtual links.
通过OSPF数据包头和OSPF接口数据结构中包含的“实例ID”实现对链路上多个协议实例的支持。实例ID仅影响OSPF数据包的接收，并适用于正常OSPF接口和虚拟链路。
IPv6 link-local addresses are for use on a single link, for purposes of neighbor discovery, auto-configuration, etc. IPv6 routers do not forward IPv6 datagrams having link-local source addresses [IP6ADDR]. Link-local unicast addresses are assigned from the IPv6 address range FE80/10.
IPv6链路本地地址用于单个链路，用于邻居发现、自动配置等。IPv6路由器不转发具有链路本地源地址[IP6ADDR]的IPv6数据报。链路本地单播地址从IPv6地址范围FE80/10分配。
OSPF for IPv6 assumes that each router has been assigned link-local unicast addresses on each of the router's attached physical links [IP6ADDR]. On all OSPF interfaces except virtual links, OSPF packets are sent using the interface's associated link-local unicast address as the source address. A router learns the link-local addresses of all other routers attached to its links and uses these addresses as next-hop information during packet forwarding.
OSPF for IPv6假定每个路由器已在每个路由器连接的物理链路上分配链路本地单播地址[IP6ADDR]。在除虚拟链路以外的所有OSPF接口上，OSPF数据包使用接口的关联链路本地单播地址作为源地址发送。路由器学习连接到其链路的所有其他路由器的链路本地地址，并在数据包转发期间使用这些地址作为下一跳信息。
On virtual links, a global scope IPv6 address MUST be used as the source address for OSPF protocol packets.
在虚拟链路上，全局作用域IPv6地址必须用作OSPF协议数据包的源地址。
Link-local addresses appear in OSPF link-LSAs (see Section 4.4.3.8). However, link-local addresses are not allowed in other OSPF LSA types. In particular, link-local addresses MUST NOT be advertised in inter-area-prefix-LSAs (Section 4.4.3.4), AS-external-LSAs (Section 4.4.3.6), NSSA-LSAs (Section 4.4.3.7), or intra-area-prefix-LSAs (Section 4.4.3.9).
链路本地地址出现在OSPF链路LSA中（见第4.4.3.8节）。但是，在其他OSPF LSA类型中不允许使用链路本地地址。特别是，链路本地地址不得在区域间前缀LSA（第4.4.3.4节）、外部LSA（第4.4.3.6节）、NSSA LSA（第4.4.3.7节）或区域内前缀LSA（第4.4.3.9节）中公布。
In OSPF for IPv6, authentication has been removed from the OSPF protocol. The "AuType" and "Authentication" fields have been removed from the OSPF packet header, and all authentication-related fields have been removed from the OSPF area and interface data structures.
在用于IPv6的OSPF中，身份验证已从OSPF协议中删除。“AuType”和“Authentication”字段已从OSPF数据包头中删除，所有与身份验证相关的字段已从OSPF区域和接口数据结构中删除。
When running over IPv6, OSPF relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/confidentiality of routing exchanges.
在IPv6上运行时，OSPF依赖于IP身份验证标头（请参见[IPAUTH]）和IP封装安全负载（请参见[IPESP]），如[OSPFV3-AUTH]中所述，以确保路由交换的完整性和身份验证/机密性。
Protection of OSPF packet exchanges against accidental data corruption is provided by the standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).
标准IPv6上层校验和（如[IPv6]第8.1节所述）提供了防止意外数据损坏的OSPF数据包交换保护，覆盖整个OSPF数据包和前置IPv6伪报头（见附录A.3.1）。
OSPF for IPv6 runs directly over IPv6. Aside from this, all addressing semantics have been removed from the OSPF packet headers, making it essentially "network-protocol-independent". All addressing information is now contained in the various LSA types only.
用于IPv6的OSPF直接在IPv6上运行。除此之外，所有寻址语义都已从OSPF数据包头中删除，使其基本上“与网络协议无关”。所有寻址信息现在仅包含在各种LSA类型中。
In detail, changes in OSPF packet format consist of the following:
具体而言，OSPF数据包格式的更改包括以下内容：
o The OSPF version number has been incremented from 2 to 3.
o OSPF版本号已从2增加到3。
o The Options field in Hello packets and Database Description packets has been expanded to 24 bits.
o Hello数据包和数据库描述数据包中的选项字段已扩展为24位。
o The Authentication and AuType fields have been removed from the OSPF packet header (see Section 2.6).
o 认证和AuType字段已从OSPF数据包头中删除（参见第2.6节）。
o The Hello packet now contains no address information at all. Rather, it now includes an Interface ID that the originating router has assigned to uniquely identify (among its own interfaces) its interface to the link. This Interface ID will be used as the network-LSA's Link State ID if the router becomes the Designated Router on the link.
o Hello数据包现在根本不包含地址信息。相反，它现在包括一个接口ID，发起路由器已分配该ID，以唯一标识（在其自身接口中）其与链路的接口。如果路由器成为链路上的指定路由器，则此接口ID将用作网络LSA的链路状态ID。
o Two Options bits, the "R-bit" and the "V6-bit", have been added to the Options field for processing router-LSAs during the SPF calculation (see Appendix A.2). If the "R-bit" is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward transit traffic; this can be used in multi-homed hosts that want to participate in the routing protocol. The V6-bit specializes the R-bit; if the V6-bit is clear, an OSPF speaker can participate in OSPF topology distribution without being used to forward IPv6 datagrams. If the R-bit is set and the V6-bit is clear, IPv6 datagrams are not forwarded but datagrams belonging to another protocol family may be forwarded.
o 两个选项位“R位”和“V6位”已添加到选项字段，用于在SPF计算期间处理路由器LSA（见附录A.2）。如果“R位”是清晰的，则OSPF扬声器可以参与OSPF拓扑分布，而不用于转发中转业务；这可用于希望参与路由协议的多宿主主机。V6位专门用于R位；如果V6位已清除，则OSPF扬声器可以参与OSPF拓扑分布，而无需转发IPv6数据报。如果设置了R位且清除了V6位，则不会转发IPv6数据报，但可以转发属于另一个协议系列的数据报。
o The OSPF packet header now includes an "Instance ID" that allows multiple OSPF protocol instances to be run on a single link (see Section 2.4).
o OSPF数据包头现在包括一个“实例ID”，允许在单个链路上运行多个OSPF协议实例（参见第2.4节）。
All addressing semantics have been removed from the LSA header, router-LSAs, and network-LSAs. These two LSAs now describe the routing domain's topology in a network-protocol-independent manner. New LSAs have been added to distribute IPv6 address information and data required for next-hop resolution. The names of some of IPv4's LSAs have been changed to be more consistent with each other.
所有寻址语义都已从LSA头、路由器LSA和网络LSA中删除。这两个LSA现在以独立于网络协议的方式描述路由域的拓扑。添加了新的LSA以分发下一跳解析所需的IPv6地址信息和数据。IPv4的某些LSA的名称已更改，以便彼此更加一致。
In detail, changes in LSA format consist of the following:
具体而言，LSA格式的更改包括以下内容：
o The Options field has been removed from the LSA header, expanded to 24 bits, and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. See Appendix A.2 for details.
o 选项字段已从LSA标头中删除，扩展到24位，并移动到路由器LSA、网络LSA、区域间路由器LSA和链路LSA的主体中。详见附录A.2。
o The LSA Type field has been expanded (into the former Options space) to 16 bits, with the upper three bits encoding flooding scope and the handling of unknown LSA types (see Section 2.9).
o LSA类型字段已扩展（进入前一个选项空间）到16位，上面的三位编码泛洪范围和未知LSA类型的处理（见第2.9节）。
o Addresses in LSAs are now expressed as [prefix, prefix length] instead of [address, mask] (see Appendix A.4.1). The default route is expressed as a prefix with length 0.
o LSA中的地址现在表示为[前缀，前缀长度]，而不是[地址，掩码]（见附录A.4.1）。默认路由表示为长度为0的前缀。
o Router-LSAs and network-LSAs now have no address information and are network protocol independent.
o 路由器LSA和网络LSA现在没有地址信息，并且与网络协议无关。
o Router interface information MAY be spread across multiple router-LSAs. Receivers MUST concatenate all the router-LSAs originated by a given router when running the SPF calculation.
o 路由器接口信息可以跨多个路由器LSA传播。在运行SPF计算时，接收器必须连接由给定路由器发起的所有路由器LSA。
o A new LSA called the link-LSA has been introduced. Link-LSAs have link-local flooding scope; they are never flooded beyond the link with which they are associated. Link-LSAs have three purposes: 1) they provide the router's link-local address to all other routers attached to the link, 2) they inform other routers attached to the link of a list of IPv6 prefixes to associate with the link, and 3) they allow the router to advertise a collection of Options bits to associate with the network-LSA that will be originated for the link. See Section 4.4.3.8 for details.
o 引入了一种称为链路LSA的新LSA。链路LSA具有链路局部泛洪范围；它们永远不会淹没在与之相关的链接之外。链路LSA有三个用途：1）它们向连接到该链路的所有其他路由器提供路由器的链路本地地址，2）它们通知连接到该链路的其他路由器与该链路关联的IPv6前缀列表，以及3）它们允许路由器公布选项位的集合，以与将为链路发起的网络LSA相关联。详见第4.4.3.8节。
o In IPv4, the router-LSA carries a router's IPv4 interface addresses, the IPv4 equivalent of link-local addresses. These are only used when calculating next hops during the OSPF routing calculation (see Section 16.1.1 of [OSPFV2]), so they do not need to be flooded past the local link. Hence, using link-LSAs to distribute these addresses is more efficient. Note that link-local addresses cannot be learned through the reception of Hellos
o 在IPv4中，路由器LSA携带路由器的IPv4接口地址，即与链路本地地址等效的IPv4地址。这些仅在OSPF路由计算期间计算下一跳时使用（见[OSPFV2]第16.1.1节），因此它们不需要淹没本地链路。因此，使用链路LSA分发这些地址更有效。请注意，无法通过接收Hellos来了解链路本地地址
in all cases. On NBMA links, next-hop routers do not necessarily exchange Hellos. Rather, these routers learn of each other's existence by way of the Designated Router (DR).
在所有情况下。在NBMA链路上，下一跳路由器不一定交换HELOS。相反，这些路由器通过指定路由器（DR）了解彼此的存在。
o The Options field in the network LSA is set to the logical OR of the Options that each router on the link advertises in its link-LSA.
o 网络LSA中的选项字段设置为链路上的每个路由器在其链路LSA中播发的选项的逻辑OR。
o Type-3 summary-LSAs have been renamed "inter-area-prefix-LSAs". Type-4 summary LSAs have been renamed "inter-area-router-LSAs".
o 类型3汇总LSA已重命名为“区域间前缀LSA”。类型4汇总LSA已重命名为“区域间路由器LSA”。
o The Link State ID in inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and AS-external-LSAs has lost its addressing semantics and now serves solely to identify individual pieces of the Link State Database. All addresses or Router IDs that were formerly expressed by the Link State ID are now carried in the LSA bodies.
o 区域间前缀LSA、区域间路由器LSA、NSSA LSA和AS外部LSA中的链路状态ID已失去其寻址语义，现在仅用于标识链路状态数据库的各个部分。以前由链路状态ID表示的所有地址或路由器ID现在都包含在LSA主体中。
o Network-LSAs and link-LSAs are the only LSAs whose Link State ID carries additional meaning. For these LSAs, the Link State ID is always the Interface ID of the originating router on the link being described. For this reason, network-LSAs and link-LSAs are now the only LSAs whose size cannot be limited: a network-LSA MUST list all routers connected to the link and a link-LSA MUST list all of a router's addresses on the link.
o 网络LSA和链路LSA是链路状态ID具有附加含义的唯一LSA。对于这些LSA，链路状态ID始终是所描述链路上发起路由器的接口ID。因此，网络LSA和链路LSA现在是唯一的大小不能限制的LSA：网络LSA必须列出连接到链路的所有路由器，链路LSA必须列出链路上路由器的所有地址。
o A new LSA called the intra-area-prefix-LSA has been introduced. This LSA carries all IPv6 prefix information that in IPv4 is included in router-LSAs and network-LSAs. See Section 4.4.3.9 for details.
o 引入了一种称为区域内前缀LSA的新LSA。此LSA携带IPv4中包含在路由器LSA和网络LSA中的所有IPv6前缀信息。详见第4.4.3.9节。
o Inclusion of a forwarding address or external route tag in AS-external-LSAs is now optional. In addition, AS-external-LSAs can now reference another LSA, for inclusion of additional route attributes that are outside the scope of the OSPF protocol. For example, this reference could be used to attach BGP path attributes to external routes.
o 在AS外部LSA中包含转发地址或外部路由标记现在是可选的。此外，由于外部LSA现在可以引用另一个LSA，因此包含OSPF协议范围之外的其他路由属性。例如，此引用可用于将BGP路径属性附加到外部路由。
Handling of unknown LSA types has been made more flexible so that, based on the LS type, unknown LSA types are either treated as having link-local flooding scope, or are stored and flooded as if they were understood. This behavior is explicitly coded in the LSA Handling bit of the link state header's LS type field (see the U-bit in Appendix A.4.2.1).
对未知LSA类型的处理变得更加灵活，因此，基于LS类型，未知LSA类型要么被视为具有链路局部泛洪范围，要么被存储和泛洪，就好像它们被理解一样。该行为在链路状态报头的LS类型字段的LSA处理位中明确编码（见附录A.4.2.1中的U位）。
The IPv4 OSPF behavior of simply discarding unknown types is unsupported due to the desire to mix router capabilities on a single link. Discarding unknown types causes problems when the Designated Router supports fewer options than the other routers on the link.
由于希望在单个链路上混合路由器功能，不支持简单丢弃未知类型的IPv4 OSPF行为。当指定路由器支持的选项少于链路上的其他路由器时，丢弃未知类型会导致问题。
In OSPF for IPv4, stub and NSSA areas were designed to minimize link-state database and routing table sizes for the areas' internal routers. This allows routers with minimal resources to participate in even very large OSPF routing domains.
在IPv4的OSPF中，存根和NSSA区域被设计为最小化区域内部路由器的链路状态数据库和路由表大小。这允许资源最少的路由器参与甚至非常大的OSPF路由域。
In OSPF for IPv6, the concept of stub and NSSA areas is retained. In IPv6, of the mandatory LSA types, stub areas carry only router-LSAs, network-LSAs, inter-area-prefix-LSAs, link-LSAs, and intra-area-prefix-LSAs. NSSA areas are restricted to these types and, of course, NSSA-LSAs. This is the IPv6 equivalent of the LSA types carried in IPv4 stub areas: router-LSAs, network-LSAs, type 3 summary-LSAs and for NSSA areas: stub area types and NSSA-LSAs.
在用于IPv6的OSPF中，存根和NSSA区域的概念被保留。在IPv6中，在强制LSA类型中，存根区域仅承载路由器LSA、网络LSA、区域间前缀LSA、链路LSA和区域内前缀LSA。NSSA区域仅限于这些类型，当然还有NSSA LSA。这是IPv4存根区域中承载的LSA类型的IPv6等价物：路由器LSA、网络LSA、类型3摘要LSA和NSSA区域：存根区域类型和NSSA LSA。
In OSPF for IPv6, neighboring routers on a given link are always identified by their OSPF Router ID. This contrasts with the IPv4 behavior where neighbors on point-to-point networks and virtual links are identified by their Router IDs while neighbors on broadcast, NBMA, and point-to-multipoint links are identified by their IPv4 interface addresses.
在用于IPv6的OSPF中，给定链路上的相邻路由器始终通过其OSPF路由器ID进行标识。这与IPv4行为形成对比，在IPv4行为中，点到点网络和虚拟链路上的邻居通过其路由器ID进行标识，而广播、NBMA、，点对多点链路由其IPv4接口地址标识。
This change affects the reception of OSPF packets (see Section 8.2 of [OSPFV2]), the lookup of neighbors (Section 10 of [OSPFV2]), and the reception of Hello packets (Section 10.5 of [OSPFV2]).
此更改影响OSPF数据包的接收（见[OSPFV2]第8.2节）、邻居查找（见[OSPFV2]第10节）和Hello数据包的接收（见[OSPFV2]第10.5节）。
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
路由器ID 0.0.0.0是保留的，不应使用。
OSPFv3 implementations based on RFC 2740 will fully interoperate with implementations based on this specification. There are, however, some protocol additions and changes (all of which are backward compatible).
基于RFC 2740的OSPFv3实现将与基于本规范的实现完全互操作。但是，还有一些协议的添加和更改（所有这些都是向后兼容的）。
This protocol feature was only partially specified in the RFC 2740. The level of specification was insufficient to implement the feature. Section 4.9 specifies the additions and clarifications necessary for implementation. They are fully compatible with RFC 2740.
RFC 2740中仅部分指定了此协议功能。规范级别不足以实现该功能。第4.9节规定了实施所需的补充和澄清。它们与RFC 2740完全兼容。
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the feature. There are no known implementations. Multicast Extensions to OSPF (MOSPF) support and its attendant protocol fields have been deprecated from OSPFv3. Refer to Section 4.4.3.2, Section 4.4.3.4, Section 4.4.3.6, Section 4.4.3.7, Appendix A.2, Appendix A.4.2.1, Appendix A.4.3, Appendix A.4.1.1, and Section 7.1.
RFC 2740中仅部分指定了此协议功能。规范级别不足以实现该功能。没有已知的实现。OSPF（MOSPF）支持的多播扩展及其伴随协议字段已从OSPFv3中弃用。参考第4.4.3.2节、第4.4.3.4节、第4.4.3.6节、第4.4.3.7节、附录A.2、附录A.4.2.1、附录A.4.3、附录A.4.1.1和第7.1节。
This protocol feature was only partially specified in RFC 2740. The level of specification was insufficient to implement the function. This document includes an NSSA specification unique to OSPFv3. This specification coupled with [NSSA] provide sufficient specification for implementation. Refer to Section 4.8.5, Appendix A.4.3, Appendix A.4.8, and [NSSA].
RFC 2740中仅部分指定了此协议功能。规范级别不足以实现该功能。本文件包括OSPFv3独有的NSSA规范。本规范加上[NSSA]为实现提供了充分的规范。参考第4.8.5节、附录A.4.3、附录A.4.8和[NSSA]。
In RFC 2740 [OSPFV3], flooding of unknown LSA was restricted within stub and NSSA areas. The text describing this restriction is included below.
在RFC 2740[OSPFV3]中，未知LSA的泛滥限制在存根和NSSA区域内。下面包含描述此限制的文本。
However, unlike in IPv4, IPv6 allows LSAs with unrecognized LS types to be labeled "Store and flood the LSA, as if type understood" (see the U-bit in Appendix A.4.2.1). Uncontrolled introduction of such LSAs could cause a stub area's link-state database to grow larger than its component routers' capacities.
但是，与IPv4不同，IPv6允许将具有无法识别的LS类型的LSA标记为“存储并泛洪LSA，就像理解类型一样”（参见附录A.4.2.1中的U位）。此类LSA的不受控制的引入可能会导致存根区域的链路状态数据库增长超过其组件路由器的容量。
To guard against this, the following rule regarding stub areas has been established: an LSA whose LS type is unrecognized can only be flooded into/throughout a stub area if both a) the LSA has area or link-local flooding scope and b) the LSA has U-bit set to 0. See Section 3.5 for details.
为了防止这种情况，建立了以下关于存根区域的规则：如果LSA具有区域或链路局部泛洪作用域，并且LSA的U位设置为0，则LS类型无法识别的LSA只能泛洪到存根区域/整个存根区域。详见第3.5节。
This restriction has been deprecated. OSPFv3 routers will flood link and area scope LSAs whose LS type is unrecognized and whose U-bit is set to 1 throughout stub and NSSA areas. There are no backward-compatibility issues other than OSPFv3 routers still supporting the restriction may not propagate newly defined LSA types.
此限制已被弃用。OSPFv3路由器将在整个存根和NSSA区域内泛洪链路和区域作用域LSA，其LS类型无法识别，且其U位设置为1。除了仍然支持限制的OSPFv3路由器不能传播新定义的LSA类型之外，没有向后兼容性问题。
The LinkLSASuppression interface configuration parameter has been added. If LinkLSASuppression is configured for an interface and the interface type is not broadcast or NBMA, origination of the link-LSA
已添加LinkLSASuppression接口配置参数。如果为接口配置了LinkLSA抑制，且接口类型不是广播或NBMA，则链路LSA的发起
may be suppressed. The LinkLSASuppression interface configuration parameter is described in Appendix C.3. Section 4.8.2 and Section 4.4.3.8 were updated to reflect the parameter's usage.
可能会被压制。LinkLSASuppression接口配置参数如附录C.3所述。第4.8.2节和第4.4.3.8节已更新，以反映参数的使用情况。
The LSA Options and Prefix Options fields have been updated to reflect recent protocol additions. Specifically, bits related to MOSPF have been deprecated, Options field bits common with OSPFv2 have been reserved, and the DN-bit has been added to the prefix-options. Refer to Appendix A.2 and Appendix A.4.1.1.
LSA选项和前缀选项字段已更新，以反映最近添加的协议。具体而言，与MOSPF相关的位已被弃用，与OSPFv2共用的选项字段位已被保留，DN位已添加到前缀选项中。参考附录A.2和附录A.4.1.1。
All references to IPv6 site-local addresses have been removed.
已删除对IPv6站点本地地址的所有引用。
When going from IPv4 to IPv6, the basic OSPF mechanisms remain unchanged from those documented in [OSPFV2]. These mechanisms are briefly outlined in Section 4 of [OSPFV2]. Both IPv6 and IPv4 have a link-state database composed of LSAs and synchronized between adjacent routers. Initial synchronization is performed through the Database Exchange process, which includes the exchange of Database Description, Link State Request, and Link State Update packets. Thereafter, database synchronization is maintained via flooding, utilizing Link State Update and Link State Acknowledgment packets. Both IPv6 and IPv4 use OSPF Hello packets to discover and maintain neighbor relationships, as well as to elect Designated Routers and Backup Designated Routers on broadcast and NBMA links. The decision as to which neighbor relationships become adjacencies, and the basic ideas behind inter-area routing, importing external information in AS-external-LSAs, and the various routing calculations are also the same.
从IPv4过渡到IPv6时，基本OSPF机制与[OSPFV2]中记录的机制保持不变。[OSPFV2]第4节简要概述了这些机制。IPv6和IPv4都有一个由LSA组成的链路状态数据库，并在相邻路由器之间进行同步。初始同步通过数据库交换过程执行，该过程包括数据库描述、链路状态请求和链路状态更新数据包的交换。此后，利用链路状态更新和链路状态确认数据包，通过泛洪保持数据库同步。IPv6和IPv4都使用OSPF Hello数据包来发现和维护邻居关系，以及在广播和NBMA链路上选择指定路由器和备份指定路由器。关于哪些邻居关系成为邻接关系的决定，以及区域间路由、将外部信息作为外部LSA导入的基本思想，以及各种路由计算也是相同的。
In particular, the following IPv4 OSPF functionality described in [OSPFV2] remains completely unchanged for IPv6:
具体而言，[OSPFV2]中描述的以下IPv4 OSPF功能对于IPv6保持完全不变：
o Both IPv4 and IPv6 use OSPF packet types described in Section 4.3 of [OSPFV2], namely: Hello, Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets. While in some cases (e.g., Hello packets) their format has changed somewhat, the functions of the various packet types remain the same.
o IPv4和IPv6都使用[OSPFV2]第4.3节中描述的OSPF数据包类型，即：Hello、数据库描述、链路状态请求、链路状态更新和链路状态确认数据包。虽然在某些情况下（例如，Hello数据包），其格式有所改变，但各种数据包类型的功能保持不变。
o The system requirements for an OSPF implementation remain unchanged, although OSPF for IPv6 requires an IPv6 protocol stack (from the network layer on down) since it runs directly over the IPv6 network layer.
o OSPF实现的系统要求保持不变，尽管OSPF for IPv6需要IPv6协议栈（从网络层向下），因为它直接在IPv6网络层上运行。
o The discovery and maintenance of neighbor relationships, and the selection and establishment of adjacencies, remain the same. This includes election of the Designated Router and Backup Designated Router on broadcast and NBMA links. These mechanisms are described in Sections 7, 7.1, 7.2, 7.3, 7.4, and 7.5 of [OSPFV2].
o 邻居关系的发现和维护以及邻接关系的选择和建立都是一样的。这包括在广播和NBMA链路上选择指定路由器和备份指定路由器。[OSPFV2]第7、7.1、7.2、7.3、7.4和7.5节对这些机制进行了描述。
o The link types (or equivalently, interface types) supported by OSPF remain unchanged, namely: point-to-point, broadcast, NBMA, point-to-multipoint, and virtual links.
o OSPF支持的链路类型（或等效的接口类型）保持不变，即：点对点、广播、NBMA、点对多点和虚拟链路。
o The interface state machine, including the list of OSPF interface states and events, and the Designated Router and Backup Designated Router election algorithm remain unchanged. These are described in Sections 9.1, 9.2, 9.3, and 9.4 of [OSPFV2].
o 接口状态机，包括OSPF接口状态和事件列表，以及指定路由器和备份指定路由器选择算法保持不变。[OSPFV2]的第9.1、9.2、9.3和9.4节对此进行了描述。
o The neighbor state machine, including the list of OSPF neighbor states and events, remains unchanged. The neighbor state machine is described in Sections 10.1, 10.2, 10.3, and 10.4 of [OSPFV2].
o 邻居状态机（包括OSPF邻居状态和事件列表）保持不变。[OSPFV2]第10.1、10.2、10.3和10.4节描述了相邻状态机。
o Aging of the link-state database, as well as flushing LSAs from the routing domain through the premature aging process, remains unchanged from the description in Sections 14 and 14.1 of [OSPFV2].
o 链路状态数据库的老化，以及通过过早老化过程从路由域刷新LSA，与[OSPFV2]第14节和第14.1节中的描述保持不变。
However, some OSPF protocol mechanisms have changed as previously described in Section 2 herein. These changes are explained in detail in the following subsections, making references to the appropriate sections of [OSPFV2].
然而，一些OSPF协议机制已经改变，如本文第2节所述。以下小节详细解释了这些变更，并参考了[OSPFV2]的相应章节。
The following subsections provide a recipe for turning an IPv4 OSPF implementation into an IPv6 OSPF implementation.
以下小节提供了将IPv4 OSPF实现转换为IPv6 OSPF实现的方法。
The major OSPF data structures are the same for both IPv4 and IPv6: areas, interfaces, neighbors, the link-state database, and the routing table. The top-level data structures for IPv6 remain those listed in Section 5 of [OSPFV2], with the following modifications:
IPv4和IPv6的主要OSPF数据结构相同：区域、接口、邻居、链路状态数据库和路由表。IPv6的顶级数据结构仍然是[OSPFV2]第5节中列出的数据结构，但有以下修改：
o All LSAs with known LS type and AS flooding scope appear in the top-level data structure, instead of belonging to a specific area or link. AS-external-LSAs are the only LSAs defined by this specification that have AS flooding scope. LSAs with unknown LS
o 所有具有已知LS类型和AS泛洪范围的LSA都显示在顶级数据结构中，而不属于特定区域或链接。AS外部LSA是本规范定义的唯一具有AS泛洪范围的LSA。具有未知LS的lsa
type, U-bit set to 1 (flood even when unrecognized), and AS flooding scope also appear in the top-level data structure.
类型，U位设置为1（即使无法识别也会泛洪），并且AS泛洪范围也会显示在顶级数据结构中。
The IPv6 area data structure contains all elements defined for IPv4 areas in Section 6 of [OSPFV2]. In addition, all LSAs of known type that have area flooding scope are contained in the IPv6 area data structure. This always includes the following LSA types: router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, and intra-area-prefix-LSAs. LSAs with unknown LS type, U-bit set to 1 (flood even when unrecognized), and area scope also appear in the area data structure. NSSA-LSAs are also included in an NSSA area's data structure.
IPv6区域数据结构包含[OSPFV2]第6节中为IPv4区域定义的所有元素。此外，具有区域泛洪作用域的所有已知类型的LSA都包含在IPv6区域数据结构中。这始终包括以下LSA类型：路由器LSA、网络LSA、区域间前缀LSA、区域间路由器LSA和区域内前缀LSA。具有未知LS类型、U位设置为1（即使无法识别也会泛洪）和区域范围的LSA也会出现在区域数据结构中。NSSA LSA也包含在NSSA区域的数据结构中。
In OSPF for IPv6, an interface connects a router to a link. The IPv6 interface structure modifies the IPv4 interface structure (as defined in Section 9 of [OSPFV2]) as follows:
在用于IPv6的OSPF中，接口将路由器连接到链路。IPv6接口结构修改IPv4接口结构（定义见[OSPFV2]第9节），如下所示：
Interface ID Every interface is assigned an Interface ID, which uniquely identifies the interface with the router. For example, some implementations MAY be able to use the MIB-II IfIndex ([INTFMIB]) as the Interface ID. The Interface ID appears in Hello packets sent out the interface, the link-local-LSA originated by the router for the attached link, and the router-LSA originated by the router-LSA for the associated area. It will also serve as the Link State ID for the network-LSA that the router will originate for the link if the router is elected Designated Router. The Interface ID for a virtual link is independent of the Interface ID of the outgoing interface it traverses in the transit area.
接口ID为每个接口分配一个接口ID，该ID唯一地标识与路由器的接口。例如，一些实现可能能够使用MIB-II IfIndex（[INTFMIB]）作为接口ID。接口ID出现在发送出接口的Hello数据包中，由路由器为连接的链路发起的链路本地LSA，以及由路由器LSA为相关区域发起的路由器LSA。它还将用作网络LSA的链路状态ID，如果路由器被选为指定路由器，则路由器将为链路发起该LSA。虚拟链路的接口ID独立于它在传输区域中穿过的传出接口的接口ID。
Instance ID Every interface is assigned an Instance ID. This should default to 0. It is only necessary to assign a value other than 0 on those links that will contain multiple separate communities of OSPF routers. For example, suppose that there are two communities of routers on a given ethernet segment that you wish to keep separate. The first community is assigned an Instance ID of 0 and all the routers in the first community will be assigned 0 as the Instance ID for interfaces connected to the ethernet segment. An Instance ID of 1 is assigned to the other routers' interfaces connected to the ethernet segment. The OSPF transmit and receive processing (see Section 4.2) will then keep the two communities separate.
实例ID每个接口都分配了一个实例ID。这应该默认为0。只需在包含多个单独的OSPF路由器社区的那些链路上指定除0以外的值。例如，假设在给定的以太网段上有两个路由器社区，您希望将它们分开。第一个社区被分配一个实例ID 0，第一个社区中的所有路由器将被分配0作为连接到以太网段的接口的实例ID。实例ID为1分配给连接到以太网段的其他路由器接口。OSPF发送和接收处理（见第4.2节）将使两个社区保持分离。
List of LSAs with link-local scope All LSAs with link-local scope and that were originated/flooded on the link belong to the interface structure that connects to the link. This includes the collection of the link's link-LSAs.
具有链接本地作用域的LSA列表所有具有链接本地作用域且在链接上发起/淹没的LSA都属于连接到链接的接口结构。这包括链接的链接LSA的集合。
IP interface address For IPv6, the IPv6 address appearing in the source of OSPF packets sent on the interface is almost always a link-local address. The one exception is for virtual links that MUST use one of the router's own global IPv6 addresses as IP interface address.
IP接口地址对于IPv6，在接口上发送的OSPF数据包源中出现的IPv6地址几乎总是链路本地地址。一个例外是虚拟链路必须使用路由器自己的一个全局IPv6地址作为IP接口地址。
List of link prefixes A list of IPv6 prefixes can be configured for the attached link. These will be advertised by the router in link-LSAs, so that they can be advertised by the link's Designated Router in intra-area-prefix-LSAs.
链路前缀列表可以为连接的链路配置IPv6前缀列表。这些将由路由器在链路lsa中进行通告，以便它们可以由链路的指定路由器在区域内前缀lsa中进行通告。
In OSPF for IPv6, each router interface has a single metric representing the cost of sending packets on the interface. In addition, OSPF for IPv6 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) as described in [OSPFV3-AUTH] to ensure integrity and authentication/ confidentiality of routing exchanges. For this reason, AuType and Authentication key are not associated with IPv6 OSPF interfaces.
在用于IPv6的OSPF中，每个路由器接口都有一个表示在接口上发送数据包的成本的度量。此外，用于IPv6的OSPF依赖于IP身份验证标头（参见[IPAUTH]）和IP封装安全负载（参见[IPESP]），如[OSPFV3-AUTH]中所述，以确保路由交换的完整性和身份验证/机密性。因此，AuType和身份验证密钥与IPv6 OSPF接口不关联。
Interface states, events, and the interface state machine remain unchanged from IPv4 as documented in Sections 9.1, 9.2, and 9.3 of [OSPFV2] respectively. The Designated Router and Backup Designated Router election algorithm also remains unchanged from the IPv4 election in Section 9.4 of [OSPFV2].
如[OSPFV2]第9.1、9.2和9.3节所述，与IPv4相比，接口状态、事件和接口状态机保持不变。与[OSPFV2]第9.4节中的IPv4选择相比，指定路由器和备份指定路由器选择算法也保持不变。
The neighbor structure performs the same function in both IPv6 and IPv4. Namely, it collects all information required to form an adjacency between two routers when such an adjacency becomes necessary. Each neighbor structure is bound to a single OSPF interface. The differences between the IPv6 neighbor structure and the neighbor structure defined for IPv4 in Section 10 of [OSPFV2] are:
邻居结构在IPv6和IPv4中执行相同的功能。也就是说，当需要在两个路由器之间形成邻接时，它收集所有需要的信息。每个邻居结构都绑定到一个OSPF接口。IPv6邻居结构与[OSPFV2]第10节中为IPv4定义的邻居结构之间的区别如下：
Neighbor's Interface ID The Interface ID that the neighbor advertises in its Hello packets must be recorded in the neighbor structure. The router will include the neighbor's Interface ID in the router's router-LSA when either a) advertising a point-to-point or point-to-multipoint link to the neighbor or b) advertising a link to a network where the neighbor has become the Designated Router.
邻居的接口ID邻居在其Hello数据包中播发的接口ID必须记录在邻居结构中。当a）宣传到邻居的点对点或点对多点链路或b）宣传到邻居已成为指定路由器的网络的链路时，路由器将在路由器的路由器LSA中包括邻居的接口ID。
Neighbor IP address The neighbor's IPv6 address contained as the source address in OSPF for IPv6 packets. This will be an IPv6 link-local address for all link types except virtual links.
邻居IP地址作为IPv6数据包的源地址包含在OSPF中的邻居的IPv6地址。这将是除虚拟链路之外的所有链路类型的IPv6链路本地地址。
Neighbor's Designated Router The neighbor's choice of Designated Router is now encoded as a Router ID instead of as an IP address.
邻居的指定路由器现在，邻居选择的指定路由器编码为路由器ID，而不是IP地址。
Neighbor's Backup Designated Router The neighbor's choice of Backup Designated Router is now encoded as a Router ID instead of as an IP address.
邻居的备份指定路由器邻居选择的备份指定路由器现在编码为路由器ID，而不是IP地址。
Neighbor states, events, and the neighbor state machine remain unchanged from IPv4 as documented in Sections 10.1, 10.2, and 10.3 of [OSPFV2] respectively. The decision as to which adjacencies to form also remains unchanged from the IPv4 logic documented in Section 10.4 of [OSPFV2].
如[OSPFV2]第10.1、10.2和10.3节所述，与IPv4相比，邻居状态、事件和邻居状态机保持不变。与[OSPFV2]第10.4节中记录的IPv4逻辑相比，关于形成哪种邻接的决定也保持不变。
OSPF for IPv6 runs directly over IPv6's network layer. As such, it is encapsulated in one or more IPv6 headers with the Next Header field of the immediately encapsulating IPv6 header set to the value 89.
用于IPv6的OSPF直接在IPv6的网络层上运行。因此，它被封装在一个或多个IPv6报头中，立即封装IPv6报头的下一个报头字段设置为值89。
As for OSPF for IPv4, OSPF for IPv6 OSPF routing protocol packets are sent along adjacencies only (with the exception of Hello packets, which are used to discover the adjacencies). OSPF packet types and functions are the same in both IPv4 and IPv6, encoded by the Type field of the standard OSPF packet header.
对于用于IPv4的OSPF，用于IPv6的OSPF路由协议数据包仅沿邻接发送（用于发现邻接的Hello数据包除外）。在IPv4和IPv6中，OSPF数据包类型和功能相同，由标准OSPF数据包头的类型字段编码。
When an IPv6 router sends an OSPF routing protocol packet, it fills in the fields of the standard OSPF for IPv6 packet header (see Appendix A.3.1) as follows:
当IPv6路由器发送OSPF路由协议数据包时，它会按如下方式填写IPv6数据包头的标准OSPF字段（见附录A.3.1）：
Version # Set to 3, the version number of the protocol as documented in this specification.
版本#设置为3，即本规范中记录的协议版本号。
Type The type of OSPF packet, such as Link State Update or Hello packet.
键入OSPF数据包的类型，例如链路状态更新或Hello数据包。
Packet length The length of the entire OSPF packet in bytes, including the standard OSPF packet header.
数据包长度整个OSPF数据包的长度（字节），包括标准OSPF数据包头。
Router ID The identity of the router itself (who is originating the packet).
路由器ID路由器本身的身份（发起数据包的人）。
Area ID The OSPF area for the interface on which the packet is being sent.
Area ID发送数据包的接口的OSPF区域。
Instance ID The OSPF Instance ID associated with the interface out of which the packet is being sent.
实例ID与发送数据包的接口相关联的OSPF实例ID。
Checksum The standard IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]) covering the entire OSPF packet and prepended IPv6 pseudo-header (see Appendix A.3.1).
校验和：标准IPv6上层校验和（如[IPv6]第8.1节所述），涵盖整个OSPF数据包和前置IPv6伪报头（见附录A.3.1）。
Selection of OSPF routing protocol packets' IPv6 source and destination addresses is performed identically to the IPv4 logic in Section 8.1 of [OSPFV2]. The IPv6 destination address is chosen from among the addresses AllSPFRouters, AllDRouters, and the Neighbor IP address associated with the other end of the adjacency (which in IPv6, for all links except virtual links, is an IPv6 link-local address).
OSPF路由协议包的IPv6源地址和目标地址的选择与[OSPFV2]第8.1节中的IPv4逻辑相同。IPv6目标地址从地址AllSPFRouters、AllDRouters和与邻接另一端关联的邻居IP地址（在IPv6中，对于除虚拟链路以外的所有链路，该地址是IPv6链路本地地址）中选择。
The sending of Link State Request packets and Link State Acknowledgment packets remains unchanged from the IPv4 procedures documented in Sections 10.9 and 13.5 of [OSPFV2] respectively. Sending Hello packets is documented in Section 4.2.1.1, and the sending of Database Description packets in Section 4.2.1.2. The sending of Link State Update packets is documented in Section 4.5.2.
链路状态请求数据包和链路状态确认数据包的发送与[OSPFV2]第10.9节和第13.5节中分别记录的IPv4程序保持不变。发送Hello数据包见第4.2.1.1节，发送数据库描述数据包见第4.2.1.2节。链路状态更新数据包的发送记录在第4.5.2节中。
IPv6 changes the way OSPF Hello packets are sent in the following ways (compare to Section 9.5 of [OSPFV2]):
IPv6通过以下方式改变了OSPF Hello数据包的发送方式（与[OSPFV2]第9.5节相比）：
o Before the Hello packet is sent on an interface, the interface's Interface ID MUST be copied into the Hello packet.
o 在接口上发送Hello数据包之前，必须将接口的接口ID复制到Hello数据包中。
o The Hello packet no longer contains an IP network mask since OSPF for IPv6 runs per-link instead of per-subnet.
o Hello数据包不再包含IP网络掩码，因为IPv6的OSPF是按链路而不是按子网运行的。
o The choice of Designated Router and Backup Designated Router is now indicated within Hellos by their Router IDs instead of by their IP interface addresses. Advertising the Designated Router
o 指定路由器和备份指定路由器的选择现在由其路由器ID而不是IP接口地址在HELOS中指示。为指定路由器做广告
(or Backup Designated Router) as 0.0.0.0 indicates that the Designated Router (or Backup Designated Router) has not yet been chosen.
（或备份指定路由器）为0.0.0.0表示尚未选择指定路由器（或备份指定路由器）。
o The Options field within Hello packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Hello packets are as follows. The E-bit is set if and only if the interface attaches to a regular area, i.e., not a stub or NSSA area. Similarly, the N-bit is set if and only if the interface attaches to an NSSA area (see [NSSA]). Finally, the DC-bit is set if and only if the router wishes to suppress the sending of future Hellos over the interface (see [DEMAND]). Unrecognized bits in the Hello packet's Options field should be cleared.
o Hello数据包中的选项字段已经移动，在这个过程中变得越来越大。更多的选项位现在是可能的。在Hello数据包中必须正确设置的内容如下。当且仅当接口连接到常规区域，即不是存根或NSSA区域时，才设置E位。类似地，当且仅当接口连接到NSSA区域时才设置N位（请参见[NSSA]）。最后，当且仅当路由器希望抑制通过接口发送未来Hello时，才设置DC位（参见[DEMAND]）。应清除Hello数据包选项字段中无法识别的位。
Sending Hello packets on NBMA networks proceeds for IPv6 in exactly the same way as for IPv4, as documented in Section 9.5.1 of [OSPFV2].
如[OSPFV2]第9.5.1节所述，在NBMA网络上发送Hello数据包的方式与IPv4完全相同。
The sending of Database Description packets differs from Section 10.8 of [OSPFV2] in the following ways:
数据库描述数据包的发送与[OSPFV2]第10.8节的不同之处如下：
o The Options field within Database Description packets has moved around, getting larger in the process. More Options bits are now possible. Those that MUST be set correctly in Database Description packets are as follows. The DC-bit is set if and only if the router wishes to suppress the sending of Hellos over the interface (see [DEMAND]). Unrecognized bits in the Database Description packet's Options field should be cleared.
o 数据库描述数据包中的选项字段已经移动，在这个过程中变得越来越大。更多的选项位现在是可能的。必须在数据库描述数据包中正确设置的内容如下。当且仅当路由器希望抑制通过接口发送Hellos时，才设置DC位（请参见[DEMAND]）。应清除数据库描述数据包选项字段中无法识别的位。
Whenever a router receives an OSPF protocol packet, it is marked with the interface on which it was received. For routers that have virtual links configured, it may not be immediately obvious with which interface to associate the packet. For example, consider the Router RT11 depicted in Figure 6 of [OSPFV2]. If RT11 receives an OSPF protocol packet on its interface to Network N8, it may want to associate the packet with the interface to Area 2, or with the virtual link to Router RT10 (which is part of the backbone). In the following, we assume that the packet is initially associated with the non-virtual link.
每当路由器接收到OSPF协议包时，它都会用接收它的接口进行标记。对于配置了虚拟链路的路由器，要将数据包与哪个接口相关联可能并不明显。例如，考虑在[OSPFv2]的图6中描绘的路由器RT11。如果RT11在其与网络N8的接口上接收到OSPF协议分组，则它可能希望将该分组与到区域2的接口相关联，或者与到路由器RT10（其是主干网的一部分）的虚拟链路相关联。在下文中，我们假设数据包最初与非虚拟链路相关联。
In order for the packet to be passed to OSPF for processing, the following tests must be performed on the encapsulating IPv6 headers:
为了将数据包传递给OSPF进行处理，必须对封装的IPv6报头执行以下测试：
o The packet's IP destination address MUST be one of the IPv6 unicast addresses associated with the receiving interface (this includes link-local addresses), one of the IPv6 multicast addresses AllSPFRouters or AllDRouters, or an IPv6 global address (for virtual links).
o 数据包的IP目标地址必须是与接收接口相关联的IPv6单播地址之一（包括链路本地地址）、IPv6多播地址AllsFrouters或AllDrooter之一或IPv6全局地址（用于虚拟链路）。
o The Next Header field of the immediately encapsulating IPv6 header MUST specify the OSPF protocol (89).
o 立即封装IPv6报头的下一个报头字段必须指定OSPF协议（89）。
o Any encapsulating IP Authentication Headers (see [IPAUTH]) and the IP Encapsulating Security Payloads (see [IPESP]) MUST be processed and/or verified to ensure integrity and authentication/ confidentiality of OSPF routing exchanges. This is described in [OSPFV3-AUTH].
o 必须处理和/或验证任何封装IP身份验证头（请参见[IPAUTH]）和IP封装安全有效载荷（请参见[IPESP]），以确保OSPF路由交换的完整性和身份验证/机密性。这在[OSPFV3-AUTH]中有描述。
After processing the encapsulating IPv6 headers, the OSPF packet header is processed. The fields specified in the header must match those configured for the receiving OSPFv3 interface. If they do not, the packet SHOULD be discarded:
在处理封装的IPv6报头之后，将处理OSPF数据包报头。标头中指定的字段必须与为接收OSPFv3接口配置的字段匹配。如果没有，则应丢弃数据包：
o The version number field MUST specify protocol version 3.
o 版本号字段必须指定协议版本3。
o The IPv6 Upper-Layer checksum (as described in Section 8.1 of [IPV6]), covering the entire OSPF packet and prepended IPv6 pseudo-header, must be verified (see Appendix A.3.1).
o 必须验证覆盖整个OSPF数据包和前置IPv6伪报头的IPv6上层校验和（如[IPv6]第8.1节所述）（见附录A.3.1）。
o The Area ID and Instance ID found in the OSPF header must be verified. If both of the following cases fail, the packet should be discarded. The Area ID and Instance ID specified in the header must either:
o 必须验证在OSPF标头中找到的区域ID和实例ID。如果以下两种情况均失败，则应丢弃数据包。标头中指定的区域ID和实例ID必须：
1. Match one of the Area ID(s) and Interface Instance ID(s) for the receiving link. Unlike IPv4, the IPv6 source address is not restricted to lie within the same IPv6 subnet as the receiving link. IPv6 OSPF runs per-link instead of per-IP-subnet.
1. 匹配接收链路的区域ID和接口实例ID之一。与IPv4不同，IPv6源地址不限于与接收链路位于同一IPv6子网内。IPv6 OSPF按链路而不是按IP子网运行。
2. Match the backbone area and other criteria for a configured virtual link. The receiving router must be an ABR (Area Border Router) and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. Additionally, the receiving link must have an OSPFv3 interface that attaches to the virtual link's configured transit area and the Instance ID must match the virtual link's Instance ID. If all of these checks succeed, the packet is accepted and is associated with the virtual link (and the backbone area).
2. Match the backbone area and other criteria for a configured virtual link. The receiving router must be an ABR (Area Border Router) and the Router ID specified in the packet (the source router) must be the other end of a configured virtual link. Additionally, the receiving link must have an OSPFv3 interface that attaches to the virtual link's configured transit area and the Instance ID must match the virtual link's Instance ID. If all of these checks succeed, the packet is accepted and is associated with the virtual link (and the backbone area).translate error, please retry
o Locally originated packets SHOULD NOT be processed by OSPF except for support of multiple interfaces attached to the same link as described in Section 4.9. Locally originated packets have a source address equal to one of the router's local addresses.
o 本地发起的数据包不应由OSPF处理，除非支持连接到同一链路的多个接口，如第4.9节所述。来自本地的数据包的源地址等于路由器的本地地址之一。
o Packets whose IPv6 destination is AllDRouters should only be accepted if the state of the receiving OSPFv3 interface is DR or Backup (see Section 9.1 [OSPFV2]).
o 只有在接收OSPFv3接口的状态为DR或Backup时（参见第9.1节[OSPFV2]），才应接受IPv6目的地为AllDrooters的数据包。
After header processing, the packet is further processed according to its OSPF packet type. OSPF packet types and functions are the same for both IPv4 and IPv6.
在报头处理之后，根据其OSPF分组类型进一步处理分组。IPv4和IPv6的OSPF数据包类型和功能相同。
If the packet type is Hello, it should then be further processed by the Hello packet processing as described in Section 4.2.2.1. All other packet types are sent/received only on adjacencies. This means that the packet must have been sent by one of the router's active neighbors. The neighbor is identified by the Router ID appearing in the received packet's OSPF header. Packets not matching any active neighbor are discarded.
如果数据包类型为Hello，则应按照第4.2.2.1节所述，通过Hello数据包处理进一步处理。所有其他数据包类型仅在相邻位置发送/接收。这意味着数据包必须由路由器的一个活动邻居发送。邻居由出现在接收数据包的OSPF报头中的路由器ID标识。不匹配任何活动邻居的数据包将被丢弃。
The receive processing of Database Description packets, Link State Request packets, and Link State Acknowledgment packets is almost identical to the IPv4 procedures documented in Sections 10.6, 10.7, and 13.7 of [OSPFV2] respectively with the exceptions noted below.
数据库描述数据包、链路状态请求数据包和链路状态确认数据包的接收处理与[OSPFV2]第10.6节、第10.7节和第13.7节中分别记录的IPv4过程几乎相同，但下文指出的例外情况除外。
o LSAs with unknown LS types in Database Description packets that have an acceptable flooding scope are processed the same as LSAs with known LS types. In OSPFv2 [OSPFV2], these would result in the adjacency being brought down with a SequenceMismatch event.
o 具有可接受泛洪作用域的数据库描述数据包中具有未知LS类型的LSA的处理与具有已知LS类型的LSA的处理相同。在OSPFv2[OSPFv2]中，这些将导致相邻关系因序列不匹配事件而降低。
The receiving of Hello packets is documented in Section 4.2.2.1 and the receiving of Link State Update packets is documented in Section 4.5.1.
Hello数据包的接收记录在第4.2.2.1节中，链路状态更新数据包的接收记录在第4.5.1节中。
The receive processing of Hello packets differs from Section 10.5 of [OSPFV2] in the following ways:
Hello数据包的接收处理与[OSPFV2]第10.5节的不同之处在于：
o On all link types (e.g., broadcast, NBMA, point-to-point, etc.), neighbors are identified solely by their OSPF Router ID. For all link types except virtual links, the Neighbor IP address is set to the IPv6 source address in the IPv6 header of the received OSPF Hello packet.
o 在所有链路类型（如广播、NBMA、点对点等）上，邻居仅通过其OSPF路由器ID进行标识。对于除虚拟链路以外的所有链路类型，邻居IP地址设置为接收到的OSPF Hello数据包的IPv6报头中的IPv6源地址。
o There is no longer a Network Mask field in the Hello packet.
o Hello数据包中不再有网络掩码字段。
o The neighbor's choice of Designated Router and Backup Designated Router is now encoded as an OSPF Router ID instead of an IP interface address.
o 邻居选择的指定路由器和备份指定路由器现在编码为OSPF路由器ID，而不是IP接口地址。
The routing table used by OSPF for IPv4 is defined in Section 11 of [OSPFV2]. For IPv6, there are analogous routing table entries: there are routing table entries for IPv6 address prefixes and also for AS boundary routers. The latter routing table entries are only used to hold intermediate results during the routing table build process (see Section 4.8).
OSPF用于IPv4的路由表在[OSPFV2]的第11节中定义。对于IPv6，有类似的路由表条目：有IPv6地址前缀的路由表条目，也有AS边界路由器的路由表条目。后一个路由表条目仅用于在路由表构建过程中保存中间结果（参见第4.8节）。
Also, to hold the intermediate results during the shortest-path calculation for each area, there is a separate routing table for each area holding the following entries:
此外，为了在每个区域的最短路径计算期间保存中间结果，每个区域都有一个单独的路由表，其中包含以下条目：
o An entry for each router in the area. Routers are identified by their OSPF Router ID. These routing table entries hold the set of shortest paths through a given area to a given router, which in turn allows calculation of paths to the IPv6 prefixes advertised by that router in intra-area-prefix-LSAs. If the router is also an area border router, these entries are also used to calculate paths for inter-area address prefixes. If in addition the router is the other endpoint of a virtual link, the routing table entry describes the cost and viability of the virtual link.
o 区域中每个路由器的条目。路由器由其OSPF路由器ID标识。这些路由表条目包含通过给定区域到给定路由器的最短路径集，从而允许计算到该路由器在区域内前缀LSA中公布的IPv6前缀的路径。如果路由器也是区域边界路由器，则这些条目也用于计算区域间地址前缀的路径。此外，如果路由器是虚拟链路的另一个端点，则路由表条目描述虚拟链路的成本和生存能力。
o An entry for each transit link in the area. Transit links have associated network-LSAs. Both the transit link and the network-LSA are identified by a combination of the Designated Router's Interface ID on the link and the Designated Router's OSPF Router ID. These routing table entries allow later calculation of paths to IP prefixes advertised for the transit link in intra-area-prefix-LSAs.
o 该区域中每个公交线路的入口。传输链路具有关联的网络LSA。传输链路和网络LSA都是通过链路上指定路由器的接口ID和指定路由器的OSPF路由器ID的组合来标识的。这些路由表条目允许以后计算区域内前缀LSA中为传输链路播发的IP前缀的路径。
The fields in the IPv4 OSPF routing table (see Section 11 of [OSPFV2]) remain valid for IPv6: optional capabilities (routers only), path type, cost, type 2 cost, link state origin, and for each of the equal cost paths to the destination, the next-hop and advertising routers.
IPv4 OSPF路由表中的字段（请参见[OSPFV2]第11节）对于IPv6仍然有效：可选功能（仅限路由器）、路径类型、成本、类型2成本、链路状态来源，以及对于到目的地、下一跳和广告路由器的每个等成本路径。
For IPv6, the link-state origin field in the routing table entry is the router-LSA or network-LSA that has directly or indirectly produced the routing table entry. For example, if the routing table entry describes a route to an IPv6 prefix, the link state origin is the router-LSA or network-LSA that is listed in the body of the intra-area-prefix-LSA that has produced the route (see Appendix A.4.10).
对于IPv6，路由表条目中的链路状态原点字段是直接或间接生成路由表条目的路由器LSA或网络LSA。例如，如果路由表条目描述了到IPv6前缀的路由，则链路状态原点是已生成路由的区域内前缀LSA正文中列出的路由器LSA或网络LSA（见附录a.4.10）。
Routing table lookup (i.e., determining the best matching routing table entry during IP forwarding) is the same for IPv6 as for IPv4.
IPv6的路由表查找（即，在IP转发期间确定最佳匹配的路由表条目）与IPv4相同。
For IPv6, the OSPF LSA header has changed slightly, with the LS type field expanding and the Options field being moved into the body of appropriate LSAs. Also, the formats of some LSAs have changed somewhat (namely, router-LSAs, network-LSAs, AS-external-LSAs, and NSSA-LSAs), while the names of other LSAs have been changed (type 3 and 4 summary-LSAs are now inter-area-prefix-LSAs and inter-area-router-LSAs respectively) and additional LSAs have been added (link-LSAs and intra-area-prefix-LSAs). Type of Service (TOS) has been removed from the OSPFv2 specification [OSPFV2] and is not encoded within OSPF for IPv6's LSAs.
对于IPv6，OSPF LSA头稍有更改，LS type字段扩展，Options字段移动到相应LSA的主体中。此外，一些LSA的格式有所改变（即路由器LSA、网络LSA、AS外部LSA和NSSA LSA），而其他LSA的名称也有所改变（类型3和类型4汇总LSA现在分别为区域间前缀LSA和区域间路由器LSA），并添加了其他LSA（链路LSA和区域内前缀LSA）。服务类型（TOS）已从OSPFv2规范[OSPFv2]中删除，并且未在用于IPv6 LSA的OSPF中编码。
These changes will be described in detail in the following subsections.
以下小节将详细描述这些更改。
In both IPv4 and IPv6, all OSPF LSAs begin with a standard 20-byte LSA header. However, the contents of this 20-byte header have changed in IPv6. The LS age, Advertising Router, LS Sequence Number, LS checksum, and length fields within the LSA header remain unchanged, as documented in Sections 12.1.1, 12.1.5, 12.1.6, 12.1.7, and A.4.1 of [OSPFV2], respectively. However, the following fields have changed for IPv6:
在IPv4和IPv6中，所有OSPF LSA都以标准的20字节LSA头开始。但是，在IPv6中，此20字节标头的内容已更改。LSA报头中的LS age、广告路由器、LS序列号、LS校验和和长度字段保持不变，如[OSPFV2]第12.1.1、12.1.5、12.1.6、12.1.7和A.4.1节所述。但是，IPv6的以下字段已更改：
Options The Options field has been removed from the standard 20-byte LSA header and moved into the body of router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs. The size of the Options field has increased from 8 to 24 bits, and some of the bit definitions have changed (see Appendix A.2). Additionally, a separate PrefixOptions field, 8 bits in length, is attached to each prefix advertised within the body of an LSA.
选项选项字段已从标准的20字节LSA标头中删除，并移动到路由器LSA、网络LSA、区域间路由器LSA和链路LSA的主体中。选项字段的大小已从8位增加到24位，一些位定义已更改（见附录A.2）。此外，在LSA主体内的每个播发前缀上附加了一个长度为8位的单独PrefixOptions字段。
LS type The size of the LS type field has increased from 8 to 16 bits, with high-order bit encoding the handling of unknown types and the next two bits encoding flooding scope. See Appendix A.4.2.1 for the current coding of the LS type field.
LS type LS type字段的大小已从8位增加到16位，高阶位编码用于处理未知类型，接下来的两位编码用于泛洪范围。LS类型字段的当前编码见附录A.4.2.1。
Link State ID The Link State ID remains at 32 bits in length. However, except for network-LSAs and link-LSAs, the Link State ID has shed any addressing semantics. For example, an IPv6 router originating multiple AS-external-LSAs could start by assigning the first a Link State ID of 0.0.0.1, the second a Link State ID of 0.0.0.2, and so on. Instead of the IPv4 behavior of encoding the network number within the AS-external-LSA's Link State ID, the IPv6 Link State ID simply serves as a way to differentiate multiple LSAs originated by the same router. For network-LSAs, the Link State ID is set to the Designated Router's Interface ID on the link. When a router originates a link-LSA for a given link, its Link State ID is set equal to the router's Interface ID on the link.
链路状态ID链路状态ID的长度保持在32位。然而，除了网络LSA和链路LSA之外，链路状态ID已经摆脱了任何寻址语义。例如，发起多个外部LSA的IPv6路由器可以首先为第一个分配链路状态ID 0.0.0.1，为第二个分配链路状态ID 0.0.0.2，依此类推。IPv6链路状态ID不是将网络号编码为外部LSA的链路状态ID的IPv4行为，而是用来区分由同一路由器发起的多个LSA。对于网络LSA，链路状态ID设置为链路上指定路由器的接口ID。当路由器为给定链路发起链路LSA时，其链路状态ID设置为等于路由器在链路上的接口ID。
In IPv6, as in IPv4, individual LSAs are identified by a combination of their LS type, Link State ID, and Advertising Router fields. Given two instances of an LSA, the most recent instance is determined by examining the LSAs' LS sequence number, using LS checksum and LS age as tiebreakers (see Section 13.1 of [OSPFV2]).
在IPv6中，与在IPv4中一样，单个LSA通过其LS类型、链路状态ID和播发路由器字段的组合来标识。给定一个LSA的两个实例，通过检查LSA的LS序列号，使用LS校验和和和LS年龄作为分接器来确定最近的实例（见[OSPFV2]第13.1节）。
In IPv6, the link-state database is split across three separate data structures. LSAs with AS flooding scope are contained within the top-level OSPF data structure (see Section 4.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes the AS-external-LSAs. LSAs with area flooding scope are contained within the appropriate area structure (see Section 4.1.1) as long as either their LS type is known or their U-bit is 1 (flood even when unrecognized); this includes router-LSAs, network-LSAs, inter-area-prefix-LSAs, inter-area-router-LSAs, NSSA-LSAs, and intra-area-prefix-LSAs. LSAs with an unknown LS type, the U-bit set to 0, and/or link-local flooding scope are contained within the appropriate interface structure (see Section 4.1.2); this includes link-LSAs.
在IPv6中，链路状态数据库分为三个独立的数据结构。具有AS泛洪作用域的LSA包含在顶级OSPF数据结构中（见第4.1节），只要其LS类型已知或其U位为1（即使无法识别也会泛洪）；这包括AS外部LSA。具有区域泛洪范围的LSA包含在适当的区域结构内（见第4.1.1节），只要其LS类型已知或其U型钻头为1（即使未识别也会泛洪）；这包括路由器LSA、网络LSA、区域间前缀LSA、区域间路由器LSA、NSSA LSA和区域内前缀LSA。具有未知LS类型、U位设置为0和/或链路局部泛洪范围的LSA包含在适当的接口结构中（见第4.1.2节）；这包括链路LSA。
To look up or install an LSA in the database, you first examine the LS type and the LSA's context (i.e., the area or link to which the LSA belongs). This information allows you to find the correct database of LSAs where you then search based on the LSA's type, Link State ID, and Advertising Router.
要在数据库中查找或安装LSA，首先检查LS类型和LSA的上下文（即LSA所属的区域或链接）。此信息允许您找到正确的LSA数据库，然后根据LSA的类型、链接状态ID和广告路由器进行搜索。
The process of reoriginating an LSA in IPv6 is the same as in IPv4: the LSA's LS sequence number is incremented, its LS age is set to 0, its LS checksum is calculated, and the LSA is added to the link state database and flooded on the appropriate interfaces.
在IPv6中对LSA重新排序的过程与在IPv4中相同：LSA的LS序列号递增，其LS age设置为0，计算其LS校验和，并将LSA添加到链路状态数据库，并在适当的接口上进行泛洪。
The list of events causing LSAs to be reoriginated for IPv4 is given in Section 12.4 of [OSPFV2]. The following events and/or actions are added for IPv6:
[OSPFV2]第12.4节给出了导致LSA为IPv4重新排序的事件列表。为IPv6添加了以下事件和/或操作：
o The state or interface ID of one of the router's interfaces changes. The router may need to (re)originate or flush its link-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs. If the router is the Designated Router, the router may also need to (re)originate and/or flush the network-LSA corresponding to the interface.
o 路由器某个接口的状态或接口ID发生更改。路由器可能需要（重新）发起或刷新其链路LSA和一个或多个路由器LSA和/或区域内前缀LSA。如果路由器是指定的路由器，则路由器可能还需要（重新）发起和/或刷新与接口对应的网络LSA。
o The identity of a link's Designated Router changes. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs.
o 链路的指定路由器的标识将更改。路由器可能需要（重新）发起或刷新链路的网络LSA和一个或多个路由器LSA和/或区域内前缀LSA。
o A neighbor transitions to/from "Full" state. The router may need to (re)originate or flush the link's network-LSA and one or more router-LSAs and/or intra-area-prefix-LSAs.
o 邻居转换到/从“完全”状态。路由器可能需要（重新）发起或刷新链路的网络LSA和一个或多个路由器LSA和/或区域内前缀LSA。
o The Interface ID of a neighbor changes. This may cause a new instance of a router-LSA to be originated for the associated area.
o 邻居的接口ID更改。这可能导致为相关区域发起路由器LSA的新实例。
o A new prefix is added to an attached link, or a prefix is deleted (both through configuration). This causes the router to reoriginate its link-LSA for the link or, if it is the only router attached to the link, causes the router to reoriginate an intra-area-prefix-LSA.
o 将向附加的链接添加新前缀，或删除前缀（通过配置）。这会导致路由器为链路重新确定其链路LSA的顺序，或者，如果它是连接到链路的唯一路由器，则会导致路由器重新确定区域内前缀LSA的顺序。
o A new link-LSA is received, causing the link's collection of prefixes to change. If the router is the Designated Router for the link, it originates a new intra-area-prefix-LSA.
o 接收到新的链接LSA，导致链接的前缀集合发生更改。如果路由器是链路的指定路由器，它将发起一个新的区域内前缀LSA。
o A new link-LSA is received, causing the logical OR of LSA options advertised by adjacent routers on the link to change. If the router is the Designated Router for the link, it originates a new network-LSA.
o 接收到新的链路LSA，导致链路上相邻路由器公布的LSA选项的逻辑OR发生变化。如果路由器是链路的指定路由器，它将发起一个新的网络LSA。
Detailed construction of the seven required IPv6 LSA types is supplied by the following subsections. In order to display example LSAs, the network map in Figure 15 of [OSPFV2] has been reworked to show IPv6 addressing, resulting in Figure 1. The OSPF cost of each
以下小节提供了七种所需IPv6 LSA类型的详细构造。为了显示示例LSA，[OSPFV2]图15中的网络图已被修改，以显示IPv6寻址，结果如图1所示。每一个项目的OSPF成本
interface is displayed in Figure 1. The assignment of IPv6 prefixes to network links is shown in Table 1. A single area address range has been configured for Area 1, so that outside of Area 1 all of its prefixes are covered by a single route to 2001:0db8:c001::/48. The OSPF interface IDs and the link-local addresses for the router interfaces in Figure 1 are given in Table 2.
界面如图1所示。将IPv6前缀分配给网络链路如表1所示。已为区域1配置了一个单区域地址范围，因此在区域1之外，其所有前缀都由一条到2001:0db8:c001:：/48的路由覆盖。表2中给出了图1中路由器接口的OSPF接口ID和链路本地地址。
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
..........................................
. Area 1.
. + .
. | .
. | 3+---+1 .
. N1 |--|RT1|-----+ .
. | +---+ \ .
. | \ ______ .
. + \/ \ 1+---+
. * N3 *------|RT4|------
. + /\_______/ +---+
. | / | .
. | 3+---+1 / | .
. N2 |--|RT2|-----+ 1| .
. | +---+ +---+ .
. | |RT3|----------------
. + +---+ .
. |2 .
. | .
. +------------+ .
. N4 .
..........................................
Figure 1: Area 1 with IP Addresses Shown
图1：显示IP地址的区域1
Network IPv6 prefix
-----------------------------------
N1 2001:0db8:c001:0200::/56
N2 2001:0db8:c001:0300::/56
N3 2001:0db8:c001:0100::/56
N4 2001:0db8:c001:0400::/56
Network IPv6 prefix
-----------------------------------
N1 2001:0db8:c001:0200::/56
N2 2001:0db8:c001:0300::/56
N3 2001:0db8:c001:0100::/56
N4 2001:0db8:c001:0400::/56
Table 1: IPv6 Link Prefixes for Sample Network
表1：示例网络的IPv6链路前缀
Router Interface Interface ID link-local address
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 to N3 1 fe80:0001::RT4
Router Interface Interface ID link-local address
-------------------------------------------------------
RT1 to N1 1 fe80:0001::RT1
to N3 2 fe80:0002::RT1
RT2 to N2 1 fe80:0001::RT2
to N3 2 fe80:0002::RT2
RT3 to N3 1 fe80:0001::RT3
to N4 2 fe80:0002::RT3
RT4 to N3 1 fe80:0001::RT4
Table 2: OSPF Interface IDs and Link-Local Addresses
表2:OSPF接口ID和链路本地地址
Figure 1
图1
The Options field in LSAs should be coded as follows. The V6-bit should be set unless the router will not participate in transit IPv6 routing. The E-bit should be clear if and only if the attached area is an OSPF stub or OSPF NSSA area. The E-bit should always be set in AS scoped LSAs. The N-bit should be set if and only if the attached area is an OSPF NSSA area. The R-bit should be set unless the router will not participate in any transit routing. The DC-bit should be set if and only if the router can correctly process the DoNotAge bit when it appears in the LS age field of LSAs (see [DEMAND]). All unrecognized bits in the Options field should be cleared.
LSA中的选项字段应编码如下。除非路由器不参与传输IPv6路由，否则应设置V6位。当且仅当连接区域是OSPF存根或OSPF NSSA区域时，E位应为清除。E位应始终设置为作用域LSA。当且仅当连接区域是OSPF NSSA区域时，才应设置N位。除非路由器不参与任何传输路由，否则应设置R位。当且仅当路由器能够正确处理出现在LSA的LS age字段中的DoNotAge位时，才应设置DC位（请参见[DEMAND]）。应清除选项字段中所有无法识别的位。
The V6-bit and R-bit are only examined in Router-LSAs during the SPF computation. In other LSA types containing options, they are set for informational purposes only.
在SPF计算期间，仅在路由器LSA中检查V6位和R位。在包含选项的其他LSA类型中，设置这些选项仅用于提供信息。
The LS type of a router-LSA is set to the value 0x2001. Router-LSAs have area flooding scope. A router MAY originate one or more router-LSAs for a given area. Each router-LSA contains an integral number of interface descriptions. Taken together, the collection of router-LSAs originated by the router for an area describes the collected states of all the router's interfaces attached to the area. When multiple router-LSAs are used, they are distinguished by their Link State ID fields.
路由器LSA的LS类型设置为值0x2001。路由器LSA具有区域泛洪范围。路由器可以为给定区域发起一个或多个路由器lsa。每个路由器LSA包含整数个接口描述。总之，由路由器为某个区域发起的路由器LSA集合描述了连接到该区域的所有路由器接口的集合状态。当使用多个路由器LSA时，它们通过其链路状态ID字段进行区分。
To the left of the Options field, the router capability bits V, E, and B should be set according to Section 12.4.1 of [OSPFV2].
在选项字段左侧，应根据[OSPFV2]第12.4.1节设置路由器能力位V、E和B。
Each of the router's interfaces to the area is then described by appending "link descriptions" to the router-LSA. Each link description is 16 bytes long, consisting of five fields: (link) Type,
然后，通过向路由器LSA添加“链路描述”来描述路由器与该区域的每个接口。每个链接描述长度为16字节，由五个字段组成：（link）Type，
Metric, Interface ID, Neighbor Interface ID, and Neighbor Router ID (see Appendix A.4.3). Interfaces in the state "Down" or "Loopback" are not described (although looped back interfaces can contribute prefixes to intra-area-prefix-LSAs), nor are interfaces without any full adjacencies described (except in the case of multiple Standby Interfaces as described in Section 4.9). All other interfaces to the area add zero, one, or more link descriptions. The number and content of these depend on the interface type. Within each link description, the Metric field is always set to the interface's output cost, and the Interface ID field is set to the interface's OSPF Interface ID.
度量、接口ID、邻居接口ID和邻居路由器ID（见附录A.4.3）。不描述处于“关闭”或“环回”状态的接口（尽管环回接口可以为区域内前缀LSA提供前缀），也不描述没有任何完全邻接的接口（第4.9节所述的多个备用接口除外）。该区域的所有其他接口添加零、一或多个链接描述。它们的数量和内容取决于接口类型。在每个链路描述中，度量字段始终设置为接口的输出成本，接口ID字段设置为接口的OSPF接口ID。
Point-to-point interfaces If the neighboring router is fully adjacent, add a Type 1 link description (point-to-point). The Neighbor Interface ID field is set to the Interface ID advertised by the neighbor in its Hello packets, and the Neighbor Router ID field is set to the neighbor's Router ID.
点对点接口如果相邻路由器完全相邻，则添加类型1链路描述（点对点）。邻居接口ID字段设置为邻居在其Hello数据包中公布的接口ID，邻居路由器ID字段设置为邻居的路由器ID。
Broadcast and NBMA interfaces If the router is fully adjacent to the link's Designated Router or if the router itself is the Designated Router and is fully adjacent to at least one other router, add a single Type 2 link description (transit network). The Neighbor Interface ID field is set to the Interface ID advertised by the Designated Router in its Hello packets, and the Neighbor Router ID field is set to the Designated Router's Router ID.
广播和NBMA接口如果路由器与链路的指定路由器完全相邻，或者如果路由器本身是指定的路由器并且与至少一个其他路由器完全相邻，则添加单个类型2链路描述（传输网络）。邻居接口ID字段设置为指定路由器在其Hello数据包中公布的接口ID，邻居路由器ID字段设置为指定路由器的路由器ID。
Virtual links If the neighboring router is fully adjacent, add a Type 4 link description (virtual). The Neighbor Interface ID field is set to the Interface ID advertised by the neighbor in its Hello packets, and the Neighbor Router ID field is set to the neighbor's Router ID. Note that the output cost of a virtual link is calculated during the routing table calculation (see Section 4.7).
虚拟链路如果相邻路由器完全相邻，请添加类型4链路描述（虚拟）。邻居接口ID字段设置为邻居在其Hello数据包中公布的接口ID，邻居路由器ID字段设置为邻居的路由器ID。请注意，虚拟链路的输出成本是在路由表计算期间计算的（参见第4.7节）。
Point-to-Multipoint interfaces For each fully adjacent neighbor associated with the interface, add a separate Type 1 link description (point-to-point) with the Neighbor Interface ID field set to the Interface ID advertised by the neighbor in its Hello packets and the Neighbor Router ID field set to the neighbor's Router ID.
点对多点接口对于与接口关联的每个完全相邻的邻居，添加一个单独的类型1链路描述（点对点），其中邻居接口ID字段设置为邻居在其Hello数据包中公布的接口ID，邻居路由器ID字段设置为邻居的路由器ID。
As an example, consider the router-LSA that router RT3 would originate for Area 1 in Figure 1. Only a single interface must be described, namely, that which connects to the transit network N3. It assumes that RT4 has been elected the Designated Router of Network N3.
作为一个例子，考虑路由器RT3将在图1中为区域1发起的路由器LSA。必须只描述一个接口，即连接到公交网络N3的接口。它假设RT4已被选为网络N3的指定路由器。
; RT3's router-LSA for Area 1
; 区域1的RT3路由器LSA
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.0.2.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.0.2.4 ; RT4's Router ID
LS age = 0 ;newly (re)originated
LS type = 0x2001 ;router-LSA
Link State ID = 0 ;first fragment
Advertising Router = 192.0.2.3 ;RT3's Router ID
bit E = 0 ;not an AS boundary router
bit B = 1 ;area border router
Options = (V6-bit|E-bit|R-bit)
Type = 2 ;connects to N3
Metric = 1 ;cost to N3
Interface ID = 1 ;RT3's Interface ID on N3
Neighbor Interface ID = 1 ;RT4's Interface ID on N3
Neighbor Router ID = 192.0.2.4 ; RT4's Router ID
RT3's router-LSA for Area 1
区域1的RT3路由器LSA
For example, if another router was added to Network N4, RT3 would have to advertise a second link description for its connection to (the now transit) network N4. This could be accomplished by reoriginating the above router-LSA, this time with two link descriptions. Or, a separate router-LSA could be originated with a separate Link State ID (e.g., using a Link State ID of 1) to describe the connection to N4.
例如，如果将另一个路由器添加到网络N4，RT3将不得不公布其与（现在传输的）网络N4的连接的第二个链路描述。这可以通过重新排列上述路由器LSA来实现，这次有两个链路描述。或者，可以使用单独的链路状态ID（例如，使用链路状态ID 1）来发起单独的路由器LSA，以描述到N4的连接。
Host routes for stub networks no longer appear in the router-LSA. Rather, they are included in intra-area-prefix-LSAs.
存根网络的主机路由不再出现在路由器LSA中。相反，它们包含在区域内前缀lsa中。
The LS type of a network-LSA is set to the value 0x2002. Network-LSAs have area flooding scope. A network-LSA is originated for every broadcast or NBMA link with an elected Designated Router that is fully adjacent with at least one other router on the link. The network-LSA is originated by the link's Designated Router and lists all routers on the link with which it is fully adjacent.
网络LSA的LS类型设置为值0x2002。网络LSA具有区域泛洪范围。对于每个广播或NBMA链路，网络LSA由与链路上至少一个其他路由器完全相邻的选定指定路由器发起。网络LSA由链路的指定路由器发起，并列出链路上与其完全相邻的所有路由器。
The procedure for originating network-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.2 of [OSPFV2], with the following exceptions:
IPv6中发起网络LSA的程序与[OSPFV2]第12.4.2节中记录的IPv4程序相同，但以下情况除外：
o An IPv6 network-LSA's Link State ID is set to the Interface ID of the Designated Router on the link.
o IPv6网络LSA的链路状态ID设置为链路上指定路由器的接口ID。
o IPv6 network-LSAs do not contain a Network Mask. All addressing information formerly contained in the IPv4 network-LSA has now been consigned to intra-Area-Prefix-LSAs originated by the link's Designated Router.
o IPv6网络LSA不包含网络掩码。以前包含在IPv4网络LSA中的所有寻址信息现在已委托给由链路的指定路由器发起的区域内前缀LSA。
o The Options field in the network-LSA is set to the logical OR of the Options fields contained within the link's associated link-LSAs corresponding to fully adjacent neighbors. In this way, the network link exhibits a capability when at least one fully adjacent neighbor on the link requests that the capability be advertised.
o 网络LSA中的选项字段设置为链路的关联链路LSA中包含的选项字段的逻辑OR，对应于完全相邻的邻居。这样，当链路上的至少一个完全相邻的邻居请求公布该能力时，网络链路展示该能力。
As an example, assuming that Router RT4 has been elected the Designated Router of Network N3 in Figure 1, the following network-LSA is originated:
例如，假设路由器RT4被选为图1中网络N3的指定路由器，则产生以下网络LSA：
; Network-LSA for Network N3
; 网络N3的网络LSA
LS age = 0 ;newly (re)originated
LS type = 0x2002 ;network-LSA
Link State ID = 1 ;RT4's Interface ID on N3
Advertising Router = 192.0.2.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.0.2.4 ;Router ID
Attached Router = 192.0.2.1 ;Router ID
Attached Router = 192.0.2.2 ;Router ID
Attached Router = 192.0.2.3 ;Router ID
LS age = 0 ;newly (re)originated
LS type = 0x2002 ;network-LSA
Link State ID = 1 ;RT4's Interface ID on N3
Advertising Router = 192.0.2.4 ;RT4's Router ID
Options = (V6-bit|E-bit|R-bit)
Attached Router = 192.0.2.4 ;Router ID
Attached Router = 192.0.2.1 ;Router ID
Attached Router = 192.0.2.2 ;Router ID
Attached Router = 192.0.2.3 ;Router ID
Network-LSA for Network N3
网络N3的网络LSA
The LS type of an inter-area-prefix-LSA is set to the value 0x2003. Inter-area-prefix-LSAs have area flooding scope. In IPv4, inter-area-prefix-LSAs were called type 3 summary-LSAs. Each inter-area-prefix-LSA describes a prefix external to the area, yet internal to the Autonomous System.
区域间前缀LSA的LS类型设置为值0x2003。区域间前缀LSA具有区域泛洪范围。在IPv4中，区域间前缀LSA称为类型3摘要LSA。每个区域间前缀LSA描述区域外部但自治系统内部的前缀。
The procedure for originating inter-area-prefix-LSAs in IPv6 is the same as the IPv4 procedure documented in Sections 12.4.3 and 12.4.3.1 of [OSPFV2], with the following exceptions:
IPv6中发起区域间前缀LSA的程序与[OSPFV2]第12.4.3节和第12.4.3.1节中记录的IPv4程序相同，但以下情况除外：
o The Link State ID of an inter-area-prefix-LSA has lost all of its addressing semantics and simply serves to distinguish multiple inter-area-prefix-LSAs that are originated by the same router.
o 区域间前缀LSA的链路状态ID已丢失其所有寻址语义，仅用于区分由同一路由器发起的多个区域间前缀LSA。
o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
o 前缀由嵌入在LSA正文中的前缀长度、前缀选项和地址前缀字段描述。不再指定网络掩码。
o The NU-bit in the PrefixOptions field should be clear.
o PrefixOptions字段中的NU位应为空。
o Link-local addresses MUST never be advertised in inter-area-prefix-LSAs.
o 决不能在区域间前缀LSA中公布链路本地地址。
As an example, the following shows the inter-area-prefix-LSA that Router RT4 originates into the OSPF backbone area, condensing all of Area 1's prefixes into the single prefix 2001:0db8:c001::/48. The cost is set to 4, which is the maximum cost of all of the individual component prefixes. The prefix is padded out to an even number of 32-bit words, so that it consumes 64 bits of space instead of 48 bits.
例如，以下显示路由器RT4发起到OSPF主干区域的区域间前缀LSA，将区域1的所有前缀压缩为单个前缀2001:0db8:c001:：/48。成本设置为4，这是所有单个组件前缀的最大成本。前缀被填充为偶数的32位字，因此它占用64位空间，而不是48位空间。
; Inter-area-prefix-LSA for Area 1 addresses ; originated by Router RT4 into the backbone
; 区域1地址的区域间前缀LSA；由路由器RT4发起进入主干网
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 2001:0db8:c001 ;padded to 64-bits
LS age = 0 ;newly (re)originated
LS type = 0x2003 ;inter-area-prefix-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Metric = 4 ;maximum to components
PrefixLength = 48
PrefixOptions = 0
Address Prefix = 2001:0db8:c001 ;padded to 64-bits
Inter-area-prefix-LSA for Area 1 addresses originated by Router RT4 into the backbone
由路由器RT4发送到主干网的区域1地址的区域间前缀LSA
The LS type of an inter-area-router-LSA is set to the value 0x2004. Inter-area-router-LSAs have area flooding scope. In IPv4, inter-area-router-LSAs were called type 4 summary-LSAs. Each inter-area-router-LSA describes a path to a destination OSPF router (i.e., an AS Boundary Router (ASBR)) that is external to the area yet internal to the Autonomous System.
区域间路由器LSA的LS类型设置为值0x2004。区域间路由器LSA具有区域泛洪范围。在IPv4中，区域间路由器LSA称为类型4摘要LSA。每个区域间路由器LSA描述到目的地OSPF路由器（即AS边界路由器（ASBR））的路径，该目的地OSPF路由器在该区域外部，但在自治系统内部。
The procedure for originating inter-area-router-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.3 of [OSPFV2], with the following exceptions:
IPv6中发起区域间路由器LSA的程序与[OSPFV2]第12.4.3节中记录的IPv4程序相同，但以下情况除外：
o The Link State ID of an inter-area-router-LSA is no longer the destination router's OSPF Router ID and now simply serves to distinguish multiple inter-area-router-LSAs that are originated by the same router. The destination router's Router ID is now found in the body of the LSA.
o 区域间路由器LSA的链路状态ID不再是目的地路由器的OSPF路由器ID，现在仅用于区分由同一路由器发起的多个区域间路由器LSA。目标路由器的路由器ID现在可以在LSA的主体中找到。
o The Options field in an inter-area-router-LSA should be set equal to the Options field contained in the destination router's own router-LSA. The Options field thus describes the capabilities supported by the destination router.
o 区域间路由器LSA中的选项字段应设置为与目标路由器自身的路由器LSA中包含的选项字段相等。因此，选项字段描述了目标路由器支持的功能。
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Router RT4 would originate into Area 1 the following inter-area-router-LSA for destination router RT7.
作为一个例子，考虑OSPF自治系统在图6中描述的[OSPFv2]。路由器RT4将起源于区域1，目的地路由器RT7的以下区域间路由器LSA。
; inter-area-router-LSA for AS boundary router RT7 ; originated by Router RT4 into Area 1
; AS边界路由器RT7的区域间路由器LSA；由路由器RT4发起进入区域1
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
LS age = 0 ;newly (re)originated
LS type = 0x2004 ;inter-area-router-LSA
Advertising Router = 192.0.2.4 ;RT4's ID
Options = (V6-bit|E-bit|R-bit) ;RT7's capabilities
Metric = 14 ;cost to RT7
Destination Router ID = Router RT7's ID
Inter-area-router-LSA for AS boundary router RT7 originated by Router RT4 into Area 1
AS边界路由器RT7的区域间路由器LSA由路由器RT4发起进入区域1
The LS type of an AS-external-LSA is set to the value 0x4005. AS-external-LSAs have AS flooding scope. Each AS-external-LSA describes a path to a prefix external to the Autonomous System.
AS外部LSA的LS类型设置为值0x4005。外部LSA具有AS泛洪范围。每个AS-external LSA描述到自治系统外部前缀的路径。
The procedure for originating AS-external-LSAs in IPv6 is the same as the IPv4 procedure documented in Section 12.4.4 of [OSPFV2], with the following exceptions:
IPv6中作为外部LSA发起的过程与[OSPFV2]第12.4.4节中记录的IPv4过程相同，但以下情况除外：
o The Link State ID of an AS-external-LSA has lost all of its addressing semantics and simply serves to distinguish multiple AS-external-LSAs that are originated by the same router.
o AS外部LSA的链路状态ID已丢失其所有寻址语义，仅用于区分由同一路由器发起的多个AS外部LSA。
o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
o 前缀由嵌入在LSA正文中的前缀长度、前缀选项和地址前缀字段描述。不再指定网络掩码。
o The NU-bit in the PrefixOptions field should be clear.
o PrefixOptions字段中的NU位应为空。
o Link-local addresses can never be advertised in AS-external-LSAs.
o 链接本地地址永远不能作为外部LSA在中播发。
o The forwarding address is present in the AS-external-LSA if and only if the AS-external-LSA's bit F is set.
o 当且仅当设置了AS外部LSA的位F时，AS外部LSA中存在转发地址。
o The external route tag is present in the AS-external-LSA if and only if the AS-external-LSA's bit T is set.
o 当且仅当AS外部LSA的位T被设置时，外部路由标记才会出现在AS外部LSA中。
o The capability for an AS-external-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if the Referenced LS Type is non-zero). This capability is for future use; the Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined.
o 通过包含引用的LS类型字段和可选的引用链接状态ID字段（当且仅当引用的LS类型为非零时，后者才存在），支持AS外部LSA引用另一个LSA的能力。这种能力是为了将来使用；引用的LS类型应设置为0，并且在定义其使用之前，应忽略此字段接收到的非零值。
As an example, consider the OSPF Autonomous System depicted in Figure 6 of [OSPFV2]. Assume that RT7 has learned its route to N12 via BGP and that it wishes to advertise a Type 2 metric into the AS. Also assume that the IPv6 prefix for N12 is the value 2001:0db8:0a00::/40. RT7 would then originate the following AS-external-LSA for the external network N12. Note that within the AS-external-LSA, N12's prefix occupies 64 bits of space in order to maintain 32-bit alignment.
作为一个例子，考虑OSPF自治系统在图6中描述的[OSPFv2]。假设RT7已经学会了通过BGP到N12的路由，并且希望在AS中公布类型2度量。还假设N12的IPv6前缀为值2001:0db8:0a00:：/40。RT7随后将发起以下作为外部网络N12的外部LSA。请注意，在AS外部LSA中，N12的前缀占用64位空间以保持32位对齐。
; AS-external-LSA for Network N12, ; originated by Router RT7
; 作为网络N12的外部LSA；由路由器RT7发起
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;LSA type/scope unique identifier
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
LS age = 0 ;newly (re)originated
LS type = 0x4005 ;AS-external-LSA
Link State ID = 123 ;LSA type/scope unique identifier
Advertising Router = Router RT7's ID
bit E = 1 ;Type 2 metric
bit F = 0 ;no forwarding address
bit T = 1 ;external route tag included
Metric = 2
PrefixLength = 40
PrefixOptions = 0
Referenced LS Type = 0 ;no Referenced Link State ID
Address Prefix = 2001:0db8:0a00 ;padded to 64-bits
External Route Tag = as per BGP/OSPF interaction
AS-external-LSA for Network N12, originated by Router RT7
作为网络N12的外部LSA，由路由器RT7发起
The LS type of an NSSA-LSA is set to the value 0x2007. NSSA-LSAs have area flooding scope. Each NSSA-LSA describes a path to a prefix external to the Autonomous System whose flooding scope is restricted to a single NSSA area.
NSSA-LSA的LS类型设置为值0x2007。NSSA LSA具有区域泛洪范围。每个NSSA-LSA描述到自治系统外部前缀的路径，该自治系统的泛洪范围仅限于单个NSSA区域。
The procedure for originating NSSA-LSAs in IPv6 is the same as the IPv4 procedure documented in [NSSA], with the following exceptions:
在IPv6中发起NSSA LSA的过程与[NSSA]中记录的IPv4过程相同，但有以下例外：
o The Link State ID of an NSSA-LSA has lost all of its addressing semantics and simply serves to distinguish multiple NSSA-LSAs that are originated by the same router in the same area.
o NSSA-LSA的链路状态ID已丢失其所有寻址语义，仅用于区分同一区域内由同一路由器发起的多个NSSA LSA。
o The prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields embedded within the LSA body. Network Mask is no longer specified.
o 前缀由嵌入在LSA正文中的前缀长度、前缀选项和地址前缀字段描述。不再指定网络掩码。
o The NU-bit in the PrefixOptions field should be clear.
o PrefixOptions字段中的NU位应为空。
o Link-local addresses can never be advertised in NSSA-LSAs.
o 链路本地地址永远不能在NSSA LSA中公布。
o The forwarding address is present in the NSSA-LSA if and only if the NSSA-LSA's bit F is set.
o 当且仅当NSSA-LSA的位F设置时，NSSA-LSA中存在转发地址。
o The external route tag is present in the NSSA-LSA if and only if the NSSA-LSA's bit T is set.
o 当且仅当NSSA-LSA的位T设置时，NSSA-LSA中存在外部路由标签。
o The capability for an NSSA-LSA to reference another LSA has been supported through the inclusion of the Referenced LS Type field and the optional Referenced Link State ID field (the latter present if and only if the Referenced LS Type is non-zero). This capability is for future use; the Referenced LS Type should be set to 0, and received non-zero values for this field should be ignored until its use is defined.
o NSSA-LSA引用另一个LSA的能力通过包含引用的LS类型字段和可选的引用链接状态ID字段得到了支持（当且仅当引用的LS类型为非零时，后者才存在）。这种能力是为了将来使用；引用的LS类型应设置为0，并且在定义其使用之前，应忽略此字段接收到的非零值。
An example of an NSSA-LSA would only differ from an AS-external-LSA in that the LS type would be 0x2007 rather than 0x4005.
NSSA-LSA的示例与AS外部LSA的唯一区别在于LS类型为0x2007而不是0x4005。
The LS type of a link-LSA is set to the value 0x0008. Link-LSAs have link-local flooding scope. A router originates a separate link-LSA for each attached link that supports two or more (including the originating router itself) routers. Link-LSAs SHOULD NOT be originated for virtual links.
链路LSA的LS类型设置为值0x0008。链路LSA具有链路本地泛洪范围。路由器为支持两个或多个（包括发起路由器本身）路由器的每个连接链路发起单独的链路LSA。不应为虚拟链路发起链路LSA。
Link-LSAs have three purposes:
链路LSA有三个用途：
1. They provide the router's link-local address to all other routers attached to the link.
1. 它们将路由器的链路本地地址提供给连接到链路的所有其他路由器。
2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link.
2. 它们通知连接到该链路的其他路由器要与该链路关联的IPv6前缀列表。
3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a broadcast or NBMA link.
3. 它们允许路由器在网络LSA中公布由指定路由器在广播或NBMA链路上发起的选项位集合。
A link-LSA for a given Link L is built in the following fashion:
给定链路L的链路LSA以以下方式构建：
o The Link State ID is set to the router's Interface ID on Link L.
o 链路状态ID设置为链路L上路由器的接口ID。
o The Router Priority of the router's interface to Link L is inserted into the link-LSA.
o 路由器与链路L的接口的路由器优先级插入链路LSA。
o The link-LSA's Options field is set to reflect the router's capabilities. On multi-access links, the Designated Router will logically OR the link-LSA Options fields for all fully adjacent neighbors in Link L's network-LSA.
o 链路LSA的选项字段设置为反映路由器的功能。在多址链路上，指定的路由器将逻辑上或链路L的网络LSA中所有完全相邻的邻居的链路LSA选项字段。
o The router inserts its link-local address on Link L into the link-LSA. This information will be used when the other routers on Link L do their next-hop calculations (see Section 4.8.2).
o 路由器将其链路L上的链路本地地址插入链路LSA。当链路L上的其他路由器进行下一跳计算时，将使用此信息（见第4.8.2节）。
o Each IPv6 address prefix that has been configured on Link L is added to the link-LSA by specifying values for the PrefixLength, PrefixOptions, and Address Prefix fields.
o 通过指定PrefixLength、PrefixOptions和address prefix字段的值，将在链路L上配置的每个IPv6地址前缀添加到链路LSA。
After building a link-LSA for a given link, the router installs the link-LSA into the associated interface data structure and floods the link-LSA on the link. All other routers on the link will receive the link-LSA, but they will not flood the link-LSA on other links.
在为给定链路构建链路LSA后，路由器将链路LSA安装到关联的接口数据结构中，并在链路上使用链路LSA。链路上的所有其他路由器将接收链路LSA，但它们不会在其他链路上溢出链路LSA。
If LinkLSASuppression is configured for the interface and the interface type is not broadcast or NBMA, origination of the link-LSA may be suppressed. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2). Refer to Appendix C.3 for a description of the LinkLSASuppression interface configuration parameter.
如果为接口配置了linklsa抑制，并且接口类型不是广播或NBMA，则可以抑制链路LSA的发起。这意味着链路上的其他路由器将使用链路LSA以外的机制确定路由器的下一跳地址（见第4.8.2节）。有关LinkLSASuppression接口配置参数的说明，请参阅附录C.3。
As an example, consider the link-LSA that RT3 will build for N3 in Figure 1. Suppose that the prefix 2001:0db8:c001:0100::/56 has been configured within RT3 for N3. This will result in the following link-LSA that RT3 will flood only on N3. Note that not all routers on N3 need be configured with the prefix; those not configured will learn the prefix when receiving RT3's link-LSA.
作为一个例子，考虑RT3将在图1中为N3构建的链路LSA。假设已在RT3中为N3配置前缀2001:0db8:c001:0100:：/56。这将导致以下链路LSA，RT3将仅在N3上泛洪。注意，并非N3上的所有路由器都需要配置前缀；那些未配置的将在接收RT3的链路LSA时学习前缀。
; RT3's link-LSA for N3
; N3的RT3链路LSA
LS age = 0 ;newly (re)originated
LS type = 0x0008 ;link-LSA
Link State ID = 1 ;RT3's Interface ID on N3
Advertising Router = 192.0.2.3 ;RT3's Router ID
Rtr Priority = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
LS age = 0 ;newly (re)originated
LS type = 0x0008 ;link-LSA
Link State ID = 1 ;RT3's Interface ID on N3
Advertising Router = 192.0.2.3 ;RT3's Router ID
Rtr Priority = 1 ;RT3's N3 Router Priority
Options = (V6-bit|E-bit|R-bit)
Link-local Interface Address = fe80:0001::RT3
# prefixes = 1
PrefixLength = 56
PrefixOptions = 0
Address Prefix = 2001:0db8:c001:0100 ;pad to 64-bits
RT3's link-LSA for N3
N3的RT3链路LSA
The LS type of an intra-area-prefix-LSA is set to the value 0x2009. Intra-area-prefix-LSAs have area flooding scope. An intra-area-prefix-LSA has one of two functions. It either associates a list of IPv6 address prefixes with a transit network link by referencing a network-LSA, or associates a list of IPv6 address prefixes with a router by referencing a router-LSA. A stub link's prefixes are associated with its attached router.
区域内前缀LSA的LS类型设置为值0x2009。区域内前缀LSA具有区域泛洪范围。区域内前缀LSA具有两种功能之一。它或者通过引用网络LSA将IPv6地址前缀列表与传输网络链路相关联，或者通过引用路由器LSA将IPv6地址前缀列表与路由器相关联。存根链接的前缀与其连接的路由器相关联。
A router MAY originate multiple intra-area-prefix-LSAs for a given area. Each intra-area-prefix-LSA has a unique Link State ID and contains an integral number of prefix descriptions.
路由器可以为给定区域发起多个区域内前缀lsa。每个区域内前缀LSA具有唯一的链路状态ID，并且包含整数个前缀描述。
A link's Designated Router originates one or more intra-area-prefix-LSAs to advertise the link's prefixes throughout the area. For a link L, L's Designated Router builds an intra-area-prefix-LSA in the following fashion:
链路的指定路由器发起一个或多个区域内前缀LSA，以在整个区域内公布链路的前缀。对于链路L，L的指定路由器以以下方式构建区域内前缀LSA：
o In order to indicate that the prefixes are to be associated with the Link L, the fields Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router are set to the corresponding fields in Link L's network-LSA (namely, LS type, Link State ID, and Advertising Router respectively). This means that the Referenced LS Type is set to 0x2002, the Referenced Link State ID is set to the Designated Router's Interface ID on Link L, and the Referenced Advertising Router is set to the Designated Router's Router ID.
o 为了指示前缀将与链路L相关联，将被引用的LS Type、被引用的链路状态ID和被引用的广告路由器的字段设置为链路L的网络LSA中的相应字段（即，分别为LS Type、链路状态ID和广告路由器）。这意味着引用的LS类型设置为0x2002，引用的链路状态ID设置为链路L上指定路由器的接口ID，引用的广告路由器设置为指定路由器的路由器ID。
o Each link-LSA associated with Link L is examined (these are in the Designated Router's interface structure for Link L). If the link-LSA's Advertising Router is fully adjacent to the Designated
o 检查与链路L相关联的每个链路LSA（它们位于链路L的指定路由器接口结构中）。如果链路LSA的广告路由器与指定的
Router and the Link State ID matches the neighbor's interface ID, the list of prefixes in the link-LSA is copied into the intra-area-prefix-LSA that is being built. Prefixes having the NU-bit and/or LA-bit set in their Options field SHOULD NOT be copied, nor should link-local addresses be copied. Each prefix is described by the PrefixLength, PrefixOptions, and Address Prefix fields. Multiple prefixes having the same PrefixLength and Address Prefix are considered to be duplicates. In this case, their PrefixOptions fields should be logically OR'ed together, and a single instance of the duplicate prefix should be included in the intra-area-prefix-LSA. The Metric field for all prefixes is set to 0.
当路由器和链路状态ID与邻居的接口ID匹配时，链路LSA中的前缀列表被复制到正在构建的区域内前缀LSA中。不应复制在其选项字段中设置了NU位和/或LA位的前缀，也不应复制链接本地地址。每个前缀由前缀长度、前缀选项和地址前缀字段描述。具有相同前缀长度和地址前缀的多个前缀被认为是重复的。在这种情况下，它们的PrefixOptions字段应该在逻辑上“或”在一起，并且重复前缀的单个实例应该包含在区域内前缀LSA中。所有前缀的度量字段都设置为0。
o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small.
o “#前缀”字段设置为路由器复制到LSA中的前缀数量。如有必要，前缀列表可以分布在多个区域内前缀LSA上，以保持LSA大小较小。
A router builds an intra-area-prefix-LSA to advertise prefixes for its attached stub links, looped-back interfaces, and hosts. A Router RTX would build its intra-area-prefix-LSA in the following fashion:
路由器构建一个区域内前缀LSA，为其连接的存根链路、环回接口和主机播发前缀。路由器RTX将以以下方式构建其区域内前缀LSA：
o In order to indicate that the prefixes are to be associated with the Router RTX itself, RTX sets the Referenced LS Type to 0x2001, the Referenced Link State ID to 0, and the Referenced Advertising Router to RTX's own Router ID.
o 为了指示前缀将与路由器RTX本身相关联，RTX将引用的LS类型设置为0x2001，将引用的链路状态ID设置为0，将引用的播发路由器设置为RTX自己的路由器ID。
o Router RTX examines its list of interfaces to the area. If the interface is in the state Down, its prefixes are not included. If the interface has been reported in RTX's router-LSA as a Type 2 link description (link to transit network), prefixes that will be included in the intra-area-prefix-LSA for the link are skipped. However, any prefixes that would normally have the LA-bit set SHOULD be advertised independent of whether or not the interface is advertised as a transit link. If the interface type is point-to-multipoint or the interface is in the state Loopback, the global scope IPv6 addresses associated with the interface (if any) are copied into the intra-area-prefix-LSA with the PrefixOptions LA-bit set, the PrefixLength set to 128, and the metric set to 0. Otherwise, the list of global prefixes configured in RTX for the link are copied into the intra-area-prefix-LSA by specifying the PrefixLength, PrefixOptions, and Address Prefix fields. The Metric field for each of these prefixes is set to the interface's output cost.
o 路由器RTX检查其与该区域的接口列表。如果接口处于关闭状态，则不包括其前缀。如果RTX的路由器LSA中已将该接口报告为类型2链路描述（链路到传输网络），则将跳过该链路的区域内前缀LSA中包含的前缀。但是，任何通常设置了LA位的前缀都应该独立于接口是否作为传输链路进行播发而进行播发。如果接口类型为点对多点或接口处于状态环回，则与接口相关联的全局作用域IPv6地址（如果有）将复制到区域内前缀LSA中，前缀选项LA位设置、前缀长度设置为128、度量设置为0。否则，通过指定前缀长度、前缀选项和地址前缀字段，将在RTX中为链路配置的全局前缀列表复制到区域内前缀LSA中。每个前缀的度量字段都设置为接口的输出成本。
o RTX adds the IPv6 prefixes for any directly attached hosts belonging to the area (see Appendix C.7) to the intra-area-prefix-LSA.
o RTX将属于该区域的任何直接连接主机的IPv6前缀（见附录C.7）添加到区域内前缀LSA。
o If RTX has one or more virtual links configured through the area, it includes one of its global scope IPv6 interface addresses in the LSA (if it hasn't already), setting the LA-bit in the PrefixOptions field, the PrefixLength to 128, and the Metric to 0. This information will be used later in the routing calculation so that the two ends of the virtual link can discover each other's IPv6 addresses.
o 如果RTX通过该区域配置了一个或多个虚拟链路，则它在LSA中包括其一个全局作用域IPv6接口地址（如果还没有），在PrefixOptions字段中设置LA位，将PrefixLength设置为128，并将度量设置为0。该信息将在稍后的路由计算中使用，以便虚拟链路的两端可以发现彼此的IPv6地址。
o The "# prefixes" field is set to the number of prefixes that the router has copied into the LSA. If necessary, the list of prefixes can be spread across multiple intra-area-prefix-LSAs in order to keep the LSA size small.
o “#前缀”字段设置为路由器复制到LSA中的前缀数量。如有必要，前缀列表可以分布在多个区域内前缀LSA上，以保持LSA大小较小。
For example, the intra-area-prefix-LSA originated by RT4 for Network N3 (assuming that RT4 is N3's Designated Router) and the intra-area-prefix-LSA originated into Area 1 by Router RT3 for its own prefixes are pictured below.
例如，由RT4为网络N3发起的区域内前缀LSA（假设RT4是N3的指定路由器）和由路由器RT3为其自身前缀发起的区域内前缀LSA如下图所示。
; RT4's Intra-area-prefix-LSA for network link N3
; 网络链路N3的RT4区域内前缀LSA
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.4 ;RT4's Router ID
# prefixes = 1
Referenced LS Type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.0.2.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 2001:0db8:c001:0100 ;pad
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 5 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.4 ;RT4's Router ID
# prefixes = 1
Referenced LS Type = 0x2002 ;network-LSA reference
Referenced Link State ID = 1
Referenced Advertising Router = 192.0.2.4
PrefixLength = 56 ;N3's prefix
PrefixOptions = 0
Metric = 0
Address Prefix = 2001:0db8:c001:0100 ;pad
; RT3's Intra-area-prefix-LSA for its own prefixes
; RT3自身前缀的区域内前缀LSA
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.3 ;RT3's Router ID
# prefixes = 1
Referenced LS Type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.0.2.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 2001:0db8:c001:0400 ;pad
LS age = 0 ;newly (re)originated
LS type = 0x2009 ;Intra-area-prefix-LSA
Link State ID = 177 ;LSA type/scope unique identifier
Advertising Router = 192.0.2.3 ;RT3's Router ID
# prefixes = 1
Referenced LS Type = 0x2001 ;router-LSA reference
Referenced Link State ID = 0
Referenced Advertising Router = 192.0.2.3
PrefixLength = 56 ;N4's prefix
PrefixOptions = 0
Metric = 2 ;N4 interface cost
Address Prefix = 2001:0db8:c001:0400 ;pad
Intra-area-prefix-LSA for Network Link N3
网络链路N3的区域内前缀LSA
When network conditions change, it may be necessary for a router to move prefixes from one intra-area-prefix-LSA to another. For example, if the router is the Designated Router for a link but the link has no other attached routers, the link's prefixes are advertised in an intra-area-prefix-LSA referring to the Designated Router's router-LSA. When additional routers appear on the link, a network-LSA is originated for the link and the link's prefixes are moved to an intra-area-prefix-LSA referring to the network-LSA.
当网络条件改变时，路由器可能需要将前缀从一个区域内前缀LSA移动到另一个区域内前缀LSA。例如，如果路由器是链路的指定路由器，但该链路没有其他连接的路由器，则在参考指定路由器的路由器LSA的区域内前缀LSA中通告链路的前缀。当链路上出现其他路由器时，为链路发起网络LSA，并且链路的前缀被移动到参考网络LSA的区域内前缀LSA。
Note that in the intra-area-prefix-LSA, the Referenced Advertising Router is always equal to the router that is originating the intra-area-prefix-LSA (i.e., the LSA's Advertising Router). The reason the Referenced Advertising Router field appears is that, even though it is currently redundant, it may not be in the future. We may sometime want to use the same LSA format to advertise address prefixes for other protocol suites. In this case, the Designated Router may not
注意，在区域内前缀LSA中，引用的广告路由器始终等于发起区域内前缀LSA的路由器（即，LSA的广告路由器）。出现“参考广告路由器”字段的原因是，尽管它当前是冗余的，但将来可能不会。有时，我们可能希望使用相同的LSA格式为其他协议套件公布地址前缀。在这种情况下，指定的路由器可能不会
be running the other protocol suite, and so another of the link's routers may need to originate the intra-area-prefix-LSA. In that case, the Referenced Advertising Router and Advertising Router would be different.
正在运行另一个协议套件，因此链路的另一个路由器可能需要发起区域内前缀LSA。在这种情况下，引用的广告路由器和广告路由器将不同。
It is expected that new LSAs will be defined that will not be processed during the Shortest Path First (SPF) calculation as described in Section 4.8, for example, OSPFv3 LSAs corresponding to information advertised in OSPFv2 using opaque LSAs [OPAQUE]. In general, the new information advertised in future LSAs should not be used unless the OSPFv3 router originating the LSA is reachable. However, depending on the application and the data advertised, this reachability validation MAY be done less frequently than every SPF calculation.
预计将定义在第4.8节所述的最短路径优先（SPF）计算期间不会处理的新LSA，例如，OSPFv3 LSA对应于使用不透明LSA在OSPFv2中公布的信息[不透明]。一般来说，除非可以访问发起LSA的OSPFv3路由器，否则不应使用未来LSA中公布的新信息。然而，根据应用程序和公布的数据，此可达性验证的频率可能低于每次SPF计算。
To facilitate inter-area reachability validation, any OSPFv3 router originating AS scoped LSAs is considered an AS Boundary Router (ASBR).
为了便于区域间可达性验证，任何作为作用域LSA发起的OSPFv3路由器都被视为AS边界路由器（ASBR）。
Most of the flooding algorithm remains unchanged from the IPv4 flooding mechanisms described in Section 13 of [OSPFV2]. In particular, the protocol processes for determining which LSA instance is newer (Section 13.1 of [OSPFV2]), responding to updates of self-originated LSAs (Section 13.4 of [OSPFV2]), sending Link State Acknowledgment packets (Section 13.5 of [OSPFV2]), retransmitting LSAs (Section 13.6 of [OSPFV2]), and receiving Link State Acknowledgment packets (Section 13.7 of [OSPFV2]), are exactly the same for IPv6 and IPv4.
与[OSPFV2]第13节中描述的IPv4洪泛机制相比，大多数洪泛算法保持不变。具体地说，协议处理用于确定哪个LSA实例较新（OSPFV2的第13.1节），响应自创LSA的更新（OSPFV2的第13.4节），发送链路状态确认包（OSPFV2的第13.5节），重新传输LSA（OSPFV2的第13.6节），和接收链路状态确认数据包（OSPFV2的第13.7节）对于IPv6和IPv4完全相同。
However, the addition of flooding scope and unknown LSA type handling
(see Appendix A.4.2.1) has caused some changes in the OSPF flooding
algorithm: the reception of Link State Updates (Section 13 in
[OSPFV2]) and the sending of Link State Updates (Section 13.3 of
[OSPFV2]) must take into account the LSA's scope and U-bit setting.
Also, installation of LSAs into the OSPF database (Section 13.2 of
[OSPFV2]) causes different events in IPv6, due to the reorganization
of LSA types and the IPv6 LSA contents. These changes are described
in detail below.
However, the addition of flooding scope and unknown LSA type handling
(see Appendix A.4.2.1) has caused some changes in the OSPF flooding
algorithm: the reception of Link State Updates (Section 13 in
[OSPFV2]) and the sending of Link State Updates (Section 13.3 of
[OSPFV2]) must take into account the LSA's scope and U-bit setting.
Also, installation of LSAs into the OSPF database (Section 13.2 of
[OSPFV2]) causes different events in IPv6, due to the reorganization
of LSA types and the IPv6 LSA contents. These changes are described
in detail below.
The encoding of flooding scope in the LS type and the need to process unknown LS types cause modifications to the processing of received Link State Update packets. As in IPv4, each LSA in a received Link
LS类型中泛洪作用域的编码和处理未知LS类型的需要导致对接收到的链路状态更新数据包的处理进行修改。与IPv4中一样，接收链路中的每个LSA
State Update packet is examined. In IPv4, eight steps are executed for each LSA, as described in Section 13 of [OSPFV2]. For IPv6, all the steps are the same, except that Steps 2 and 3 are modified as follows:
检查状态更新包。在IPv4中，每个LSA执行八个步骤，如[OSPFV2]第13节所述。对于IPv6，所有步骤都相同，只是步骤2和3修改如下：
(2) Examine the LSA's LS type. Discard the LSA and get the next one from the Link State Update packet if the interface area has been configured as a stub or NSSA area and the LS type indicates "AS flooding scope".
(2) 检查LSA的LS类型。如果接口区域已配置为存根或NSSA区域，并且LS类型指示“as泛洪范围”，则丢弃LSA并从链路状态更新数据包中获取下一个LSA。
This generalizes the IPv4 behavior where AS-external-LSAs and AS-scoped opaque LSAs [OPAQUE] are not flooded throughout stub or NSSA areas.
这概括了IPv4的行为，即AS外部LSA和AS作用域不透明LSA[不透明]不会淹没整个存根或NSSA区域。
(3) Else if the flooding scope in the LSA's LS type is set to "reserved", discard the LSA and get the next one from the Link State Update packet.
(3) 否则，如果LSA的LS类型中的泛洪作用域设置为“保留”，则丢弃LSA并从链路状态更新数据包中获取下一个LSA。
Steps 5b (sending Link State Update packets) and 5d (installing LSAs in the link-state database) in Section 13 of [OSPFV2] are also somewhat different for IPv6, as described in Sections 4.5.2 and 4.5.3 below.
[OSPFV2]第13节中的步骤5b（发送链路状态更新包）和5d（在链路状态数据库中安装LSA）对于IPv6也有些不同，如下面第4.5.2节和第4.5.3节所述。
The sending of Link State Update packets is described in Section 13.3 of [OSPFV2]. For IPv4 and IPv6, the steps for sending a Link State Update packet are the same (steps 1 through 5 of Section 13.3 in [OSPFV2]). However, the list of eligible interfaces on which to flood the LSA is different. For IPv6, the eligible interfaces are selected based on the following factors:
[OSPFV2]第13.3节描述了链路状态更新包的发送。对于IPv4和IPv6，发送链路状态更新数据包的步骤相同（OSPFV2第13.3节的步骤1至5）。但是，要在其上泛洪LSA的合格接口列表是不同的。对于IPv6，根据以下因素选择符合条件的接口：
o The LSA's flooding scope.
o LSA的泛洪范围。
o For LSAs with area or link-local flooding scope, the particular area or interface with which the LSA is associated.
o 对于具有区域或链路局部泛洪范围的LSA，与LSA关联的特定区域或接口。
o Whether the LSA has a recognized LS type.
o LSA是否具有可识别的LS类型。
o The setting of the U-bit in the LS type. If the U-bit is set to 0, unrecognized LS types are treated as having link-local scope. If set to 1, unrecognized LS types are stored and flooded as if they were recognized.
o LS类型中U位的设置。如果U位设置为0，则无法识别的LS类型将被视为具有链接本地作用域。如果设置为1，则将存储未识别的LS类型并将其淹没，就像它们已被识别一样。
Choosing the set of eligible interfaces then breaks into the following cases:
选择一组符合条件的接口，然后分为以下几种情况：
Case 1 The LSA's LS type is recognized. In this case, the set of eligible interfaces is set depending on the flooding scope encoded in the LS type. If the flooding scope is "AS flooding scope", the eligible interfaces are all router interfaces excepting virtual links. In addition, AS-external-LSAs are not flooded on interfaces connecting to stub or NSSA areas. If the flooding scope is "area flooding scope", the eligible interfaces are those interfaces connecting to the LSA's associated area. If the flooding scope is "link-local flooding scope", then there is a single eligible interface, the one connecting to the LSA's associated link (which is also the interface on which the LSA was received in a Link State Update packet).
案例1 LSA的LS类型被识别。在这种情况下，根据LS类型中编码的泛洪作用域设置合格接口集。如果泛洪范围为“AS泛洪范围”，则符合条件的接口是除虚拟链路之外的所有路由器接口。此外，由于外部LSA不会淹没在连接到存根或NSSA区域的接口上。如果泛洪范围为“区域泛洪范围”，则合格接口为连接到LSA相关区域的接口。如果泛洪作用域是“链路本地泛洪作用域”，则存在单个合格接口，该接口连接到LSA的关联链路（也是在链路状态更新数据包中接收LSA的接口）。
Case 2 The LS type is unrecognized and the U-bit in the LS type is set to 0 (treat the LSA as if it had link-local flooding scope). In this case, there is a single eligible interface, namely, the interface on which the LSA was received.
情况2 LS类型无法识别，并且LS类型中的U位设置为0（将LSA视为具有链路局部泛洪作用域）。在这种情况下，有一个合格的接口，即接收LSA的接口。
Case 3 The LS type is unrecognized, and the U-bit in the LS type is set to 1 (store and flood the LSA as if the type is understood). In this case, select the eligible interfaces based on the encoded flooding scope the same as in Case 1 above.
情况3 LS类型无法识别，并且LS类型中的U位设置为1（存储并泛洪LSA，就像理解类型一样）。在这种情况下，根据编码的泛洪范围选择符合条件的接口，与上述情况1相同。
A further decision must sometimes be made before adding an LSA to a given neighbor's link-state retransmission list (Step 1d in Section 13.3 of [OSPFV2]). If the LS type is recognized by the router but not by the neighbor (as can be determined by examining the Options field that the neighbor advertised in its Database Description packet) and the LSA's U-bit is set to 0, then the LSA should be added to the neighbor's link-state retransmission list if and only if that neighbor is the Designated Router or Backup Designated Router for the attached link. The LS types described in detail by this document, namely, router-LSAs (LS type 0x2001), network-LSAs (0x2002), inter-area-prefix-LSAs (0x2003), inter-area-router-LSAs (0x2004), NSSA-LSAs (0x2007), AS-external-LSAs (0x4005), link-LSAs (0x0008), and Intra-Area-Prefix-LSAs (0x2009), are assumed to be understood by all routers. However, all LS types MAY not be understood by all routers. For example, a new LSA type with its U-bit set to 0 MAY only be understood by a subset of routers. This new LS type should only be flooded to an OSPF neighbor that understands the LS type or when the neighbor is the Designated Router or Backup Designated Router for the attached link.
有时，在将LSA添加到给定邻居的链路状态重传列表之前，必须做出进一步的决定（OSPFV2第13.3节中的步骤1d）。如果LS类型由路由器识别，但邻居无法识别（可通过检查邻居在其数据库描述数据包中公布的选项字段确定），并且LSA的U位设置为0，然后，LSA应添加到邻居的链路状态重传列表中，当且仅当该邻居是连接链路的指定路由器或备份指定路由器时。本文档详细描述的LS类型，即路由器LSA（LS类型0x2001）、网络LSA（0x2002）、区域间前缀LSA（0x2003）、区域间路由器LSA（0x2004）、NSSA LSA（0x2007）、外部LSA（0x4005）、链路LSA（0x0008）和区域内前缀LSA（0x2009），假定所有路由器都能理解。然而，并非所有路由器都能理解所有LS类型。例如，U位设置为0的新LSA类型只能被路由器的子集理解。这种新的LS类型应仅适用于理解LS类型的OSPF邻居，或者当邻居是连接链路的指定路由器或备份指定路由器时。
The previous paragraph solves a problem for IPv4 OSPF extensions, which require that the Designated Router support the extension in order to have the new LSA types flooded across broadcast and NBMA networks.
上一段解决了IPv4 OSPF扩展的一个问题，它要求指定的路由器支持该扩展，以便使新的LSA类型在广播和NBMA网络中泛滥。
There are three separate places to store LSAs, depending on their flooding scope. LSAs with AS flooding scope are stored in the global OSPF data structure (see Section 4.1) as long as their LS type is known or their U-bit is 1. LSAs with area flooding scope are stored in the appropriate area data structure (see Section 4.1.1) as long as their LS type is known or their U-bit is 1. LSAs with link-local flooding scope, and those LSAs with unknown LS type and U-bit set to 0 (treat the LSA as if it had link-local flooding scope), are stored in the appropriate interface data structure.
根据LSA的泛洪范围，有三个单独的位置可存储LSA。具有AS泛洪作用域的LSA存储在全局OSPF数据结构中（见第4.1节），只要其LS类型已知或其U位为1。具有区域泛洪范围的LSA存储在适当的区域数据结构中（见第4.1.1节），只要其LS类型已知或其U位为1。具有链路本地泛洪作用域的LSA，以及那些具有未知LS类型且U位设置为0的LSA（将LSA视为具有链路本地泛洪作用域）存储在适当的接口数据结构中。
When storing the LSA into the link-state database, a check must be made to see whether the LSA's contents have changed. Changes in contents are indicated exactly as in Section 13.2 of [OSPFV2]. When an LSA's contents have been changed, the following parts of the routing table must be recalculated, based on the LSA's LS type:
将LSA存储到链接状态数据库时，必须检查LSA的内容是否已更改。内容的变化如[OSPFV2]第13.2节所示。更改LSA的内容后，必须根据LSA的LS类型重新计算路由表的以下部分：
Router-LSAs, Network-LSAs, Intra-Area-Prefix-LSAs, and Link-LSAs The entire routing table is recalculated, starting with the shortest-path calculation for each area (see Section 4.8).
路由器LSA、网络LSA、区域内前缀LSA和链路LSA重新计算整个路由表，从每个区域的最短路径计算开始（见第4.8节）。
Inter-Area-Prefix-LSAs and Inter-Area-Router-LSAs The best route to the destination described by the LSA must be recalculated (see Section 16.5 in [OSPFV2]). If this destination is an AS boundary router, it may also be necessary to re-examine all the AS-external-LSAs.
必须重新计算区域间前缀LSA和区域间路由器LSA到LSA所述目的地的最佳路由（见[OSPFV2]第16.5节）。如果此目的地是AS边界路由器，则可能还需要重新检查所有AS外部LSA。
AS-external-LSAs and NSSA-LSAs The best route to the destination described by the AS-external-LSA or NSSA-LSA must be recalculated (see Section 16.6 in [OSPFV2] and Section 2.0 in [NSSA]).
作为外部LSA和NSSA LSA，必须重新计算到达AS外部LSA或NSSA-LSA所述目的地的最佳路线（见[OSPFV2]第16.6节和[NSSA]第2.0节）。
As in IPv4, any old instance of the LSA must be removed from the database when the new LSA is installed. This old instance must also be removed from all neighbors' link-state retransmission lists.
与IPv4中一样，在安装新LSA时，必须从数据库中删除LSA的任何旧实例。还必须从所有邻居的链路状态重传列表中删除此旧实例。
In IPv6, the definition of a self-originated LSA has been simplified from the IPv4 definition appearing in Sections 13.4 and 14.1 of [OSPFV2]. For IPv6, self-originated LSAs are those LSAs whose Advertising Router is equal to the router's own Router ID.
在IPv6中，自创LSA的定义已从[OSPFV2]第13.4节和第14.1节中的IPv4定义简化。对于IPv6，自创LSA是指其广告路由器等于路由器自身路由器ID的LSA。
OSPF virtual links for IPv4 are described in Section 15 of [OSPFV2]. Virtual links are the same in IPv6, with the following exceptions:
[OSPFV2]第15节描述了IPv4的OSPF虚拟链路。IPv6中的虚拟链路相同，但有以下例外：
o LSAs having AS flooding scope are never flooded over virtual adjacencies, nor are LSAs with AS flooding scope summarized over virtual adjacencies during the database exchange process. This is a generalization of the IPv4 treatment of AS-external-LSAs.
o 在数据库交换过程中，具有AS泛洪作用域的LSA不会淹没在虚拟邻接上，也不会在虚拟邻接上汇总具有AS泛洪作用域的LSA。这是IPv4对AS外部LSA处理的概括。
o The IPv6 interface address of a virtual link MUST be an IPv6 address having global scope, instead of the link-local addresses used by other interface types. This address is used as the IPv6 source for OSPF protocol packets sent over the virtual link. Hence, a link-LSA SHOULD NOT be originated for a virtual link since the virtual link has no link-local address or associated prefixes.
o 虚拟链路的IPv6接口地址必须是具有全局作用域的IPv6地址，而不是其他接口类型使用的链路本地地址。此地址用作通过虚拟链路发送的OSPF协议数据包的IPv6源。因此，不应为虚拟链路发起链路LSA，因为虚拟链路没有链路本地地址或相关前缀。
o Likewise, the virtual neighbor's IPv6 address is an IPv6 address with global scope. To enable the discovery of a virtual neighbor's IPv6 address during the routing calculation, the neighbor advertises its virtual link's IPv6 interface address in an intra-area-prefix-LSA originated for the virtual link's transit area (see Section 4.4.3.9 and Section 4.8.1).
o 同样，虚拟邻居的IPv6地址是具有全局作用域的IPv6地址。为了能够在路由计算期间发现虚拟邻居的IPv6地址，邻居在为虚拟链路的传输区域生成的区域内前缀LSA中播发其虚拟链路的IPv6接口地址（参见第4.4.3.9节和第4.8.1节）。
o Like all other IPv6 OSPF interfaces, virtual links are assigned unique (within the router) Interface IDs. These are advertised in Hellos sent over the virtual link and in the router's router-LSAs.
o 与所有其他IPv6 OSPF接口一样，虚拟链路被分配唯一的（在路由器内）接口ID。这些在通过虚拟链路发送的HELOS和路由器的路由器LSA中公布。
The IPv6 OSPF routing calculation proceeds along the same lines as the IPv4 OSPF routing calculation, following the five steps specified by Section 16 of [OSPFV2]. High-level differences between the IPv6 and IPv4 calculations include:
IPv6 OSPF路由计算按照[OSPFV2]第16节规定的五个步骤，按照与IPv4 OSPF路由计算相同的路线进行。IPv6和IPv4计算之间的高级别差异包括：
o Prefix information has been removed from router-LSAs and network-LSAs and is now advertised in intra-area-prefix-LSAs. Whenever [OSPFV2] specifies that stub networks within router-LSAs be examined, IPv6 will instead examine prefixes within intra-area-prefix-LSAs.
o 前缀信息已从路由器LSA和网络LSA中删除，现在在区域内前缀LSA中公布。每当[OSPFV2]指定检查路由器LSA内的存根网络时，IPv6将改为检查区域内前缀LSA内的前缀。
o Type 3 and 4 summary-LSAs have been renamed inter-area-prefix-LSAs and inter-area-router-LSAs respectively.
o 类型3和4摘要LSA已分别重命名为区域间前缀LSA和区域间路由器LSA。
o Addressing information is no longer encoded in Link State IDs and is now only found within the body of LSAs.
o 寻址信息不再在链路状态ID中编码，现在只能在LSA主体中找到。
o In IPv6, a router can originate multiple router-LSAs, distinguished by Link State ID, within a single area. These router-LSAs MUST be treated as a single aggregate by the area's shortest-path calculation (see Section 4.8.1).
o 在IPv6中，路由器可以在单个区域内发起多个路由器LSA，通过链路状态ID进行区分。必须通过区域最短路径计算将这些路由器LSA视为单个集合（见第4.8.1节）。
For each area, the shortest-path tree calculation creates routing table entries for the area's routers and transit links (see Section 4.8.1). These entries are then used when processing intra-area-prefix-LSAs, inter-area-prefix-LSAs, and inter-area-router-LSAs, as described in Section 4.8.3.
对于每个区域，最短路径树计算为该区域的路由器和传输链路创建路由表条目（见第4.8.1节）。然后在处理区域内前缀LSA、区域间前缀LSA和区域间路由器LSA时使用这些条目，如第4.8.3节所述。
Events generated as a result of routing table changes (Section 16.7 of [OSPFV2]) and the equal-cost multipath logic (Section 16.8 of [OSPFV2]) are identical for both IPv4 and IPv6.
由于路由表更改（第16.7节[OSPFV2]）和等成本多路径逻辑（第16.8节[OSPFV2]）而生成的事件对于IPv4和IPv6都是相同的。
The IPv4 shortest-path calculation is contained in Section 16.1 of [OSPFV2]. The graph used by the shortest-path tree calculation is identical for both IPv4 and IPv6. The graph's vertices are routers and transit links, represented by router-LSAs and network-LSAs respectively. A router is identified by its OSPF Router ID, while a transit link is identified by its Designated Router's Interface ID and OSPF Router ID. Both routers and transit links have associated routing table entries within the area (see Section 4.3).
IPv4最短路径计算包含在[OSPFV2]的第16.1节中。最短路径树计算所使用的图形对于IPv4和IPv6都是相同的。图的顶点是路由器和传输链路，分别由路由器LSA和网络LSA表示。路由器由其OSPF路由器ID标识，而传输链路由其指定路由器的接口ID和OSPF路由器ID标识。路由器和传输链路在区域内都有相关的路由表条目（见第4.3节）。
Section 16.1 of [OSPFV2] splits up the shortest-path calculations into two stages. First, the Dijkstra calculation is performed, and then the stub links are added onto the tree as leaves. The IPv6 calculation maintains this split.
[OSPFV2]第16.1节将最短路径计算分为两个阶段。首先，执行Dijkstra计算，然后将存根链接作为树叶添加到树上。IPv6计算将维护此拆分。
The Dijkstra calculation for IPv6 is identical to that specified for IPv4, with the following exceptions (referencing the steps from the Dijkstra calculation as described in Section 16.1 of [OSPFV2]):
IPv6的Dijkstra计算与IPv4的计算相同，但有以下例外（参考[OSPFV2]第16.1节中描述的Dijkstra计算步骤）：
o The Vertex ID for a router is the OSPF Router ID. The Vertex ID for a transit network is a combination of the Interface ID and OSPF Router ID of the network's Designated Router.
o 路由器的顶点ID是OSPF路由器ID。传输网络的顶点ID是网络指定路由器的接口ID和OSPF路由器ID的组合。
o In Step 2, when a router Vertex V has just been added to the shortest-path tree, there may be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to V's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA. The Options field and the
o 在步骤2中，当路由器顶点V刚刚添加到最短路径树时，可能有多个LSA与路由器关联。所有将广告路由器设置为V的OSPF路由器ID的路由器LSA都必须作为聚合处理，将它们视为单个大型路由器LSA的片段。选项字段和
router type bits (bits Nt, V, E, and B) should always be taken from the router-LSA with the smallest Link State ID.
路由器类型位（位Nt、V、E和B）应始终取自链路状态ID最小的路由器LSA。
o Step 2a is not needed in IPv6, as there are no longer stub network links in router-LSAs.
o IPv6中不需要步骤2a，因为路由器LSA中不再有存根网络链路。
o In Step 2b, if W is a router and the router-LSA V6-bit or R-bit is not set in the LSA options, the transit link W is ignored and V's next link is examined.
o 在步骤2b中，如果W是路由器并且在LSA选项中未设置路由器LSA V6位或R位，则忽略传输链路W并且检查V的下一链路。
o In Step 2b, if W is a router, there may again be multiple LSAs associated with the router. All router-LSAs with the Advertising Router set to W's OSPF Router ID MUST be processed as an aggregate, treating them as fragments of a single large router-LSA.
o 在步骤2b中，如果W是路由器，则可能再次存在与路由器相关联的多个lsa。所有将广告路由器设置为W的OSPF路由器ID的路由器LSA必须作为一个集合进行处理，将它们视为单个大型路由器LSA的片段。
o In Step 4, there are now per-area routing table entries for each of an area's routers rather than just the area border routers. These entries subsume all the functionality of IPv4's area border router routing table entries, including the maintenance of virtual links. When the router added to the area routing table in this step is the other end of a virtual link, the virtual neighbor's IP address is set as follows: The collection of intra-area-prefix-LSAs originated by the virtual neighbor is examined, with the virtual neighbor's IP address being set to the first prefix encountered with the LA-bit set.
o 在步骤4中，现在每个区域的路由器都有每个区域的路由表条目，而不仅仅是区域边界路由器。这些条目包含IPv4的区域边界路由器路由表条目的所有功能，包括虚拟链路的维护。当在此步骤中添加到区域路由表的路由器是虚拟链路的另一端时，虚拟邻居的IP地址设置如下：检查由虚拟邻居发起的区域内前缀LSA的集合，虚拟邻居的IP地址设置为LA位集遇到的第一个前缀。
o Routing table entries for transit networks, which are no longer associated with IP networks, are also calculated in Step 4 and added to the per-area routing table.
o 公交网络的路由表条目（不再与IP网络关联）也将在步骤4中计算并添加到每区域路由表中。
The next stage of the shortest-path calculation proceeds similarly to the two steps of the second stage of Section 16.1 in [OSPFV2]. However, instead of examining the stub links within router-LSAs, the list of the area's intra-area-prefix-LSAs is examined. A prefix advertisement whose NU-bit is set SHOULD NOT be included in the routing calculation. The cost of any advertised prefix is the sum of the prefix's advertised metric plus the cost to the transit vertex (either router or transit network) identified by intra-area-prefix-LSA's Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router fields. This latter cost is stored in the transit vertex's routing table entry for the area.
最短路径计算的下一阶段类似于[OSPFV2]第16.1节第二阶段的两个步骤。但是，不检查路由器lsa内的存根链路，而是检查区域内前缀lsa的列表。路由计算中不应包括设置了NU位的前缀播发。任何播发前缀的成本是前缀的播发度量加上由区域内前缀LSA的引用LS类型、引用链路状态ID和引用的播发路由器字段标识的中转顶点（路由器或中转网络）的成本之和。后一种成本存储在该区域的transit vertex的路由表条目中。
This specification does not require that the above algorithm be used to calculate the intra-area shortest-path tree. However, if another algorithm or optimization is used, an identical shortest-path tree must be produced. It is also important that any alternate algorithm or optimization maintain the requirement that transit vertices must
本规范不要求使用上述算法计算区域内最短路径树。但是，如果使用其他算法或优化，则必须生成相同的最短路径树。同样重要的是，任何替代算法或优化都必须保持过境点必须满足的要求
be bidirectional for inclusion in the tree. Alternate algorithms and optimizations are beyond the scope of this specification.
必须是双向的，以便包含在树中。替代算法和优化超出了本规范的范围。
In IPv6, the calculation of the next-hop's IPv6 address (which will be a link-local address) proceeds along the same lines as the IPv4 next-hop calculation (see Section 16.1.1 of [OSPFV2]). However, there are some differences. When calculating the next-hop IPv6 address for a router (call it Router X) that shares a link with the calculating router, the calculating router assigns the next-hop IPv6 address to be the link-local interface address contained in Router X's link-LSA (see Appendix A.4.9) for the link. This procedure is necessary for some link types, for example NBMA, where the two routers need not be neighbors and might not be exchanging OSPF Hello packets. For other link types, the next-hop address may be determined via the IPv6 source address in the neighbor's Hello packet.
在IPv6中，下一个跃点的IPv6地址（将是链路本地地址）的计算与IPv4下一个跃点的计算（见[OSPFV2]第16.1.1节）的过程相同。但是，也存在一些差异。计算与计算路由器共享链路的路由器（称为路由器X）的下一跳IPv6地址时，计算路由器将下一跳IPv6地址指定为路由器X链路LSA（见附录a.4.9）中包含的链路本地接口地址。此过程对于某些链路类型是必需的，例如NBMA，其中两个路由器不需要是邻居，也可能不交换OSPF Hello数据包。对于其他链路类型，可以通过邻居的Hello数据包中的IPv6源地址来确定下一跳地址。
Additionally, when calculating routes for the area's intra-area-prefix-LSAs, the parent vertex can be either a router-LSA or network-LSA. This is in contrast to the second stage of the OSPFv2 intra-area SPF (Section 16.1 in [OSPFV2]) where the parent vertex is always a router-LSA. In the case where the intra-area-prefix-LSA's referenced LSA is a directly connected network-LSA, the prefixes are also considered to be directly connected. In this case, the next hop is solely the outgoing link and no IPv6 next-hop address is selected.
此外，当计算区域内前缀LSA的路由时，父顶点可以是路由器LSA或网络LSA。这与OSPFv2区域内SPF的第二阶段（见[OSPFv2]第16.1节）形成对比，其中父顶点始终是路由器LSA。在区域内前缀LSA的参考LSA是直接连接的网络LSA的情况下，前缀也被认为是直接连接的。在这种情况下，下一跳仅为传出链路，未选择IPv6下一跳地址。
Calculation of inter-area routes for IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.2 of [OSPFV2], with the following modifications:
IPv6区域间路由的计算过程与[OSPFV2]第16.2节中的IPv4计算过程相同，但有以下修改：
o The names of the Type 3 summary-LSAs and Type 4 summary-LSAs have been changed to inter-area-prefix-LSAs and inter-area-router-LSAs respectively.
o 类型3摘要LSA和类型4摘要LSA的名称已分别更改为区域间前缀LSA和区域间路由器LSA。
o The Link State ID of the above LSA types no longer encodes the network or router described by the LSA. Instead, an address prefix is contained in the body of an inter-area-prefix-LSA and an advertised AS boundary router's OSPF Router ID is carried in the body of an inter-area-router-LSA.
o 上述LSA类型的链路状态ID不再编码LSA描述的网络或路由器。相反，在区域间前缀LSA的主体中包含地址前缀，并且在区域间路由器LSA的主体中携带作为边界路由器的OSPF路由器ID。
o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation.
o 区域间路由计算应忽略在PrefixOptions字段中设置了NU位的前缀。
When a single inter-area-prefix-LSA or inter-area-router-LSA has changed, the incremental calculations outlined in Section 16.5 of [OSPFV2] can be performed instead of recalculating the entire routing table.
当单个区域间前缀LSA或区域间路由器LSA发生变化时，可以执行[OSPFV2]第16.5节中概述的增量计算，而不是重新计算整个路由表。
Examination of transit areas' summary-LSAs in IPv6 proceeds along the same lines as the IPv4 calculation in Section 16.3 of [OSPFV2], modified in the same way as the IPv6 inter-area route calculation in Section 4.8.3.
IPv6中的中转区汇总LSA检查按照与[OSPFV2]第16.3节中的IPv4计算相同的路线进行，修改方式与第4.8.3节中的IPv6区域间路由计算相同。
The IPv6 AS external route calculation proceeds along the same lines as the IPv4 calculation in Section 16.4 of [OSPFV2] and Section 2.5 of [NSSA], with the following exceptions:
IPv6作为外部路由的计算过程与[OSPFV2]第16.4节和[NSSA]第2.5节中的IPv4计算过程相同，但以下情况除外：
o The Link State ID of the AS-external-LSA and NSSA-LSA types no longer encodes the network described by the LSA. Instead, an address prefix is contained in the body of the LSA.
o AS外部LSA和NSSA-LSA类型的链路状态ID不再编码LSA描述的网络。相反，地址前缀包含在LSA的主体中。
o The default route in AS-external-LSAs or NSSA-LSAs is advertised by a zero-length prefix.
o AS外部LSA或NSSA LSA中的默认路由由零长度前缀播发。
o Instead of comparing the AS-external-LSA's or NSSA-LSA's Forwarding Address field to 0.0.0.0 to see whether a forwarding address has been used, the bit F in the respective LSA is examined. A forwarding address is in use if and only if bit F is set.
o 不是将AS外部LSA或NSSA-LSA的转发地址字段与0.0.0.0进行比较以查看是否使用了转发地址，而是检查相应LSA中的位F。当且仅当设置了位F时，才使用转发地址。
o Prefixes having the NU-bit set in their PrefixOptions field should be ignored by the inter-area route calculation.
o 区域间路由计算应忽略在PrefixOptions字段中设置了NU位的前缀。
o AS Boundary Router (ASBR) and forwarding address selection will proceed the same as if RFC1583Compatibility is disabled. Furthermore, RFC1583Compatibility is not an OSPF for IPv6 configuration parameter. Refer to Appendix C.1.
o AS边界路由器（ASBR）和转发地址选择将与禁用RFC1583兼容性时相同。此外，RFC1583兼容性不是IPv6的OSPF配置参数。参考附录C.1。
When a single AS-external-LSA or NSSA-LSA has changed, the incremental calculations outlined in Section 16.6 of [OSPFV2] can be performed instead of recalculating the entire routing table.
当单个AS外部LSA或NSSA-LSA发生变化时，可以执行[OSPFV2]第16.6节中概述的增量计算，而不是重新计算整个路由表。
In OSPF for IPv6, a router may have multiple interfaces to a single link associated with the same OSPF instance and area. All interfaces
在用于IPv6的OSPF中，路由器可能具有多个与同一OSPF实例和区域关联的单个链路的接口。所有接口
will be used for the reception and transmission of data traffic while only a single interface sends and receives OSPF control traffic. In more detail:
将用于数据通信的接收和传输，而只有一个接口发送和接收OSPF控制通信。更详细地说：
o Each of the multiple interfaces is assigned a different Interface ID. A router will automatically detect that multiple interfaces are attached to the same link when a Hello packet is received with one of the router's link-local addresses as the source address and an Interface ID other than the Interface ID of the receiving interface.
o 多个接口中的每一个都分配了一个不同的接口ID。当接收到一个Hello数据包时，路由器将自动检测到多个接口连接到同一个链路，其中一个路由器的链路本地地址作为源地址，另一个接口ID不是接收接口的接口ID。
o Each of the multiple interfaces MUST be configured with the same Interface Instance ID to be considered on the same link. If an interface has multiple Instance IDs, it will be grouped with other interfaces based on matching Instance IDs. Each Instance ID will be treated uniquely with respect to groupings of multiple interfaces on the same link. For example, if interface A is configured with Instance IDs 1 and 35, and interface B is configured with Instance ID 35, interface B may be the Active Interface for Instance ID 35 but interface A will be active for Instance ID 1.
o 多个接口中的每一个都必须配置相同的接口实例ID，以便在同一链路上进行考虑。如果一个接口有多个实例ID，它将根据匹配的实例ID与其他接口分组。对于同一链接上多个接口的分组，每个实例ID将被唯一地处理。例如，如果接口A配置了实例ID 1和35，而接口B配置了实例ID 35，则接口B可能是实例ID 35的活动接口，但接口A将是实例ID 1的活动接口。
o The router will ignore OSPF packets other than Hello packets on all but one of the interfaces attached to the link. It will only send its OSPF control packets (including Hello packets) on a single interface. This interface is designated the Active Interface and other interfaces attached to the same link will be designated Standby Interfaces. The choice of the Active Interface is implementation dependent. For example, the interface with the highest Interface ID could be chosen. If the router is elected Designated Router, it will be the Active Interface's Interface ID that will be used as the network-LSA's Link State ID.
o 路由器将忽略除连接到链路的一个接口之外的所有接口上的除Hello数据包以外的OSPF数据包。它将只在单个接口上发送其OSPF控制数据包（包括Hello数据包）。此接口被指定为活动接口，连接到同一链路的其他接口将被指定为备用接口。活动接口的选择取决于实现。例如，可以选择具有最高接口ID的接口。如果路由器被选为指定的路由器，那么将使用活动接口的接口ID作为网络LSA的链路状态ID。
o All of the interfaces to the link (Active and Standby) will appear in the router-LSA. In addition, a link-LSA will be generated for each of the interfaces. In this way, all interfaces will be included in OSPF's routing calculations.
o 链路的所有接口（主动和备用）都将出现在路由器LSA中。此外，将为每个接口生成链路LSA。这样，所有接口都将包含在OSPF的路由计算中。
o Any link-local scope LSAs that are originated for a Standby Interface will be flooded over the Active Interface. If a Standby Interface goes down, then the link-local scope LSAs originated for the Standby Interfaces MUST be flushed on the Active Interface.
o 为备用接口发起的任何链路本地作用域LSA都将淹没在活动接口上。如果备用接口关闭，则必须在活动接口上刷新为备用接口发起的链路本地作用域LSA。
o Prefixes on Standby Interfaces will be processed the same way as prefixes on the Active Interface. For example, if the router is the DR for the link, the Active Interface's prefixes are included
o 备用接口上的前缀处理方式与活动接口上的前缀处理方式相同。例如，如果路由器是链路的DR，则包含活动接口的前缀
in an intra-area-prefix-LSA which is associated with the Active Interface's network-LSA; prefixes from Standby Interfaces on the link will also be included in that intra-area-prefix LSA. Similarly, if the link is a stub link, then the prefixes for the Active and Standby Interfaces will all be included in the same intra-area-prefix-LSA that is associated with the router-LSA.
在与活动接口的网络LSA相关联的区域内前缀LSA中；链路上备用接口的前缀也将包含在该区域内前缀LSA中。类似地，如果链路是存根链路，则主动和备用接口的前缀将全部包括在与路由器LSA相关联的相同区域内前缀LSA中。
o If the Active Interface fails, a new Active Interface will have to take over. The new Active Interface SHOULD form all new neighbor adjacencies with routers on the link. This failure can be detected when the router's other interfaces to the Active Interface's link cease to hear the router's Hellos or through internal mechanisms, e.g., monitoring the Active Interface's status.
o 如果活动接口出现故障，则必须由新的活动接口接管。新的活动接口应与链路上的路由器形成所有新的邻居邻接。当路由器与活动接口的链路的其他接口停止听到路由器的hello时，或通过内部机制（例如，监视活动接口的状态）可以检测到此故障。
o If the network becomes partitioned with different local interfaces attaching to different network partitions, multiple interfaces will become Active Interfaces and function independently.
o 如果网络被分区，不同的本地接口连接到不同的网络分区，则多个接口将成为活动接口并独立运行。
o During the SPF calculation when a network-LSA for a network that is directly connected to the root vertex is being examined, all of the multiple interfaces to the link of adjacent router-LSAs must be used in the next-hop calculation. This can be accomplished during the back link check (see Section 16.1, Step 2 (B), in [OSPFV2]) by examining each link of the router-LSA and making a list of the links that point to the network-LSA. The Interface IDs for links in this list are then used to find the corresponding link-LSAs and the link-local addresses used as next hops when installing equal-cost paths in the routing table.
o 在SPF计算期间，当检查直接连接到根顶点的网络的网络LSA时，必须在下一跳计算中使用到相邻路由器LSA链路的所有多个接口。这可以通过检查路由器LSA的每条链路并列出指向网络LSA的链路列表，在反向链路检查期间完成（参见[OSPFV2]第16.1节步骤2（B））。然后，在路由表中安装等成本路径时，使用此列表中链接的接口ID查找相应的链接LSA和用作下一个跃点的链接本地地址。
o The interface state machine is modified to add the state Standby. See Section 4.9.1 for a description of the Standby state.
o 修改接口状态机以添加Standby状态。有关备用状态的说明，请参见第4.9.1节。
In this state, the interface is one of multiple interfaces to a link and this interface is designated Standby and is not sending or receiving control packets. The interface will continue to receive the Hello packets sent by the Active Interface. The interface will maintain a timer, the Active Interface Timer, with the same interval as the RouterDeadInterval. This timer will be reset whenever an OSPF Hello packet is received from the Active Interface to the link.
在此状态下，该接口是链接的多个接口之一，该接口被指定为备用接口，不发送或接收控制数据包。接口将继续接收活动接口发送的Hello数据包。接口将维护一个计时器，即活动接口计时器，其间隔与RouterDeadInterval相同。每当从链路的活动接口接收到OSPF Hello数据包时，该计时器将被重置。
Two new events are added to the list of events that cause interface state changes: MultipleInterfacesToLink and ActiveInterfaceDead. The descriptions of these events are as follows:
将两个新事件添加到导致接口状态更改的事件列表中：MultipleInterfacesToLink和ActiveInterfaceDead。这些事件的描述如下：
MultipleInterfacesToLink An interfaces on the router has received a Hello packet from another interface on the same router. One of the interfaces is designated as the Active Interface and the other interface is designated as a Standby Interface. The Standby Interface transitions to the Standby state.
MultipleInterfacesToLink路由器上的某个接口已从同一路由器上的另一个接口接收到Hello数据包。其中一个接口指定为活动接口，另一个接口指定为备用接口。待机界面将转换为待机状态。
ActiveInterfaceDead There has been an indication that a Standby Interface is no longer on a link with an Active Interface. The firing of the Active Interface Timer is one indication of this event, as it indicates that the Standby Interface has not received an OSPF Hello packet from the Active Interface for the RouterDeadInterval. Other indications may come from internal notifications, such as the Active Interface being disabled through a configuration change. Any indication internal to the router, such that the router knows the Active Interface is no longer active on the link, can trigger the ActiveInterfaceDead event for a Standby Interface.
ActiveInterfaceDead有迹象表明备用接口不再位于与活动接口的链接上。激活活动接口计时器是此事件的一个指示，因为它指示备用接口尚未从活动接口接收到用于RouterDeadInterval的OSPF Hello数据包。其他指示可能来自内部通知，例如通过配置更改禁用活动接口。路由器内部的任何指示，例如路由器知道链路上的活动接口不再是活动的，都可以触发备用接口的ActiveInterfaceDead事件。
Interface state machine additions include:
接口状态机添加包括：
State(s): Waiting, DR Other, Backup, or DR
状态：等待、灾难恢复其他、备份或灾难恢复
Event: MultipleInterfacesToLink
事件：MultipleInterfacesToLink
New state: Standby
新状态：待机
Action: All interface variables are reset and interface timers disabled. Also, all neighbor connections associated with the interface are destroyed. This is done by generating the event KillNbr on all associated neighbors. The Active Interface Timer is started and the interface will listen for OSPF Hello packets from the link's Active Interface.
措施：重置所有接口变量并禁用接口计时器。此外，与接口关联的所有邻居连接都将被破坏。这是通过在所有关联的邻居上生成事件KillNbr来完成的。活动接口计时器启动，接口将侦听来自链路活动接口的OSPF Hello数据包。
State(s): Standby
国家：待命
Event: ActiveInterfaceDead
事件：ActiveInterfaceDead
New state: Down
新州：关闭
Action: The Active Interface Timer is first disabled. Then the InterfaceUp event is invoked.
措施：首先禁用活动接口计时器。然后调用InterfaceUp事件。
Standby Interface State Machine Additions
备用接口状态机添加
When running over IPv6, OSPFv3 relies on the IP Authentication Header (see [IPAUTH]) and the IP Encapsulating Security Payload (see [IPESP]) to ensure integrity and authentication/confidentiality of protocol packets. This is described in [OSPFV3-AUTH].
在IPv6上运行时，OSPFv3依赖IP身份验证标头（请参见[IPAUTH]）和IP封装安全负载（请参见[IPESP]）来确保协议数据包的完整性和身份验证/机密性。这在[OSPFV3-AUTH]中有描述。
Most OSPFv3 implementations will be running on systems that support multiple protocols with their own independent security assumptions and domains. When IPsec is used to protect OSPFv3 packets, it is important for the implementation to check the IPsec Security Association (SA) and local SA database to ensure the OSPF packet originated from a source that is trusted for OSPFv3. This is required to eliminate the possibility that the packet was authenticated using an SA defined for another protocol running on the same system.
大多数OSPFv3实现将运行在支持多种协议的系统上，这些协议具有各自独立的安全假设和域。当IPsec用于保护OSPFv3数据包时，实施过程中必须检查IPsec安全关联（SA）和本地SA数据库，以确保OSPF数据包来自OSPFv3信任的源。这是为了消除使用为同一系统上运行的另一协议定义的SA对数据包进行身份验证的可能性。
The mechanisms in [OSPFV3-AUTH] do not provide protection against compromised, malfunctioning, or misconfigured routers. Such routers can, either accidentally or deliberately, cause malfunctions affecting the whole routing domain. The reader is encouraged to consult [GENERIC-THREATS] for a more comprehensive description of threats to routing protocols.
[OSPFV3-AUTH]中的机制不提供针对受损、故障或错误配置路由器的保护。这种路由器可能会意外或故意导致影响整个路由域的故障。鼓励读者参考[GENERIC-THREATS]，以更全面地描述路由协议的威胁。
The Management Information Base (MIB) for OSPFv3 is defined in [OSPFV3-MIB].
OSPFv3的管理信息库（MIB）在[OSPFv3-MIB]中定义。
Most OSPF for IPv6 IANA considerations are documented in [OSPF-IANA]. IANA has updated the reference for RFC 2740 to this document.
[OSPF-IANA]中记录了针对IPv6 IANA的大多数OSPF注意事项。IANA已将RFC 2740的参考更新至本文件。
Additionally, this document introduces the following IANA requirements that were not present in [OSPFV3]:
此外，本文件还介绍了[OSPFV3]中没有的下列IANA要求：
o Reserves the options with the values 0x000040 and 0x000080 for migrated OSPFv2 options in the OSPFv3 Options registry defined in [OSPF-IANA]. For information on the OSPFv3 Options field, refer to Appendix A.2.
o 在[OSPF-IANA]中定义的OSPFv3选项注册表中，为迁移的OSPFv2选项保留值为0x000040和0x000080的选项。有关OSPFv3选项字段的信息，请参阅附录A.2。
o Adds the prefix option P-bit with value 0x08 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o 将值为0x08的前缀选项P位添加到[OSPF-IANA]中定义的OSPFv3前缀选项注册表中。有关OSPFv3前缀选项的信息，请参阅附录A.4.1.1。
o Adds the prefix option DN-bit with value 0x10 to the OSPFv3 Prefix Options registry defined in [OSPF-IANA]. For information on OSPFv3 Prefix Options, refer to Appendix A.4.1.1.
o 将值为0x10的前缀选项DN位添加到[OSPF-IANA]中定义的OSPFv3前缀选项注册表中。有关OSPFv3前缀选项的信息，请参阅附录A.4.1.1。
With the deprecation of MOSPF for OSPFv3, the following code points are available for reassignment. Refer to [OSPF-IANA] for information on the respective registries. This document:
随着OSPFv3的MOSPF的弃用，以下代码点可用于重新分配。请参阅[OSPF-IANA]以了解有关各注册中心的信息。本文件：
o Deprecates the MC-bit with value 0x000004 in the OSPFv3 Options registry.
o 在OSPFv3选项注册表中弃用值为0x000004的MC位。
o Deprecates Group-membership-LSA with value 6 in OSPFv3 LSA Function Code registry.
o 在OSPFv3 LSA功能代码注册表中不推荐值为6的组成员身份LSA。
o Deprecates MC-bit with value 0x04 in the OSPFv3 Prefix Options registry.
o 在OSPFv3前缀选项注册表中弃用值为0x04的MC位。
The W-bit in the OSPFv3 Router Properties has also been deprecated. This requires a new registry for OSPFv3 router properties since it will diverge from the OSPFv2 Router Properties.
OSPFv3路由器属性中的W位也已被弃用。这需要一个新的OSPFv3路由器属性注册表，因为它将与OSPFv2路由器属性不同。
Registry Name: OSPFv3 Router Properties Registry Reference: RFC 5340 Registration Procedures: Standards Action
注册表名称：OSPFv3路由器属性注册表参考：RFC 5340注册程序：标准操作
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC 5340
0x02 E-bit RFC 5340
0x04 V-bit RFC 5340
0x08 Deprecated RFC 5340
0x10 Nt-bit RFC 5340
Registry:
Value Description Reference
------ ------------- ---------
0x01 B-bit RFC 5340
0x02 E-bit RFC 5340
0x04 V-bit RFC 5340
0x08 Deprecated RFC 5340
0x10 Nt-bit RFC 5340
OSPFv3 Router Properties Registry
OSPFv3路由器属性注册表
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFC文本是使用Marshall Rose的xml2rfc工具生成的。
The following individuals contributed comments that were incorporated into this document:
以下个人提供了纳入本文件的意见：
o Harold Rabbie for his description of protocol details that needed to be clarified for OSPFv3 NSSA support.
o Harold Rabbie感谢他对OSPFv3 NSSA支持需要澄清的协议细节的描述。
o Nic Neate for his pointing out that there needed to be changes for unknown LSA types handling in the processing of Database Description packets.
o Nic Neate指出，在处理数据库描述数据包时，需要对未知LSA类型的处理进行更改。
o Jacek Kwiatkowski for being the first to point out that the V6- and R-bits are not taken into account in the OSPFv3 intra-area SPF calculation.
o Jacek Kwiatkowski是第一个指出在OSPFv3区域内SPF计算中未考虑V6位和R位的人。
o Michael Barnes recognized that the support for multiple interfaces to a single link was broken (see Section 4.9) and provided the description of the current protocol mechanisms. Abhay Roy reviewed and suggested improvements to the mechanisms.
o Michael Barnes认识到对单个链路的多个接口的支持已经中断（见第4.9节），并提供了当前协议机制的描述。Abhay Roy对这些机制进行了审查并提出了改进建议。
o Alan Davey reviewed and commented on document revisions.
o Alan Davey审查并评论了文件修订。
o Vivek Dubey reviewed and commented on document revisions.
o Vivek Dubey审查并评论了文件修订。
o Manoj Goyal and Vivek Dubey complained enough about link-LSAs being unnecessary to compel introduction of the LinkLSASuppression interface configuration parameter.
o Manoj Goyal和Vivek Dubey对链路LSA没有必要强制引入LinkLSA抑制接口配置参数的抱怨已经够多了。
o Manoj Goyal for pointing out that the next-hop calculation for intra-area-prefix-LSAs corresponding to network vertices was unclear.
o Manoj Goyal指出，对应于网络顶点的区域内前缀LSA的下一跳计算不清楚。
o Ramana Koppula reviewed and commented on document revisions.
o Ramana Koppula审查并评论了文件修订。
o Paul Wells reviewed and commented on document revisions.
o Paul Wells审查并评论了文件修订。
o Amir Khan reviewed and commented on document revisions.
o 阿米尔·汗审查并评论了文件修订。
o Dow Street and Wayne Wheeler commented on the addition of the DN-bit to OSPFv3.
o 陶氏街和韦恩·惠勒对OSPFv3增加DN位发表了评论。
o Mitchell Erblichs provided numerous editorial comments.
o Mitchell Erblichs提供了许多编辑评论。
o Russ White provided numerous editorial comments.
o Russ White提供了大量的编辑评论。
o Kashima Hiroaki provided editorial comments.
o 鹿岛广崎提供了编辑评论。
o Sina Mirtorabi suggested that OSPFv3 should be aligned with OSPFv2 with respect to precedence and should map it to IPv6 traffic class as specified in RFC 2474. Steve Blake helped with the text.
o Sina Mirtorabi建议，OSPFv3应与OSPFv2在优先级方面保持一致，并应将其映射到RFC 2474中指定的IPv6流量类别。史蒂夫·布莱克帮助写了这篇文章。
o Faraz Shamin reviewed a late version of the document and provided editorial comments.
o Faraz Shamin审查了文件的最新版本，并提供了编辑意见。
o Christian Vogt performed the General Area Review Team (Gen-ART) review and provided comments.
o Christian Vogt进行了一般区域审查小组（Gen ART）审查，并提供了意见。
o Dave Ward, Dan Romascanu, Tim Polk, Ron Bonica, Pasi Eronen, and Lars Eggert provided comments during the IESG review. Also, thanks to Pasi for the text in Section 5 relating to routing threats.
o Dave Ward、Dan Romascanu、Tim Polk、Ron Bonica、Pasi Eronen和Lars Eggert在IESG审查期间提供了评论。另外，感谢Pasi在第5节中提供的有关路由威胁的文本。
[DEMAND] Moy, J., "Extending OSPF to Support Demand Circuits", RFC 1793, April 1995.
[需求]Moy，J.，“扩展OSPF以支持需求电路”，RFC 1793，1995年4月。
[DIFF-SERV] Nichols, K., Blake, S., Baker, F., and D. Black, "Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers", RFC 2474, December 1998.
[DIFF-SERV]Nichols，K.，Blake，S.，Baker，F.，和D.Black，“IPv4和IPv6报头中区分服务字段（DS字段）的定义”，RFC 2474，1998年12月。
[DN-BIT] Rosen, E., Peter, 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.
[DN-BIT]Rosen，E.，Peter，P.，和P.Pillay Esnault，“使用链路状态公告（LSA）选项位防止BGP/MPLS IP虚拟专用网络（VPN）中的循环”，RFC 45762006年6月。
[INTFMIB] McCloghrie, K. and F. Kastenholz, "The Interfaces Group MIB", RFC 2863, June 2000.
[INTFMIB]McCloghrie，K.和F.Kastenholz，“接口组MIB”，RFC 28632000年6月。
[IP6ADDR] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
[IP6ADDR]Hinden，R.和S.Deering，“IP版本6寻址体系结构”，RFC 42912006年2月。
[IPAUTH] Kent, S., "IP Authentication Header", RFC 4302, December 2005.
[IPAUTH]Kent，S.，“IP认证头”，RFC 4302，2005年12月。
[IPESP] Kent, S., "IP Encapsulating Security Payload (ESP)", RFC 4303, December 2005.
[IPESP]Kent，S.，“IP封装安全有效载荷（ESP）”，RFC 4303，2005年12月。
[IPV4] Postal, J., "Internet Protocol", STD 5, RFC 791, September 1981.
[IPV4]Postal，J.，“互联网协议”，STD 5，RFC 7911981年9月。
[IPV6] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998.
[IPV6]Deering，S.和R.Hinden，“互联网协议，第6版（IPV6）规范”，RFC 2460，1998年12月。
[NSSA] Murphy, P., "The OSPF Not-So-Stubby Area (NSSA) Option", RFC 3101, January 2003.
[NSSA]Murphy，P.，“OSPF不那么短的区域（NSSA）选项”，RFC3101，2003年1月。
[OSPF-IANA] Kompella, K. and B. Fenner, "IANA Considerations for OSPF", BCP 130, RFC 4940, July 2007.
[OSPF-IANA]Kompella，K.和B.Fenner，“OSPF的IANA考虑”，BCP 130，RFC 4940，2007年7月。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[OSPFV3-AUTH] Gupta, M. and N. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3-AUTH]Gupta，M.和N.Melam，“OSPFV3的认证/保密”，RFC 45522006年6月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[GENERIC-THREATS] Barbir, A., Murphy, S., and Y. Yang, "Generic Threats to Routing Protocols", RFC 4593, October 2006.
[通用威胁]Barbir，A.，Murphy，S.，和Y.Yang，“路由协议的通用威胁”，RFC 4593，2006年10月。
[MOSPF] Moy, J., "Multicast Extensions to OSPF", RFC 1584, March 1994.
[MOSPF]Moy，J.，“OSPF的多播扩展”，RFC1584，1994年3月。
[MTUDISC] Mogul, J. and S. Deering, "Path MTU discovery", RFC 1191, November 1990.
[MTUDISC]Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[OPAQUE] Coltun, R., "The OSPF Opaque LSA Option", RFC 2370, July 1998.
[不透明]Coltun，R.，“OSPF不透明LSA选项”，RFC 23701998年7月。
[OSPFV3] Coltun, R., Ferguson, D., and J. Moy, "OSPF for IPv6", RFC 2740, December 1999.
[OSPFV3]Coltun，R.，Ferguson，D.，和J.Moy，“IPv6的OSPF”，RFC 27401999年12月。
[OSPFV3-MIB] Joyal, D. and V. Manral, "Management Information Base for OSPFv3", Work in Progress, September 2007.
[OSPFV3-MIB]Joyal，D.和V.Manral，“OSPFV3的管理信息库”，正在进行的工作，2007年9月。
[SERV-CLASS] Babiarz, J., Chan, K., and F. Baker, "Configuration Guidelines for DiffServ Service Classes", RFC 4594, August 2006.
[SERV-CLASS]Babiarz，J.，Chan，K.，和F.Baker，“区分服务服务类的配置指南”，RFC 45942006年8月。
This appendix describes the format of OSPF protocol packets and OSPF LSAs. The OSPF protocol runs directly over the IPv6 network layer. Before any data formats are described, the details of the OSPF encapsulation are explained.
本附录描述了OSPF协议包和OSPF LSA的格式。OSPF协议直接在IPv6网络层上运行。在描述任何数据格式之前，将解释OSPF封装的细节。
Next, the OSPF Options field is described. This field describes various capabilities that may or may not be supported by pieces of the OSPF routing domain. The OSPF Options field is contained in OSPF Hello packets, Database Description packets, and OSPF LSAs.
接下来，描述OSPF选项字段。此字段描述OSPF路由域的各个部分可能支持也可能不支持的各种功能。OSPF选项字段包含在OSPF Hello数据包、数据库描述数据包和OSPF LSA中。
OSPF packet formats are detailed in Section A.3.
OSPF数据包格式详见第A.3节。
A description of OSPF LSAs appears in Section A.4. This section describes how IPv6 address prefixes are represented within LSAs, details the standard LSA header, and then provides formats for each of the specific LSA types.
OSPF LSA的说明见第A.4节。本节介绍如何在LSA中表示IPv6地址前缀，详细说明标准LSA标头，然后提供每个特定LSA类型的格式。
OSPF runs directly over the IPv6's network layer. OSPF packets are therefore encapsulated solely by IPv6 and local data-link headers.
OSPF直接在IPv6的网络层上运行。因此，OSPF数据包仅由IPv6和本地数据链路头进行封装。
OSPF does not define a way to fragment its protocol packets, and depends on IPv6 fragmentation when transmitting packets larger than the link MTU. If necessary, the length of OSPF packets can be up to 65,535 bytes. The OSPF packet types that are likely to be large (Database Description, Link State Request, Link State Update, and Link State Acknowledgment packets) can usually be split into multiple protocol packets without loss of functionality. This is recommended; IPv6 fragmentation should be avoided whenever possible. Using this reasoning, an attempt should be made to limit the size of OSPF packets sent over virtual links to 1280 bytes unless Path MTU Discovery is being performed [MTUDISC].
OSPF没有定义对其协议数据包进行分段的方法，并且在传输大于链路MTU的数据包时依赖于IPv6分段。如有必要，OSPF数据包的长度可高达65535字节。可能较大的OSPF数据包类型（数据库描述、链路状态请求、链路状态更新和链路状态确认数据包）通常可以拆分为多个协议数据包，而不会丢失功能。这是建议的；应尽可能避免IPv6碎片。根据此推理，应尝试将通过虚拟链路发送的OSPF数据包的大小限制为1280字节，除非正在执行路径MTU发现[MTUDISC]。
The other important features of OSPF's IPv6 encapsulation are:
OSPF IPv6封装的其他重要功能包括：
o Use of IPv6 multicast. Some OSPF messages are multicast when sent over broadcast networks. Two distinct IP multicast addresses are used. Packets sent to these multicast addresses should never be forwarded; they are meant to travel a single hop only. As such, the multicast addresses have been chosen with link-local scope and packets sent to these addresses should have their IPv6 Hop Limit set to 1. b
o IPv6多播的使用。一些OSPF消息在通过广播网络发送时是多播的。使用两个不同的IP多播地址。发送到这些多播地址的数据包不应该被转发；他们只能跳一步。因此，已使用链路本地作用域选择多播地址，发送到这些地址的数据包的IPv6跃点限制应设置为1。B
AllSPFRouters This multicast address has been assigned the value FF02::5. All routers running OSPF should be prepared to receive packets sent to this address. Hello packets are always sent to this destination. Also, certain OSPF protocol packets are sent to this address during the flooding procedure.
此多播地址的所有SPFROUTERS已分配值FF02:：5。所有运行OSPF的路由器都应该准备好接收发送到此地址的数据包。Hello数据包始终发送到此目的地。此外，在泛洪过程中，某些OSPF协议包被发送到此地址。
AllDRouters This multicast address has been assigned the value FF02::6. Both the Designated Router and Backup Designated Router must be prepared to receive packets destined to this address. Certain OSPF protocol packets are sent to this address during the flooding procedure.
此多播地址已分配值FF02:：6。指定路由器和备份指定路由器都必须准备好接收发送到此地址的数据包。在泛洪过程中，某些OSPF协议数据包被发送到此地址。
o OSPF is IP protocol 89. This number SHOULD be inserted in the Next Header field of the encapsulating IPv6 header.
o OSPF是IP协议89。此编号应插入到封装IPv6标头的下一个标头字段中。
o The OSPFv2 specification (Appendix A.1 in [OSPFV2]) indicates that OSPF protocol packets are sent with IP precedence set to Internetwork Control (B'110') [IPV4]. If routers in the OSPF routing domain map their IPv6 Traffic Class octet to the Differentiated Services Code Point (DSCP) as specified in [DIFF-SERV], then OSPFv3 packets SHOULD be sent with their DSCP set to CS6 (B'110000'), as specified in [SERV-CLASS]. In networks supporting this mapping, OSPF packets will be given precedence over IPv6 data traffic.
o OSPFv2规范（OSPFv2中的附录A.1）指出，发送OSPF协议包时，IP优先级设置为Internetwork Control（B'110'）[IPV4]。如果OSPF路由域中的路由器按照[DIFF-SERV]中的规定将其IPv6通信量等级八位字节映射到区分服务代码点（DSCP），则应按照[SERV-Class]中的规定将其DSCP设置为CS6（B'110000'）发送OSPFv3数据包。在支持这种映射的网络中，OSPF数据包将优先于IPv6数据流量。
The 24-bit OSPF Options field is present in OSPF Hello packets, Database Description packets, and certain LSAs (router-LSAs, network-LSAs, inter-area-router-LSAs, and link-LSAs). 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.
24位OSPF选项字段出现在OSPF Hello数据包、数据库描述数据包和某些LSA（路由器LSA、网络LSA、区域间路由器LSA和链路LSA）中。选项字段使OSPF路由器能够支持（或不支持）可选功能，并将其功能级别与其他OSPF路由器进行通信。通过这种机制，不同功能的路由器可以在OSPF路由域中混合使用。
An option mismatch between routers can cause a variety of behaviors, depending on the particular option. Some option mismatches prevent neighbor relationships from forming (e.g., the E-bit below); these mismatches are discovered through the sending and receiving of Hello packets. Some option mismatches prevent particular LSA types from being flooded across adjacencies; these are discovered through the sending and receiving of Database Description packets. Some option mismatches prevent routers from being included in one or more of the various routing calculations because of their reduced functionality; these mismatches are discovered by examining LSAs.
路由器之间的选项不匹配可能导致多种行为，具体取决于特定的选项。某些选项不匹配会阻止邻居关系的形成（例如，下面的e位）；这些不匹配是通过发送和接收Hello数据包发现的。某些选项不匹配会阻止特定LSA类型在相邻区域被淹没；这些是通过发送和接收数据库描述数据包发现的。一些选项不匹配会阻止路由器被包括在一个或多个不同的路由计算中，因为它们的功能降低了；这些不匹配是通过检查LSA发现的。
Seven bits of the OSPF Options field have been assigned. 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 LSAs. Conversely, routers encountering unrecognized Options bits in received Hello packets, Database Description packets, or LSAs should ignore the unrecognized bits and process the packet or LSA normally.
已分配OSPF选项字段的七位。下面简要描述每个位。在发送Hello数据包或数据库描述数据包以及发起LSA时，路由器应重置（即清除）选项字段中未识别的位。相反，在收到的Hello数据包、数据库描述数据包或LSA中遇到无法识别选项位的路由器应忽略无法识别的位，并正常处理数据包或LSA。
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
| | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
| | | | | | | | | | | | | | | | |*|*|DC|R|N|x| E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+--+
The Options field
选项字段
The Options field
选项字段
V6-bit If this bit is clear, the router/link should be excluded from IPv6 routing calculations. See Section 4.8 for details.
V6位如果清除此位，则应将路由器/链路排除在IPv6路由计算之外。详见第4.8节。
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 [OSPFV2].
E位该位描述了外部LSA被淹没的方式，如[OSPFV2]第3.6、9.5、10.8和12.1.2节所述。
x-Bit This bit was previously used by MOSPF (see [MOSPF]), which has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
x位该位以前由MOSPF使用（参见[MOSPF]），OSPFv3已弃用该位。该位应设置为0，并在接收时忽略。将来可能会重新分配。
N-bit This bit indicates whether or not the router is attached to an NSSA as specified in [NSSA].
N位该位指示路由器是否按照[NSSA]中的规定连接到NSSA。
R-bit This bit (the `Router' bit) indicates whether the originator is an active router. If the router bit is clear, then routes that transit the advertising node cannot be computed. Clearing the router bit would be appropriate for a multi-homed host that wants to participate in routing, but does not want to forward non-locally addressed packets.
R位该位（“路由器”位）表示发起者是否为活动路由器。如果路由器位清除，则无法计算通过广告节点的路由。清除路由器位适用于希望参与路由但不希望转发非本地寻址数据包的多宿主机。
DC-bit This bit describes the router's handling of demand circuits, as specified in [DEMAND].
DC位该位描述路由器对需求电路的处理，如[demand]中所述。
*-bit These bits are reserved for migration of OSPFv2 protocol extensions.
*-位这些位是为迁移OSPFv2协议扩展而保留的。
There are five distinct OSPF packet types. All OSPF packet types begin with a standard 16-byte header. This header is described first. Each packet type is then described in a succeeding section. In these sections, each packet's format is displayed and the packet's component fields are defined.
有五种不同的OSPF数据包类型。所有OSPF数据包类型都以标准的16字节报头开始。首先描述该标题。然后在接下来的一节中描述每种分组类型。在这些部分中，将显示每个数据包的格式，并定义数据包的组件字段。
All OSPF packet types (other than the OSPF Hello packets) deal with lists of LSAs. For example, Link State Update packets implement the flooding of LSAs throughout the OSPF routing domain. The format of LSAs is described in Section A.4.
所有OSPF数据包类型（OSPF Hello数据包除外）都处理LSA列表。例如，链路状态更新包在整个OSPF路由域中实现LSA的泛洪。LSA的格式见第A.4节。
The receive processing of OSPF packets is detailed in Section 4.2.2. The sending of OSPF packets is explained in Section 4.2.1.
OSPF数据包的接收处理详见第4.2.2节。第4.2.1节解释了OSPF数据包的发送。
Every OSPF packet starts with a standard 16-byte header. Together with the encapsulating IPv6 headers, the OSPF header contains all the information necessary to determine whether the packet should be accepted for further processing. This determination is described in Section 4.2.2.
每个OSPF数据包都以一个标准的16字节报头开始。OSPF报头与封装的IPv6报头一起包含确定是否应接受该数据包进行进一步处理所需的所有信息。第4.2.2节描述了该测定。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version # | Type | Packet length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The OSPF Packet Header
OSPF包头
Version # The OSPF version number. This specification documents version 3 of the OSPF protocol.
版本#OSPF版本号。本规范记录了OSPF协议的第3版。
Type The OSPF packet types are as follows. See Appendix A.3.2 through Appendix A.3.6 for details.
类型OSPF数据包类型如下所示。详见附录A.3.2至附录A.3.6。
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Type Description
---------------------------------
1 Hello
2 Database Description
3 Link State Request
4 Link State Update
5 Link State Acknowledgment
Packet length The length of the OSPF protocol packet in bytes. This length includes the standard OSPF header.
数据包长度OSPF协议数据包的长度，以字节为单位。此长度包括标准OSPF标头。
Router ID The Router ID of the packet's source.
路由器ID数据包源的路由器ID。
Area ID A 32-bit number identifying the area to which this packet belongs. All OSPF packets are associated with a single area. Most travel a single hop only. Packets traversing a virtual link are labeled with the backbone Area ID of 0.
区域ID标识此数据包所属区域的32位数字。所有OSPF数据包都与单个区域相关联。大多数旅行只有一个单跳。通过虚拟链路的数据包标记为主干区域ID为0。
Checksum OSPF uses the standard checksum calculation for IPv6 applications: The 16-bit one's complement of the one's complement sum of the entire contents of the packet, starting with the OSPF packet header, and prepending a "pseudo-header" of IPv6 header fields, as specified in Section 8.1 of [IPV6]. The "Upper-Layer Packet Length" in the pseudo-header is set to the value of the OSPF packet header's length field. The Next Header value used in the pseudo-header is 89. If the packet's length is not an integral number of 16-bit words, the packet is padded with a byte of zero before checksumming. Before computing the checksum, the checksum field in the OSPF packet header is set to 0.
校验和OSPF使用IPv6应用程序的标准校验和计算：数据包全部内容的16位1的补码，从OSPF数据包头开始，并在IPv6报头字段的“伪报头”之前，如[IPv6]第8.1节所述。伪报头中的“上层分组长度”设置为OSPF分组报头的长度字段的值。伪报头中使用的下一个报头值是89。如果数据包的长度不是16位字的整数，则在校验和之前用零字节填充数据包。在计算校验和之前，OSPF数据包头中的校验和字段设置为0。
Instance ID Enables multiple instances of OSPF to be run over a single link. Each protocol instance would be assigned a separate Instance ID; the Instance ID has link-local significance only. Received packets whose Instance ID is not equal to the receiving interface's Instance ID are discarded.
实例ID允许在单个链路上运行多个OSPF实例。每个协议实例将被分配一个单独的实例ID；实例ID仅具有链接本地意义。实例ID不等于接收接口实例ID的接收数据包将被丢弃。
0 These fields are reserved. They SHOULD be set to 0 when sending protocol packets and MUST be ignored when receiving protocol packets.
0这些字段是保留的。在发送协议数据包时，它们应设置为0，在接收协议数据包时必须忽略。
Hello packets are OSPF packet type 1. These packets are sent periodically on all interfaces (including virtual links) in order to establish and maintain neighbor relationships. In addition, Hello packets are multicast on those links having a multicast or broadcast capability, enabling dynamic discovery of neighboring routers.
Hello数据包是OSPF数据包类型1。这些数据包在所有接口（包括虚拟链路）上定期发送，以便建立和维护邻居关系。此外，Hello数据包在具有多播或广播功能的链路上进行多播，从而能够动态发现相邻路由器。
All routers connected to a common link must agree on certain parameters (HelloInterval and RouterDeadInterval). These parameters are included in Hello packets allowing differences to inhibit the forming of neighbor relationships. The Hello packet also contains fields used in Designated Router election (Designated Router ID and Backup Designated Router ID), and fields used to detect bidirectional communication (the Router IDs of all neighbors whose Hellos have been recently received).
连接到公共链路的所有路由器必须在某些参数（HelloInterval和RouterDeadInterval）上达成一致。这些参数包含在Hello数据包中，允许差异抑制邻居关系的形成。Hello数据包还包含指定路由器选择中使用的字段（指定路由器ID和备份指定路由器ID），以及用于检测双向通信的字段（最近收到Hello的所有邻居的路由器ID）。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 1 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| HelloInterval | RouterDeadInterval |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Backup Designated Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Hello Packet
OSPF Hello数据包
Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB]).
接口ID 32位数字，在路由器接口集合中唯一标识此接口。例如，在某些实现中，可以使用MIB-II IfIndex（[INTFMIB]）。
Rtr Priority This router's Router Priority. Used in (Backup) Designated Router election. If set to 0, the router will be ineligible to become (Backup) Designated Router.
Rtr优先级此路由器的路由器优先级。用于（备份）指定路由器选择。如果设置为0，路由器将没有资格成为（备份）指定路由器。
Options The optional capabilities supported by the router, as documented in Section A.2.
选项路由器支持的可选功能，如第A.2节所述。
HelloInterval The number of seconds between this router's Hello packets.
HelloInterval此路由器的Hello数据包之间的秒数。
RouterDeadInterval The number of seconds before declaring a silent router down.
RouterReadInterval声明静默路由器关闭前的秒数。
Designated Router ID The sending router's view of the identity of the Designated Router for this network. The Designated Router is identified by its Router ID. It is set to 0.0.0.0 if there is no Designated Router.
指定路由器ID发送路由器对此网络的指定路由器的标识的视图。指定的路由器由其路由器ID标识。如果没有指定的路由器，则将其设置为0.0.0.0。
Backup Designated Router ID The sending router's view of the identity of the Backup Designated Router for this network. The Backup Designated Router is identified by its IP Router ID. It is set to 0.0.0.0 if there is no Backup Designated Router.
备份指定路由器ID发送路由器对此网络的备份指定路由器标识的视图。备份指定路由器由其IP路由器ID标识。如果没有备份指定路由器，则将其设置为0.0.0.0。
Neighbor ID The Router IDs of each router on the network with neighbor state 1-Way or greater.
邻居ID邻居状态为1路或更大的网络上每个路由器的路由器ID。
Database Description packets are OSPF packet type 2. These packets are exchanged when an adjacency is being initialized. They describe the contents of the link-state database. Multiple packets may be used to describe the database. For this purpose, a poll-response procedure is used. One of the routers is designated to be the master and the other is the slave. The master sends Database Description packets (polls) that are acknowledged by Database Description packets sent by the slave (responses). The responses are linked to the polls via the packets' DD sequence numbers.
数据库描述数据包为OSPF数据包类型2。当邻接被初始化时，这些数据包被交换。它们描述链接状态数据库的内容。可以使用多个数据包来描述数据库。为此，使用轮询响应程序。其中一个路由器被指定为主路由器，另一个路由器被指定为从路由器。主服务器发送由从服务器发送的数据库描述数据包（响应）确认的数据库描述数据包（轮询）。响应通过数据包的DD序列号链接到轮询。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 3 | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 3 | 2 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| Interface MTU | 0 |0|0|0|0|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| DD sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+
| ... |
The OSPF Database Description Packet
OSPF数据库描述包
The format of the Database Description packet is very similar to both the Link State Request packet and the Link State Acknowledgment packet. The main part of all three is a list of items, each item describing a piece of the link-state database. The sending of Database Description packets is documented in Section 10.8 of [OSPFV2]. The reception of Database Description packets is documented in Section 10.6 of [OSPFV2].
数据库描述数据包的格式与链路状态请求数据包和链路状态确认数据包非常相似。这三个项目的主要部分是一个项目列表，每个项目描述链接状态数据库的一部分。[OSPFV2]第10.8节记录了数据库描述数据包的发送。[OSPFV2]第10.6节记录了数据库描述数据包的接收情况。
Options The optional capabilities supported by the router, as documented in Section A.2.
选项路由器支持的可选功能，如第A.2节所述。
Interface MTU The size in bytes of the largest IPv6 datagram that can be sent out the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC].
Interface MTU最大IPv6数据报的大小（字节），可在没有碎片的情况下发送到相关接口。常见互联网链接类型的MTU可在[MTUDISC]的表7-1中找到。
Interface MTU should be set to 0 in Database Description packets sent over virtual links.
在通过虚拟链接发送的数据库描述数据包中，接口MTU应设置为0。
I-bit The Init bit. When set to 1, this packet is the first in the sequence of Database Description packets.
我一点一点的。当设置为1时，此数据包是数据库描述数据包序列中的第一个数据包。
M-bit The More bit. When set to 1, it indicates that more Database Description packets are to follow.
M-一点一点。当设置为1时，表示将遵循更多的数据库描述数据包。
MS-bit The Master/Slave bit. When set to 1, it indicates that the router is the master during the Database Exchange process. Otherwise, the router is the slave.
MS位为主/从位。当设置为1时，表示在数据库交换过程中路由器是主路由器。否则，路由器就是从机。
DD sequence number Used to sequence the collection of Database Description packets. The initial value (indicated by the Init bit being set) should be unique. The DD sequence number then increments until the complete database for both the master and slave routers have been exchanged.
用于对数据库描述数据包集合进行排序的DD序列号。初始值（由设置的初始位指示）应该是唯一的。然后，DD序列号递增，直到主路由器和从路由器的完整数据库都已交换。
The rest of the packet consists of a (possibly partial) list of the link-state database's pieces. Each LSA in the database is described by its LSA header. The LSA header is documented in Appendix A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
数据包的其余部分由链路状态数据库片段的（可能是部分）列表组成。数据库中的每个LSA都由其LSA头描述。LSA标题记录在附录A.4.2中。它包含唯一标识LSA和LSA当前实例所需的所有信息。
Link State Request packets are OSPF packet type 3. After exchanging Database Description packets with a neighboring router, a router may find that parts of its link-state database are out-of-date. The Link State Request packet is used to request the pieces of the neighbor's database that are more up-to-date. Multiple Link State Request packets may need to be used.
链路状态请求数据包为OSPF数据包类型3。在与相邻路由器交换数据库描述数据包后，路由器可能会发现其链路状态数据库的某些部分已过时。链路状态请求数据包用于请求邻居数据库中更新的数据块。可能需要使用多个链路状态请求数据包。
A router that sends a Link State Request packet has in mind the precise instance of the database pieces it is requesting. Each instance is defined by its LS sequence number, LS checksum, and LS age, although these fields are not specified in the Link State Request packet itself. The router may receive even more recent LSA instances in response.
发送链路状态请求数据包的路由器会记住它所请求的数据库片段的精确实例。每个实例由其LS序列号、LS校验和和和LS年龄定义，尽管这些字段未在链路状态请求数据包本身中指定。路由器可以接收甚至更多最近的LSA实例作为响应。
The sending of Link State Request packets is documented in Section 10.9 of [OSPFV2]. The reception of Link State Request packets is documented in Section 10.7 of [OSPFV2].
[OSPFV2]第10.9节记录了链路状态请求数据包的发送。[OSPFV2]第10.7节记录了链路状态请求数据包的接收情况。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 3 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Request Packet
OSPF链路状态请求包
Each LSA requested is specified by its LS type, Link State ID, and Advertising Router. This uniquely identifies the LSA without specifying its instance. Link State Request packets are understood to be requests for the most recent instance of the specified LSAs.
请求的每个LSA由其LS类型、链路状态ID和播发路由器指定。这将唯一标识LSA，而不指定其实例。链路状态请求包被理解为对指定lsa的最新实例的请求。
Link State Update packets are OSPF packet type 4. These packets implement the flooding of LSAs. Each Link State Update packet carries a collection of LSAs one hop further from their origin. Several LSAs may be included in a single packet.
链路状态更新数据包为OSPF数据包类型4。这些数据包实现LSA的泛洪。每个链路状态更新数据包携带一个LSA集合，该集合距离其源站更远一跳。在单个分组中可以包括多个lsa。
Link State Update packets are multicast on those physical networks that support multicast/broadcast. In order to make the flooding procedure reliable, flooded LSAs are acknowledged in Link State Acknowledgment packets. If retransmission of certain LSAs is necessary, the retransmitted LSAs are always carried by unicast Link State Update packets. For more information on the reliable flooding of LSAs, consult Section 4.5.
链路状态更新数据包是支持多播/广播的物理网络上的多播。为了使泛洪过程可靠，在链路状态确认包中确认泛洪LSA。如果需要重新传输某些LSA，则重新传输的LSA始终由单播链路状态更新包携带。有关LSA可靠泛洪的更多信息，请参阅第4.5节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 4 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # LSAs |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- +-+
| LSAs |
+- +-+
| ... |
The OSPF Link State Update Packet
OSPF链路状态更新包
# LSAs The number of LSAs included in this update.
#LSA此更新中包含的LSA数。
The body of the Link State Update packet consists of a list of LSAs. Each LSA begins with a common 20-byte header, described in Appendix A.4.2. Detailed formats of the different types of LSAs are described Appendix A.4.
链路状态更新包的主体由LSA列表组成。每个LSA都以附录a.4.2中所述的公共20字节报头开始。不同类型LSA的详细格式见附录A.4。
Link State Acknowledgment packets are OSPF packet type 5. To make the flooding of LSAs reliable, flooded LSAs are explicitly or implicitly acknowledged. Explicit acknowledgment is accomplished through the sending and receiving of Link State Acknowledgment packets. The sending of Link State Acknowledgment packets is documented in Section 13.5 of [OSPFV2]. The reception of Link State Acknowledgment packets is documented in Section 13.7 of [OSPFV2].
链路状态确认数据包为OSPF数据包类型5。为了使LSA的泛洪可靠，显式或隐式地确认泛洪LSA。显式确认是通过发送和接收链路状态确认数据包来完成的。[OSPFV2]第13.5节记录了链路状态确认数据包的发送。[OSPFV2]第13.7节记录了链路状态确认数据包的接收。
Multiple LSAs MAY be acknowledged in a single Link State Acknowledgment packet. Depending on the state of the sending interface and the sender of the corresponding Link State Update packet, a Link State Acknowledgment packet is sent to the multicast address AllSPFRouters, the multicast address AllDRouters, or to a neighbor's unicast address (see Section 13.5 of [OSPFV2] for details).
可以在单个链路状态确认分组中确认多个lsa。根据发送接口的状态和相应链路状态更新数据包的发送方，链路状态确认数据包被发送到多播地址AllsFrouters、多播地址AllDrooters或邻居的单播地址（详见[OSPFV2]第13.5节）。
The format of this packet is similar to that of the Data Description packet. The body of both packets is simply a list of LSA headers.
此数据包的格式与数据描述数据包的格式相似。两个数据包的主体只是一个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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 3 | 5 | Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Area ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Checksum | Instance ID | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- An LSA Header -+
| |
+- -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
The OSPF Link State Acknowledgment Packet
OSPF链路状态确认数据包
Each acknowledged LSA is described by its LSA header. The LSA header is documented in Appendix A.4.2. It contains all the information required to uniquely identify both the LSA and the LSA's current instance.
每个已确认的LSA由其LSA头描述。LSA标题记录在附录A.4.2中。它包含唯一标识LSA和LSA当前实例所需的所有信息。
This document defines eight distinct types of LSAs. Each LSA begins with a standard 20-byte LSA header. This header is explained in Appendix A.4.2. Succeeding sections describe each LSA type individually.
本文档定义了八种不同类型的LSA。每个LSA都以一个标准的20字节LSA头开始。附录A.4.2对该标题进行了解释。接下来的章节分别描述每种LSA类型。
Each LSA describes a piece of the OSPF routing domain. Every router originates a router-LSA. A network-LSA is advertised for each link by its Designated Router. A router's link-local addresses are advertised to its neighbors in link-LSAs. IPv6 prefixes are advertised in intra-area-prefix-LSAs, inter-area-prefix-LSAs, AS-external-LSAs, and NSSA-LSAs. Location of specific routers can be advertised across area boundaries in inter-area-router-LSAs. All LSAs are then flooded throughout the OSPF routing domain. The
每个LSA描述OSPF路由域的一部分。每个路由器产生一个路由器LSA。网络LSA由其指定的路由器为每条链路发布广告。路由器的链路本地地址在链路LSA中通告给它的邻居。IPv6前缀在区域内前缀LSA、区域间前缀LSA、外部LSA和NSSA LSA中公布。特定路由器的位置可以在区域间路由器LSA中跨区域边界公布。然后，所有LSA在整个OSPF路由域中被淹没。这个
flooding algorithm is reliable, ensuring that all routers common to a flooding scope have the same collection of LSAs associated with that flooding scope. (See Section 4.5 for more information concerning the flooding algorithm.) This collection of LSAs is called the link-state database.
泛洪算法是可靠的，确保泛洪作用域的所有公用路由器都具有与该泛洪作用域关联的相同LSA集合。（有关泛洪算法的更多信息，请参见第4.5节。）此LSA集合称为链路状态数据库。
From the link-state database, each router constructs a shortest-path tree with itself as root. This yields a routing table (see Section 11 of [OSPFV2]). For details on the routing table build process, see Section 4.8.
从链路状态数据库中，每个路由器构建一个以自身为根的最短路径树。这就产生了一个路由表（见[OSPFV2]第11节）。有关路由表生成过程的详细信息，请参阅第4.8节。
IPv6 addresses are bit strings of length 128. IPv6 routing protocols, and OSPF for IPv6 in particular, advertise IPv6 address prefixes. IPv6 address prefixes are bit strings whose length ranges between 0 and 128 bits (inclusive).
IPv6地址是长度为128的位字符串。IPv6路由协议，特别是用于IPv6的OSPF，公布IPv6地址前缀。IPv6地址前缀是长度范围在0到128位（含）之间的位字符串。
Within OSPF, IPv6 address prefixes are always represented by a combination of three fields: PrefixLength, PrefixOptions, and Address Prefix. PrefixLength is the length in bits of the prefix. PrefixOptions is an 8-bit field describing various capabilities associated with the prefix (see Appendix A.4.1.1). Address Prefix is an encoding of the prefix itself as an even multiple of 32-bit words, padding with zero bits as necessary. This encoding consumes ((PrefixLength + 31) / 32) 32-bit words.
在OSPF中，IPv6地址前缀始终由三个字段的组合表示：前缀长度、前缀选项和地址前缀。PrefixLength是前缀的长度（以位为单位）。PrefixOptions是一个8位字段，描述与前缀相关的各种功能（见附录A.4.1.1）。地址前缀是将前缀本身编码为32位字的偶数倍，根据需要填充零位。此编码使用（（前缀长度+31）/32）32位字。
The default route is represented by a prefix of length 0.
默认路由由长度为0的前缀表示。
Examples of IPv6 Prefix representation in OSPF can be found in Appendix A.4.5, Appendix A.4.7, Appendix A.4.8, Appendix A.4.9, and Appendix A.4.10.
OSPF中IPv6前缀表示的示例见附录A.4.5、附录A.4.7、附录A.4.8、附录A.4.9和附录A.4.10。
Each prefix is advertised along with an 8-bit field of capabilities. These serve as input to the various routing calculations. For example, they can indicate that prefixes are to be ignored in some cases or are to be marked as not readvertisable in others.
每个前缀与8位功能字段一起发布。这些作为各种布线计算的输入。例如，它们可以指示前缀在某些情况下被忽略，或者在其他情况下被标记为不可读。
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
0 1 2 3 4 5 6 7
+--+--+--+--+--+-+--+--+
| | | |DN| P|x|LA|NU|
+--+--+--+--+--+-+--+--+
The PrefixOptions Field
PrefixOptions字段
NU-bit The "no unicast" capability bit. If set, the prefix should be excluded from IPv6 unicast calculations. If not set, it should be included.
NU位为“无单播”功能位。如果已设置，则应将前缀从IPv6单播计算中排除。如果未设置，则应将其包括在内。
LA-bit The "local address" capability bit. If set, the prefix is actually an IPv6 interface address of the Advertising Router. Advertisement of local interface addresses is described in Section 4.4.3.9. An implementation MAY also set the LA-bit for prefixes advertised with a host PrefixLength (128).
LA位为“本地地址”功能位。如果设置，前缀实际上是广告路由器的IPv6接口地址。第4.4.3.9节描述了本地接口地址的公布。一种实现还可以为以主机前缀长度（128）播发的前缀设置LA位。
x-bit This bit was previously defined as a "multicast" capability bit. However, the use was never adequately specified and has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
x位该位先前定义为“多播”功能位。然而，OSPFv3的使用从未得到充分规定，因此已被弃用。该位应设置为0，并在接收时忽略。将来可能会重新分配。
P-bit The "propagate" bit. Set on NSSA area prefixes that should be readvertised by the translating NSSA area border [NSSA].
P位“传播”位。设置NSSA区域前缀，该前缀应由NSSA区域边界[NSSA]读取。
DN-bit This bit controls an inter-area-prefix-LSAs or AS-external-LSAs re-advertisement in a VPN environment as specified in [DN-BIT].
DN位此位控制[DN-bit]中指定的VPN环境中的区域间前缀LSA或外部LSA重新播发。
All LSAs begin with a common 20-byte header. This header contains enough information to uniquely identify the LSA (LS type, Link State ID, and Advertising Router). Multiple instances of the LSA may exist in the routing domain at the same time. It is then necessary to determine which instance is more recent. This is accomplished by examining the LS age, LS sequence number, and LS checksum fields that are also contained in the LSA header.
所有LSA都以一个公共的20字节头开始。此标头包含足够的信息来唯一标识LSA（LS类型、链路状态ID和播发路由器）。LSA的多个实例可能同时存在于路由域中。然后有必要确定哪个实例是最近的。这是通过检查也包含在LSA标头中的LS age、LS序列号和LS校验和字段来实现的。
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 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 | LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The LSA Header
LSA报头
LS Age The time in seconds since the LSA was originated.
LS Age自启动LSA以来的时间（以秒为单位）。
LS Type The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. See Appendix A.4.2.1 for a detailed description of LS type.
LS Type LS Type字段表示LSA执行的功能。LS类型的高阶三位编码LSA的通用属性，而其余部分（称为LSA功能代码）表示LSA的特定功能。LS类型的详细说明见附录A.4.2.1。
Link State ID The originating router's identifier for the LSA. The combination of the Link State ID, LS type, and Advertising Router uniquely identify the LSA in the link-state database.
链路状态标识LSA的原始路由器标识符。链路状态ID、LS类型和播发路由器的组合唯一地标识链路状态数据库中的LSA。
Advertising Router The Router ID of the router that originated the LSA. For example, in network-LSAs this field is equal to the Router ID of the network's Designated Router.
广告路由器发起LSA的路由器的路由器ID。例如，在网络LSAs中，此字段等于网络指定路由器的路由器ID。
LS sequence number Successive instances of an LSA are given successive LS sequence numbers. The sequence number can be used to detect old or duplicate LSA instances. See Section 12.1.6 in [OSPFV2] for more details.
LS序列号LSA的连续实例被赋予连续的LS序列号。序列号可用于检测旧的或重复的LSA实例。更多详情请参见[OSPFV2]中的第12.1.6节。
LS checksum The Fletcher checksum of the complete contents of the LSA, including the LSA header but excluding the LS age field. See Section 12.1.7 in [OSPFV2] for more details.
LS校验和LSA完整内容的Fletcher校验和，包括LSA标头，但不包括LS age字段。有关更多详细信息，请参见[OSPFV2]中的第12.1.7节。
length The length in bytes of the LSA. This includes the 20-byte LSA header.
长度LSA的长度（以字节为单位）。这包括20字节的LSA报头。
The LS type field indicates the function performed by the LSA. The high-order three bits of LS type encode generic properties of the LSA, while the remainder (called LSA function code) indicate the LSA's specific functionality. The format of the LS type is as follows:
LS类型字段表示LSA执行的功能。LS类型的高阶三位编码LSA的通用属性，而其余部分（称为LSA功能代码）表示LSA的特定功能。LS类型的格式如下所示：
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
|U |S2|S1| LSA Function Code |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
LSA Type
LSA型
The U-bit indicates how the LSA should be handled by a router that 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 the type is 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 the type is understood
U-Bit
U形位
The S1 and S2 bits indicate the flooding scope of the LSA. The values are:
S1和S2位表示LSA的泛洪范围。这些数值是：
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
S2 S1 Flooding Scope
-------------------------------------------------------------
0 0 Link-Local Scoping - Flooded only on originating link
0 1 Area Scoping - Flooded only in originating area
1 0 AS Scoping - Flooded throughout AS
1 1 Reserved
Flooding Scope
泛洪范围
The LSA function codes are defined as follows. The origination and processing of these LSA function codes are defined elsewhere in this document, except for the NSSA-LSA (see [NSSA]) and 0x2006, which was previously used by MOSPF (see [MOSPF]). MOSPF has been deprecated for OSPFv3. As shown below, each LSA function b code also implies a specific setting for the U, S1, and S2 bits.
LSA功能代码定义如下。除NSSA-LSA（见[NSSA]）和0x2006外，这些LSA功能代码的起源和处理在本文件的其他地方进行了定义，之前由MOSPF使用（见[MOSPF]）。MOSPF已不推荐用于OSPFv3。如下所示，每个LSA功能b代码还表示U、S1和S2位的特定设置。
LSA Function Code LS Type Description
----------------------------------------------------
1 0x2001 Router-LSA
2 0x2002 Network-LSA
3 0x2003 Inter-Area-Prefix-LSA
4 0x2004 Inter-Area-Router-LSA
5 0x4005 AS-External-LSA
6 0x2006 Deprecated (may be reassigned)
7 0x2007 NSSA-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-LSA
LSA Function Code LS Type Description
----------------------------------------------------
1 0x2001 Router-LSA
2 0x2002 Network-LSA
3 0x2003 Inter-Area-Prefix-LSA
4 0x2004 Inter-Area-Router-LSA
5 0x4005 AS-External-LSA
6 0x2006 Deprecated (may be reassigned)
7 0x2007 NSSA-LSA
8 0x0008 Link-LSA
9 0x2009 Intra-Area-Prefix-LSA
LSA Function Code
LSA功能代码
Router-LSAs have LS type equal to 0x2001. Each router in an area originates one or more router-LSAs. The complete collection of router-LSAs originated by the router describe the state and cost of the router's interfaces to the area. For details concerning the construction of router-LSAs, see Section 4.4.3.2. Router-LSAs are only flooded throughout a single area.
路由器LSA的LS类型等于0x2001。一个区域中的每个路由器发起一个或多个路由器LSA。由路由器发起的路由器LSA的完整集合描述了路由器与该区域接口的状态和成本。有关路由器LSA构造的详细信息，请参见第4.4.3.2节。路由器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 |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 |0|0|1| 1 |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 |Nt|x|V|E|B| Options |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | 0 | Metric |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Interface ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Neighbor Router ID |
+-+-+-+--+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Router-LSA Format
路由器LSA格式
A single router may originate one or more router-LSAs, distinguished by their Link State IDs (which are chosen arbitrarily by the originating router). The Options field and V, E, and B bits should be the same in all router-LSAs from a single originator. However, in the case of a mismatch, the values in the LSA with the lowest Link State ID take precedence. When more than one router-LSA is received from a single router, the links are processed as if concatenated into a single LSA.
单个路由器可以发起一个或多个路由器lsa，通过它们的链路状态id（由发起路由器任意选择）进行区分。选项字段和V、E和B位在来自单个发起者的所有路由器LSA中应相同。然而，在不匹配的情况下，具有最低链路状态ID的LSA中的值优先。当从单个路由器接收到多个路由器LSA时，链路被处理为好像连接到单个LSA一样。
Bit V When set, the router is an endpoint of one or more fully adjacent virtual links having the described area as transit area (V is for virtual link endpoint).
位V设置时，路由器是一个或多个完全相邻的虚拟链路的端点，该虚拟链路具有所述区域作为传输区域（V表示虚拟链路端点）。
Bit E When set, the router is an AS boundary router (E is for external).
位E设置后，路由器为AS边界路由器（E为外部路由器）。
Bit B When set, the router is an area border router (B is for border).
位B设置后，路由器为区域边界路由器（B表示边界）。
Bit x This bit was previously used by MOSPF (see [MOSPF]) and has been deprecated for OSPFv3. The bit should be set to 0 and ignored when received. It may be reassigned in the future.
位x该位以前由MOSPF使用（参见[MOSPF]），现在已不推荐用于OSPFv3。该位应设置为0，并在接收时忽略。将来可能会重新分配。
Bit Nt When set, the router is an NSSA border router that is unconditionally translating NSSA-LSAs into AS-external-LSAs (Nt stands for NSSA translation). Note that such routers have their NSSATranslatorRole area configuration parameter set to Always. (See [NSSA].)
位Nt设置后，路由器为NSSA边界路由器，无条件地将NSSA LSA转换为外部LSA（Nt代表NSSA转换）。请注意，此类路由器的NSSATranslatorRole区域配置参数设置为“始终”。（见[NSSA]。）
Options The optional capabilities supported by the router, as documented in Appendix A.2.
选项路由器支持的可选功能，如附录A.2所述。
The following fields are used to describe each router interface. The Type field indicates the kind of interface being described. It may be an interface to a transit network, a point-to-point connection to another router, or a virtual link. The values of all the other fields describing a router interface depend on the interface's Type field.
以下字段用于描述每个路由器接口。类型字段表示所描述的接口类型。它可能是到传输网络的接口、到另一路由器的点对点连接或虚拟链路。描述路由器接口的所有其他字段的值取决于接口的类型字段。
Type The kind of interface being described. One of the following:
键入要描述的接口类型。以下其中一项：
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
Type Description
---------------------------------------------------
1 Point-to-point connection to another router
2 Connection to a transit network
3 Reserved
4 Virtual link
Router Link Types
路由器链路类型
Metric The cost of using this router interface for outbound traffic.
度量使用此路由器接口进行出站通信的成本。
Interface ID The Interface ID assigned to the interface being described. See Section 4.1.2 and Appendix C.3.
接口ID分配给所描述接口的接口ID。见第4.1.2节和附录C.3。
Neighbor Interface ID The Interface ID the neighbor router has associated with the link, as advertised in the neighbor's Hello packets. For transit (type 2) links, the link's Designated Router is the neighbor described. For other link types, the sole adjacent neighbor is described.
邻居接口ID邻居路由器与链路关联的接口ID，如邻居的Hello数据包中公布的。对于传输（类型2）链路，链路的指定路由器是所述的邻居。对于其他链路类型，描述了唯一的相邻邻居。
Neighbor Router ID The Router ID the of the neighbor router. For transit (type 2) links, the link's Designated Router is the neighbor described. For other link types, the sole adjacent neighbor is described.
邻居路由器ID邻居路由器的路由器ID。对于传输（类型2）链路，链路的指定路由器是所述的邻居。对于其他链路类型，描述了唯一的相邻邻居。
For transit (Type 2) links, the combination of Neighbor Interface ID and Neighbor Router ID allows the network-LSA for the attached link to be found in the link-state database.
对于传输（类型2）链路，邻居接口ID和邻居路由器ID的组合允许在链路状态数据库中找到连接链路的网络LSA。
Network-LSAs have LS type equal to 0x2002. A network-LSA is originated for each broadcast and NBMA link in the area that includes two or more adjacent routers. The network-LSA is originated by the link's Designated Router. The LSA describes all routers attached to the link including the Designated Router itself. The LSA's Link State ID field is set to the Interface ID that the Designated Router has been advertising in Hello packets on the link.
网络LSA的LS类型等于0x2002。网络LSA针对包括两个或多个相邻路由器的区域中的每个广播和NBMA链路发起。网络LSA由链路的指定路由器发起。LSA描述连接到链路的所有路由器，包括指定的路由器本身。LSA的链路状态ID字段设置为指定路由器在链路上的Hello数据包中公布的接口ID。
The distance from the network to all attached routers is zero. This is why the Metric fields need not be specified in the network-LSA. For details concerning the construction of network-LSAs, see Section 4.4.3.3.
从网络到所有连接的路由器的距离为零。这就是为什么不需要在网络LSA中指定度量字段。有关网络LSA建设的详细信息，请参见第4.4.3.3节。
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 |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
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 |0|0|1| 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Attached Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
Network-LSA Format
网络LSA格式
Attached Router The Router IDs of each of the routers attached to the link. Actually, only those routers that are fully adjacent to the Designated Router are listed. The Designated Router includes itself in this list. The number of routers included can be deduced from the LSA header's length field.
连接的路由器连接到链路的每个路由器的路由器ID。实际上，仅列出与指定路由器完全相邻的路由器。指定的路由器将自身包含在此列表中。包含的路由器数量可以从LSA报头的长度字段中推断出来。
Inter-area-prefix-LSAs have LS type equal to 0x2003. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 3 summary-LSAs (see Section 12.4.3 of [OSPFV2]). Originated by area border routers, they describe routes to IPv6 address prefixes that belong to other areas. A separate inter-area-prefix-LSA is originated for each IPv6 address prefix. For details concerning the construction of inter-area-prefix-LSAs, see Section 4.4.3.4.
区域间前缀LSA的LS类型等于0x2003。这些LSA是IPv4第3类概要LSA的IPv6等效OSPF（见[OSPFV2]第12.4.3节）。由区域边界路由器发起，它们描述到属于其他区域的IPv6地址前缀的路由。为每个IPv6地址前缀生成单独的区域间前缀LSA。有关区域间前缀LSA构造的详细信息，请参见第4.4.3.4节。
For stub areas, inter-area-prefix-LSAs can also be used to describe a (per-area) default route. Default summary routes are used in stub areas instead of flooding a complete set of external routes. When describing a default summary route, the inter-area-prefix-LSA's PrefixLength is set to 0.
对于存根区域，区域间前缀LSA也可用于描述（每个区域）的默认路由。默认摘要路由用于存根区域，而不是淹没一整套外部路由。描述默认摘要路由时，区域间前缀LSA的PrefixLength设置为0。
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 |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|1| 3 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Prefix-LSA Format
区域间前缀LSA格式
Metric The cost of this route. Expressed in the same units as the interface costs in router-LSAs. When the inter-area-prefix-LSA is describing a route to a range of addresses (see Appendix C.2), the cost is set to the maximum cost to any reachable component of the address range.
衡量这条路线的成本。以与路由器LSA中的接口成本相同的单位表示。当区域间前缀LSA描述到地址范围的路由时（见附录C.2），成本设置为地址范围任何可到达组件的最大成本。
PrefixLength, PrefixOptions, and Address Prefix Representation of the IPv6 address prefix, as described in Appendix A.4.1.
IPv6地址前缀的前缀长度、前缀选项和地址前缀表示，如附录A.4.1所述。
Inter-area-router-LSAs have LS type equal to 0x2004. These LSAs are the IPv6 equivalent of OSPF for IPv4's type 4 summary-LSAs (see Section 12.4.3 of [OSPFV2]). Originated by area border routers, they describe routes to AS boundary routers in other areas. To see why it is necessary to advertise the location of each ASBR, consult Section 16.4 in [OSPFV2]. Each LSA describes a route to a single router. For details concerning the construction of inter-area-router-LSAs, see Section 4.4.3.5.
区域间路由器LSA的LS类型等于0x2004。这些LSA是IPv4第4类概要LSA的IPv6等效OSPF（见[OSPFV2]第12.4.3节）。源于区域边界路由器，它们将到的路由描述为其他区域的边界路由器。要了解为什么有必要公布每个ASBR的位置，请参阅[OSPFV2]中的第16.4节。每个LSA描述到单个路由器的路由。有关区域间路由器LSA构造的详细信息，请参见第4.4.3.5节。
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 |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|1| 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Router ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Inter-Area-Router-LSA Format
区域间路由器LSA格式
Options The optional capabilities supported by the router, as documented in Appendix A.2.
选项路由器支持的可选功能，如附录A.2所述。
Metric The cost of this route. Expressed in the same units as the interface costs in router-LSAs.
衡量这条路线的成本。以与路由器LSA中的接口成本相同的单位表示。
Destination Router ID The Router ID of the router being described by the LSA.
目标路由器ID LSA描述的路由器的路由器ID。
AS-external-LSAs have LS type equal to 0x4005. These LSAs are originated by AS boundary routers and describe destinations external to the AS. Each LSA describes a route to a single IPv6 address prefix. For details concerning the construction of AS-external-LSAs, see Section 4.4.3.6.
AS外部LSA的LS类型等于0x4005。这些LSA由AS边界路由器发起，描述AS外部的目的地。每个LSA描述到单个IPv6地址前缀的路由。有关AS外部LSA施工的详细信息，请参见第4.4.3.6节。
AS-external-LSAs can be used to describe a default route. Default routes are used when no specific route exists to the destination. When describing a default route, the AS-external-LSA's PrefixLength is set to 0.
AS外部LSA可用于描述默认路由。当不存在到目的地的特定路线时，使用默认路线。描述默认路由时，AS外部LSA的前缀长度设置为0。
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 |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|1|0| 5 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |E|F|T| Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Forwarding Address (Optional) -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| External Route Tag (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID (Optional) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
AS-external-LSA Format
作为外部LSA格式
bit E The type of external metric. If bit E is set, the metric specified is a Type 2 external metric. This means the metric is considered larger than any intra-AS path. If bit E is zero, the specified metric is a Type 1 external metric. This means that it is expressed in the same units as other LSAs (i.e., the same units as the interface costs in router-LSAs).
位E表示外部度量的类型。如果设置了位E，则指定的度量是类型2外部度量。这意味着度量被认为比任何内部AS路径都大。如果位E为零，则指定的度量是类型1外部度量。这意味着它以与其他LSA相同的单位表示（即，与路由器LSA中的接口成本相同的单位）。
bit F If set, a Forwarding Address has been included in the LSA.
位F如果设置，则LSA中已包含转发地址。
bit T If set, an External Route Tag has been included in the LSA.
位T如果设置，则LSA中已包含外部路由标签。
Metric The cost of this route. Interpretation depends on the external type indication (bit E above).
衡量这条路线的成本。解释取决于外部类型指示（上面的E位）。
PrefixLength, PrefixOptions, and Address Prefix Representation of the IPv6 address prefix, as described in Appendix A.4.1.
IPv6地址前缀的前缀长度、前缀选项和地址前缀表示，如附录A.4.1所述。
Referenced LS Type If non-zero, an LSA with this LS type is to be associated with this LSA (see Referenced Link State ID below).
引用的LS类型如果非零，则具有此LS类型的LSA将与此LSA关联（请参阅下面的引用链接状态ID）。
Forwarding address A fully qualified IPv6 address (128 bits). Included in the LSA if and only if bit F has been set. If included, data traffic for the advertised destination will be forwarded to this address. It MUST NOT be set to the IPv6 Unspecified Address (0:0:0:0:0:0:0:0) or an IPv6 Link-Local Address (Prefix FE80/10). While OSPFv3 routes are normally installed with link-local addresses, an OSPFv3 implementation advertising a forwarding address MUST advertise a global IPv6 address. This global IPv6 address may be the next-hop gateway for an external prefix or may be obtained through some other method (e.g., configuration).
转发地址完全限定的IPv6地址（128位）。当且仅当已设置位F时才包含在LSA中。如果包含，则播发目的地的数据流量将转发到此地址。不能将其设置为IPv6未指定地址（0:0:0:0:0:0:0）或IPv6链路本地地址（前缀FE80/10）。虽然OSPFv3路由通常安装有链路本地地址，但播发转发地址的OSPFv3实现必须播发全局IPv6地址。该全局IPv6地址可以是外部前缀的下一跳网关，或者可以通过某些其他方法（例如，配置）获得。
External Route Tag A 32-bit field that MAY be used to communicate additional information between AS boundary routers. Included in the LSA if and only if bit T has been set.
外部路由标记一个32位字段，可用于在AS边界路由器之间传递附加信息。当且仅当设置了位T时才包含在LSA中。
Referenced Link State ID Included if and only if Reference LS Type is non-zero. If included, additional information concerning the advertised external route can be found in the LSA having LS type equal to "Referenced LS Type", Link State ID equal to "Referenced Link State ID", and Advertising Router the same as that specified in the AS-external-LSA's link-state header. This additional information is not used by the OSPF protocol itself. It may be used to communicate information between AS boundary routers. The precise nature of such information is outside the scope of this specification.
当且仅当引用LS类型为非零时，才包含引用链接状态ID。如果包括，可以在LSA中找到关于广告外部路由的附加信息，其中LS type等于“参考LS type”，链路状态ID等于“参考链路状态ID”，广告路由器与as外部LSA的链路状态报头中指定的相同。OSPF协议本身不使用此附加信息。它可用于在AS边界路由器之间进行信息通信。此类信息的准确性质不在本规范范围内。
All, none, or some of the fields labeled Forwarding address, External Route Tag, and Referenced Link State ID MAY be present in the AS-external-LSA (as indicated by the setting of bit F, bit T, and Referenced LS Type respectively). When present, Forwarding Address always comes first, External Route Tag next, and the Referenced Link State ID last.
标记为转发地址、外部路由标签和参考链路状态ID的所有、无或部分字段可能存在于AS外部LSA中（分别通过位F、位T和参考LS类型的设置表示）。当存在时，转发地址总是排在第一位，外部路由标签排在第二位，引用的链路状态ID排在最后。
NSSA-LSAs have LS type equal to 0x2007. These LSAs are originated by AS boundary routers within an NSSA and describe destinations external to the AS that may or may not be propagated outside the NSSA (refer to [NSSA]). Other than the LS type, their format is exactly the same as AS-external LSAs as described in Appendix A.4.7.
NSSA LSA的LS类型等于0x2007。这些LSA由NSSA内的AS边界路由器发起，描述AS外部的目的地，这些目的地可能在NSSA外部传播，也可能不在NSSA外部传播（请参阅[NSSA]）。除LS类型外，其格式与附录A.4.7中所述的外部LSA完全相同。
A global IPv6 address MUST be selected as forwarding address for NSSA-LSAs that are to be propagated by NSSA area border routers. The selection should proceed the same as OSPFv2 NSSA support [NSSA] with additional checking to ensure IPv6 link-local address are not selected.
必须选择全局IPv6地址作为NSSA区域边界路由器传播的NSSA LSA的转发地址。选择应与OSPFv2 NSSA支持[NSSA]相同，并进行额外检查，以确保未选择IPv6链路本地地址。
Link-LSAs have LS type equal to 0x0008. A router originates a separate link-LSA for each attached physical link. These LSAs have link-local flooding scope; they are never flooded beyond the associated link. Link-LSAs have three purposes:
链路LSA的LS类型等于0x0008。路由器为每个连接的物理链路创建单独的链路LSA。这些LSA具有局部洪水范围；它们永远不会淹没在相关链接之外。链路LSA有三个用途：
1. They provide the router's link-local address to all other routers attached to the link.
1. 它们将路由器的链路本地地址提供给连接到链路的所有其他路由器。
2. They inform other routers attached to the link of a list of IPv6 prefixes to associate with the link.
2. 它们通知连接到该链路的其他路由器要与该链路关联的IPv6前缀列表。
3. They allow the router to advertise a collection of Options bits in the network-LSA originated by the Designated Router on a broadcast or NBMA link.
3. 它们允许路由器在网络LSA中公布由指定路由器在广播或NBMA链路上发起的选项位集合。
For details concerning the construction of links-LSAs, see Section 4.4.3.8.
有关链路LSA施工的详细信息，请参见第4.4.3.8节。
A link-LSA's Link State ID is set equal to the originating router's Interface ID on the link.
链路LSA的链路状态ID设置为等于链路上发起路由器的接口ID。
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 |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|0| 8 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rtr Priority | Options |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- -+
| |
+- Link-local Interface Address -+
| |
+- -+
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # prefixes |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | 0 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Link-LSA Format
链接LSA格式
Rtr Priority The Router Priority of the interface attaching the originating router to the link.
Rtr优先级将始发路由器连接到链路的接口的路由器优先级。
Options The set of Options bits that the router would like set in the network-LSA that will be originated by the Designated Router on broadcast or NBMA links.
选项路由器希望在网络LSA中设置的一组选项位，由指定路由器在广播或NBMA链路上发起。
Link-local Interface Address The originating router's link-local interface address on the link.
链路本地接口地址链路上发起路由器的链路本地接口地址。
# prefixes The number of IPv6 address prefixes contained in the LSA.
#前缀LSA中包含的IPv6地址前缀数。
The rest of the link-LSA contains a list of IPv6 prefixes to be associated with the link.
链路LSA的其余部分包含要与链路关联的IPv6前缀列表。
PrefixLength, PrefixOptions, and Address Prefix Representation of an IPv6 address prefix, as described in Appendix A.4.1.
IPv6地址前缀的前缀长度、前缀选项和地址前缀表示，如附录A.4.1所述。
Intra-area-prefix-LSAs have LS type equal to 0x2009. A router uses intra-area-prefix-LSAs to advertise one or more IPv6 address prefixes that are associated with a local router address, an attached stub network segment, or an attached transit network segment. In IPv4, the first two were accomplished via the router's router-LSA and the last via a network-LSA. In OSPF for IPv6, all addressing information that was advertised in router-LSAs and network-LSAs has been removed and is now advertised in intra-area-prefix-LSAs. For details concerning the construction of intra-area-prefix-LSA, see Section 4.4.3.9.
区域内前缀LSA的LS类型等于0x2009。路由器使用区域内前缀LSA播发与本地路由器地址、连接的存根网段或连接的传输网段关联的一个或多个IPv6地址前缀。在IPv4中，前两个是通过路由器的路由器LSA完成的，最后一个是通过网络LSA完成的。在用于IPv6的OSPF中，在路由器LSA和网络LSA中播发的所有寻址信息都已删除，现在在区域内前缀LSA中播发。有关区域内前缀LSA构造的详细信息，请参见第4.4.3.9节。
A router can originate multiple intra-area-prefix-LSAs for each router or transit network. Each such LSA is distinguished by its unique Link State ID.
路由器可以为每个路由器或传输网络发起多个区域内前缀LSA。每个这样的LSA通过其唯一的链路状态ID来区分。
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 |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Prefixes | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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 |0|0|1| 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Sequence Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS Checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| # Prefixes | Referenced LS Type |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Referenced Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PrefixLength | PrefixOptions | Metric |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Address Prefix |
| ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Intra-Area-Prefix LSA Format
区域内前缀LSA格式
# prefixes The number of IPv6 address prefixes contained in the LSA.
#前缀LSA中包含的IPv6地址前缀数。
Referenced LS Type, Referenced Link State ID, and Referenced Advertising Router Identifies the router-LSA or network-LSA with which the IPv6 address prefixes should be associated. If Referenced LS Type is 0x2001, the prefixes are associated with a router-LSA, Referenced Link State ID should be 0, and Referenced Advertising Router should be the originating router's Router ID. If Referenced LS Type is 0x2002, the prefixes are associated with a network-LSA, Referenced Link State ID should be the Interface ID of the link's Designated Router, and Referenced Advertising Router should be the Designated Router's Router ID.
引用的LS类型、引用的链路状态ID和引用的播发路由器标识应与IPv6地址前缀关联的路由器LSA或网络LSA。如果引用的LS类型为0x2001，则前缀与路由器LSA关联，引用的链路状态ID应为0，引用的播发路由器应为发起路由器的路由器ID。如果引用的LS类型为0x2002，则前缀与网络LSA关联，引用的链路状态ID应为链路指定路由器的接口ID，引用的广告路由器应为指定路由器的路由器ID。
The rest of the intra-area-prefix-LSA contains a list of IPv6 prefixes to be associated with the router or transit link, as well as their associated costs.
区域内前缀LSA的其余部分包含将与路由器或传输链路相关联的IPv6前缀列表，以及它们的相关成本。
PrefixLength, PrefixOptions, and Address Prefix Representation of an IPv6 address prefix, as described in Appendix A.4.1.
IPv6地址前缀的前缀长度、前缀选项和地址前缀表示，如附录A.4.1所述。
Metric The cost of this prefix. Expressed in the same units as the interface costs in router-LSAs.
度量此前缀的成本。以与路由器LSA中的接口成本相同的单位表示。
Architectural constants for the OSPF protocol are defined in Appendix B of [OSPFV2]. The only difference for OSPF for IPv6 is that DefaultDestination is encoded as a prefix with length 0 (see Appendix A.4.1).
OSPF协议的架构常数在[OSPFV2]的附录B中定义。用于IPv6的OSPF的唯一区别是DefaultDestination编码为长度为0的前缀（见附录a.4.1）。
The OSPF protocol has quite a few configurable parameters. These parameters are listed below. They are grouped into general functional categories (area parameters, interface parameters, etc.). Sample values are given for some of the parameters.
OSPF协议有很多可配置的参数。下面列出了这些参数。它们分为一般功能类别（区域参数、接口参数等）。给出了一些参数的样本值。
Some parameter settings need to be consistent among groups of routers. For example, all routers in an area must agree on that area's parameters. Similarly, all routers attached to a network must agree on that network's HelloInterval and RouterDeadInterval.
某些参数设置需要在路由器组之间保持一致。例如，一个区域内的所有路由器必须就该区域的参数达成一致。同样，连接到网络的所有路由器必须在该网络的HelloInterval和RouterReadInterval上达成一致。
Some parameters may be determined by router algorithms outside of this specification (e.g., the address of a host connected to the router via a SLIP line). From OSPF's point of view, these items are still configurable.
一些参数可由本规范之外的路由器算法确定（例如，通过滑线连接到路由器的主机地址）。从OSPF的角度来看，这些项目仍然是可配置的。
In general, a separate copy of the OSPF protocol is run for each area. Because of this, most configuration parameters are defined on a per-area basis. The few global configuration parameters are listed below.
通常，每个区域都会运行OSPF协议的单独副本。因此，大多数配置参数都是按面积定义的。下面列出了几个全局配置参数。
Router ID This is a 32-bit number that uniquely identifies the router in the Autonomous System. If a router's OSPF Router ID is changed, the router's OSPF software should be restarted before the new Router ID takes effect. Before restarting due to a Router ID change, the router should flush its self-originated LSAs from the routing domain (see Section 14.1 of [OSPFV2]). Otherwise, they will persist for up to MaxAge seconds.
路由器ID这是一个32位的数字，唯一标识自治系统中的路由器。如果路由器的OSPF路由器ID发生更改，则应在新路由器ID生效之前重新启动路由器的OSPF软件。在因路由器ID更改而重新启动之前，路由器应从路由域中刷新其自创LSA（请参阅[OSPFV2]第14.1节）。否则，它们将持续最长达数秒。
Because the size of the Router ID is smaller than an IPv6 address, it cannot be set to one of the router's IPv6 addresses (as is commonly done for IPv4). Possible Router ID assignment procedures for IPv6 include: a) assign the IPv6 Router ID as one of the router's IPv4 addresses or b) assign IPv6 Router IDs through some local administrative procedure (similar to procedures used by manufacturers to assign product serial numbers).
由于路由器ID的大小小于IPv6地址，因此无法将其设置为路由器的IPv6地址之一（IPv4通常是这样）。IPv6可能的路由器ID分配过程包括：a）将IPv6路由器ID分配为路由器的IPv4地址之一，或b）通过一些本地管理过程分配IPv6路由器ID（类似于制造商分配产品序列号的过程）。
The Router ID of 0.0.0.0 is reserved and SHOULD NOT be used.
路由器ID 0.0.0.0是保留的，不应使用。
All routers belonging to an area must agree on that area's configuration. Disagreements between two routers will lead to an inability for adjacencies to form between them, with a resulting hindrance to the flow of both routing protocol information and data traffic. The following items must be configured for an area:
属于某个区域的所有路由器必须同意该区域的配置。两个路由器之间的分歧将导致它们之间无法形成邻接，从而阻碍路由协议信息和数据流量的流动。必须为区域配置以下项目：
Area ID This is a 32-bit number that identifies the area. The Area ID of 0 is reserved for the backbone.
区域ID这是标识区域的32位数字。区域ID 0是为主干保留的。
List of address ranges Address ranges control the advertisement of routes across area boundaries. Each address range consists of the following items:
地址范围列表地址范围控制跨区域边界的路由广告。每个地址范围由以下项目组成：
[IPv6 prefix, prefix length] Describes the collection of IPv6 addresses contained in the address range.
[IPv6前缀，前缀长度]描述地址范围中包含的IPv6地址的集合。
Status Set to either Advertise or DoNotAdvertise. Routing information is condensed at area boundaries. External to the area, at most a single route is advertised (via a inter-area-prefix-LSA) for each address range. The route is advertised if and only if the address range's Status is set to Advertise. Unadvertised ranges allow the existence of certain networks to be intentionally hidden from other areas. Status is set to Advertise by default.
状态设置为播发或不播发。路由信息在区域边界处压缩。在该区域之外，对于每个地址范围，最多只公布一条路由（通过区域间前缀LSA）。当且仅当地址范围的状态设置为播发时，才会播发路由。未经宣传的范围允许故意对其他区域隐藏某些网络的存在。默认情况下，状态设置为播发。
ExternalRoutingCapability Whether AS-external-LSAs will be flooded into/throughout the area. If AS-external-LSAs are excluded from the area, the area is called a stub area or NSSA. Internal to stub areas, routing to external destinations will be based solely on a default inter-area route. The backbone cannot be configured as a stub or NSSA area. Also, virtual links cannot be configured through stub or NSSA areas. For more information, see Section 3.6 of [OSPFV2] and [NSSA].
外部布线能力是否为外部LSA将被淹没到该区域/整个区域。如果外部LSA被排除在该区域之外，则该区域称为存根区域或NSSA。内部到存根区域，到外部目的地的路由将仅基于默认的区域间路由。主干网不能配置为存根或NSSA区域。此外，不能通过存根或NSSA区域配置虚拟链路。有关更多信息，请参见[OSPFV2]和[NSSA]的第3.6节。
StubDefaultCost If the area has been configured as a stub area, and the router itself is an area border router, then the StubDefaultCost indicates the cost of the default inter-area-prefix-LSA that the router should advertise into the area. See Section 12.4.3.1 of [OSPFV2] for more information.
StubDefaultCost如果该区域已配置为存根区域，并且路由器本身是区域边界路由器，则StubDefaultCost表示路由器应向该区域播发的默认区域间前缀LSA的成本。更多信息参见[OSPFV2]第12.4.3.1节。
NSSATranslatorRole and TranslatorStabilityInterval These area parameters are described in Appendix D of [NSSA]. Additionally, an NSSA Area Border Router (ABR) is also required to allow configuration of whether or not an NSSA default route is advertised in an NSSA-LSA. If advertised, its metric and metric type are configurable. These requirements are also described in Appendix D of [NSSA].
NSSA TranslatorRole和TranslatorStabilityInterval这些区域参数在[NSSA]的附录D中描述。此外，还需要NSSA区域边界路由器（ABR）来允许配置NSSA-LSA中是否公布NSSA默认路由。如果公布，其度量和度量类型是可配置的。[NSSA]的附录D中也描述了这些要求。
ImportSummaries When set to enabled, prefixes external to the area are imported into the area via the advertisement of inter-area-prefix-LSAs. When set to disabled, inter-area routes are not imported into the area. The default setting is enabled. This parameter is only valid for stub or NSSA areas.
ImportSummaries设置为enabled时，区域外部的前缀通过区域间前缀LSA的播发导入到区域中。设置为“禁用”时，区域间管线不会导入到区域中。默认设置已启用。此参数仅对存根或NSSA区域有效。
Some of the configurable router interface parameters (such as Area ID, HelloInterval, and RouterDeadInterval) actually imply properties of the attached links. Therefore, these parameters must be consistent across all the routers attached to that link. The parameters that must be configured for a router interface are:
一些可配置的路由器接口参数（如区域ID、HelloInterval和RouterDeadInterval）实际上暗示了连接链路的属性。因此，这些参数必须在连接到该链路的所有路由器上保持一致。必须为路由器接口配置的参数包括：
IPv6 link-local address The IPv6 link-local address associated with this interface. May be learned through auto-configuration.
IPv6链路本地地址与此接口关联的IPv6链路本地地址。可通过自动配置学习。
Area ID The OSPF area to which the attached link belongs.
Area ID连接的链路所属的OSPF区域。
Instance ID The OSPF protocol instance associated with this OSPF interface. Defaults to 0.
实例ID与此OSPF接口关联的OSPF协议实例。默认值为0。
Interface ID 32-bit number uniquely identifying this interface among the collection of this router's interfaces. For example, in some implementations it may be possible to use the MIB-II IfIndex ([INTFMIB]).
接口ID 32位数字，在路由器接口集合中唯一标识此接口。例如，在某些实现中，可以使用MIB-II IfIndex（[INTFMIB]）。
IPv6 prefixes The list of IPv6 prefixes to associate with the link. These will be advertised in intra-area-prefix-LSAs.
IPv6前缀要与链接关联的IPv6前缀列表。这些将在区域内前缀LSA中公布。
Interface output cost(s) The cost of sending a packet on the interface, expressed in the link-state metric. This is advertised as the link cost for this interface in the router's router-LSA. The interface output cost MUST always be greater than 0.
接口输出成本在接口上发送数据包的成本，以链路状态度量表示。这在路由器的路由器LSA中作为该接口的链路成本公布。接口输出成本必须始终大于0。
RxmtInterval The number of seconds between LSA retransmissions for adjacencies belonging to this interface. Also used when retransmitting Database Description and Link State Request packets. This should be well over the expected round-trip delay between any two routers on the attached link. The setting of this value should be conservative or needless retransmissions will result. Sample value for a local area network: 5 seconds.
RxMTINERVAL属于此接口的邻接的LSA重新传输之间的秒数。在重新传输数据库描述和链路状态请求数据包时也使用。这应该远远超过连接链路上任何两个路由器之间的预期往返延迟。此值的设置应保守，否则将导致不必要的重新传输。局域网的样本值：5秒。
InfTransDelay The estimated number of seconds it takes to transmit a Link State Update packet over this interface. LSAs contained in the update packet must have their age incremented by this amount before transmission. This value should take into account the transmission and propagation delays of the interface. It MUST be greater than 0. Sample value for a local area network: 1 second.
InfTransDelay通过此接口传输链路状态更新数据包所需的估计秒数。在传输之前，更新数据包中包含的LSA的年龄必须增加此数量。该值应考虑接口的传输和传播延迟。它必须大于0。局域网的样本值：1秒。
Router Priority An 8-bit unsigned integer. When two routers attached to a network both attempt to become the Designated Router, the one with the highest Router Priority takes precedence. If there is still a tie, the router with the highest Router ID takes precedence. A router whose Router Priority is set to 0 is ineligible to become the Designated Router on the attached link. Router Priority is only configured for interfaces to broadcast and NBMA networks.
路由器优先级为8位无符号整数。当两个连接到网络的路由器都试图成为指定路由器时，具有最高路由器优先级的路由器优先。如果仍然存在平局，则具有最高路由器ID的路由器优先。路由器优先级设置为0的路由器没有资格成为连接链路上的指定路由器。路由器优先级仅为广播和NBMA网络的接口配置。
HelloInterval The length of time, in seconds, between Hello packets that the router sends on the interface. This value is advertised in the router's Hello packets. It MUST be the same for all routers attached to a common link. The smaller the HelloInterval, the faster topological changes will be detected. However, more OSPF routing protocol traffic will ensue. Sample value for a X.25 PDN: 30 seconds. Sample value for a local area network (LAN): 10 seconds.
HelloInterval路由器在接口上发送Hello数据包之间的时间长度，以秒为单位。此值在路由器的Hello数据包中公布。连接到公共链路的所有路由器必须相同。HelloInterval越小，检测到的拓扑变化越快。然而，更多的OSPF路由协议流量将随之增加。X.25 PDN的样本值：30秒。局域网（LAN）的样本值：10秒。
RouterDeadInterval After ceasing to hear a router's Hello packets, the number of seconds before its neighbors declare the router down. This is also advertised in the router's Hello packets in their RouterDeadInterval field. This should be some multiple of the HelloInterval (e.g., 4). This value again MUST be the same for all routers attached to a common link.
RouterReadInterval停止听到路由器的Hello数据包后，其邻居宣布路由器关闭前的秒数。这也会在路由器的Hello数据包的RouterReadInterval字段中公布。这应该是HelloInterval的倍数（例如，4）。对于连接到公共链路的所有路由器，该值也必须相同。
LinkLSASuppression Indicates whether or not origination of a link-LSA is suppressed. If set to "enabled" and the interface type is not broadcast or NBMA, the router will not originate a link-LSA for the link. This implies that other routers on the link will ascertain the router's next-hop address using a mechanism other than the link-LSA (see Section 4.8.2). The default value is "disabled" for interface types described in this specification. It is implicitly "disabled" if the interface type is broadcast or NBMA. Future interface types MAY specify a different default.
LinkLSASuppression指示是否抑制链路LSA的发起。如果设置为“已启用”，且接口类型不是广播或NBMA，路由器将不会为链路发起链路LSA。这意味着链路上的其他路由器将使用链路LSA以外的机制确定路由器的下一跳地址（见第4.8.2节）。对于本规范中描述的接口类型，默认值为“禁用”。如果接口类型为广播或NBMA，则隐式“禁用”。未来的接口类型可能会指定不同的默认值。
Virtual links are used to restore/increase connectivity of the backbone. Virtual links may be configured between any pair of area border routers having interfaces to a common (non-backbone) area. The virtual link appears as a point-to-point link with no global IPv6 addresses in the graph for the backbone. The virtual link must be configured in both of the area border routers.
虚拟链路用于恢复/增加主干网的连接性。虚拟链路可以配置在具有公共（非主干）区域接口的任何一对区域边界路由器之间。虚拟链路显示为点对点链路，在主干网的图中没有全局IPv6地址。必须在两个区域边界路由器中配置虚拟链路。
A virtual link appears in router-LSAs (for the backbone) as if it were a separate router interface to the backbone. As such, it has most of the parameters associated with a router interface (see Appendix C.3). Virtual links do not have link-local addresses, but instead use one of the router's global-scope IPv6 addresses as the IP source in OSPF protocol packets it sends on the virtual link. Router Priority is not used on virtual links. Interface output cost is not configured on virtual links, but is dynamically set to be the cost of the transit area intra-area path between the two endpoint routers. The parameter RxmtInterval may be configured and should be well over
虚拟链路出现在路由器LSA（用于主干网）中，就好像它是到主干网的单独路由器接口一样。因此，它具有与路由器接口相关的大多数参数（见附录C.3）。虚拟链路没有链路本地地址，而是使用路由器的一个全局范围IPv6地址作为它在虚拟链路上发送的OSPF协议包中的IP源。虚拟链路上未使用路由器优先级。接口输出成本不在虚拟链路上配置，而是动态设置为两个端点路由器之间的传输区域内路径的成本。可以配置参数RxmtInterval，并且参数应完全超过
the expected round-trip delay between the two routers. This may be hard to estimate for a virtual link; it is better to err on the side of making it too long.
两个路由器之间的预期往返延迟。对于虚拟链路，这可能很难估计；宁可犯错误，把时间拖得太长。
A virtual link is defined by the following two configurable parameters: the Router ID of the virtual link's other endpoint and the (non-backbone) area that the virtual link traverses (referred to as the virtual link's transit area). Virtual links cannot be configured through stub or NSSA areas. Additionally, an Instance ID may be configured for virtual links from different protocol instances in order to utilize the same transit area (without requiring different Router IDs for demultiplexing).
虚拟链路由以下两个可配置参数定义：虚拟链路的另一个端点的路由器ID和虚拟链路所经过的（非主干）区域（称为虚拟链路的传输区域）。无法通过存根或NSSA区域配置虚拟链路。此外，可以为来自不同协议实例的虚拟链路配置实例ID，以便利用相同的传输区域（不需要不同的路由器ID来解复用）。
OSPF treats an NBMA network much like it treats a broadcast network. Since there may be many routers attached to the network, a Designated Router is selected for the network. This Designated Router then originates a network-LSA listing all routers attached to the NBMA network.
OSPF对待NBMA网络就像对待广播网络一样。由于可能有许多路由器连接到网络，因此为网络选择指定的路由器。然后，该指定路由器发起网络LSA，列出连接到NBMA网络的所有路由器。
However, due to the lack of broadcast capabilities, it may be necessary to use configuration parameters in the Designated Router selection. These parameters will only need to be configured in those routers that are themselves eligible to become the Designated Router (i.e., those routers whose Router Priority for the network is non-zero), and then only if no automatic procedure for discovering neighbors exists:
但是，由于缺少广播功能，可能需要在指定的路由器选择中使用配置参数。这些参数只需要在那些自身有资格成为指定路由器的路由器（即，网络路由器优先级为非零的路由器）中配置，并且只有在不存在自动发现邻居程序的情况下：
List of all other attached routers The list of all other routers attached to the NBMA network. Each router is configured with its Router ID and IPv6 link-local address on the network. Also, for each router listed, that router's eligibility to become the Designated Router must be defined. When an interface to an NBMA network first comes up, the router only sends Hello packets to those neighbors eligible to become the Designated Router until such time that a Designated Router is elected.
所有其他连接路由器的列表连接到NBMA网络的所有其他路由器的列表。每个路由器都配置有其路由器ID和网络上的IPv6链路本地地址。此外，对于列出的每个路由器，必须定义该路由器成为指定路由器的资格。当NBMA网络的接口首次出现时，路由器仅向有资格成为指定路由器的邻居发送Hello数据包，直到选择指定路由器为止。
PollInterval If a neighboring router has become inactive (Hello packets have not been seen for RouterDeadInterval seconds), it may still be necessary to send Hello packets to the dead neighbor. These Hello packets will be sent at the reduced rate PollInterval, which should be much larger than HelloInterval. Sample value for a PDN X.25 network: 2 minutes.
PollInterval如果相邻路由器已变为非活动状态（在RouterDeadInterval秒内未看到Hello数据包），则可能仍然需要向死亡的邻居发送Hello数据包。这些Hello数据包将以较低的PollInterval速率发送，这应该比HelloInterval大得多。PDN X.25网络的样本值：2分钟。
On point-to-multipoint networks, it may be necessary to configure the set of neighbors that are directly reachable over the point-to-multipoint network. Each neighbor is configured with its Router ID and IPv6 link-local address on the network. Designated Routers are not elected on point-to-multipoint networks, so the Designated Router eligibility of configured neighbors is not defined.
在点对多点网络上，可能需要配置可通过点对多点网络直接访问的邻居集。每个邻居都配置了其路由器ID和网络上的IPv6链路本地地址。在点对多点网络上未选择指定路由器，因此未定义已配置邻居的指定路由器资格。
Host prefixes are advertised in intra-area-prefix-LSAs. They indicate either local router addresses, router interfaces to point-to-point networks, looped router interfaces, or IPv6 hosts that are directly connected to the router (e.g., via a PPP connection). For each host directly connected to the router, the following items must be configured:
主机前缀在区域内前缀LSA中播发。它们表示本地路由器地址、到点到点网络的路由器接口、环路路由器接口或直接连接到路由器（例如，通过PPP连接）的IPv6主机。对于每个直接连接到路由器的主机，必须配置以下项目：
Host IPv6 prefix An IPv6 prefix belonging to the directly connected host. This must not be a valid IPv6 global prefix.
主机IPv6前缀属于直接连接的主机的IPv6前缀。这不能是有效的IPv6全局前缀。
Cost of link to host The cost of sending a packet to the host, in terms of the link-state metric. However, since the host probably has only a single connection to the Internet, the actual configured cost(s) in many cases is unimportant (i.e., will have no effect on routing).
链路到主机的成本根据链路状态度量向主机发送数据包的成本。但是，由于主机可能只有一个到Internet的连接，因此在许多情况下，实际配置的成本并不重要（即对路由没有影响）。
Area ID The OSPF area to which the host's prefix belongs.
区域ID主机前缀所属的OSPF区域。
Authors' Addresses
作者地址
Rob Coltun Acoustra Productions 3204 Brooklawn Terrace Chevy Chase, MD 20815 USA
Rob Coltun Auditora Productions 3204布鲁克草坪露台雪佛兰蔡斯，美国马里兰州20815
Dennis Ferguson Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 USA
Dennis Ferguson Juniper Networks美国加利福尼亚州桑尼维尔马蒂尔达大道北1194号，邮编94089
EMail: dennis@juniper.net
EMail: dennis@juniper.net
John Moy Sycamore Networks, Inc 10 Elizabeth Drive Chelmsford, MA 01824 USA
美国马萨诸塞州切姆斯福德伊丽莎白大道10号约翰·莫伊·桑树网络公司01824
EMail: jmoy@sycamorenet.com
EMail: jmoy@sycamorenet.com
Acee Lindem (editor) Redback Networks 102 Carric Bend Court Cary, NC 27519 USA
Acee Lindem（编辑）Redback Networks 102美国北卡罗来纳州卡里克本德法院，邮编27519
EMail: acee@redback.com
EMail: acee@redback.com
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.