Internet Engineering Task Force (IETF) A. Lindem
Request for Comments: 7503 Cisco Systems
Updates: 5340 J. Arkko
Category: Standards Track Ericsson
ISSN: 2070-1721 April 2015
Internet Engineering Task Force (IETF) A. Lindem
Request for Comments: 7503 Cisco Systems
Updates: 5340 J. Arkko
Category: Standards Track Ericsson
ISSN: 2070-1721 April 2015
OSPFv3 Autoconfiguration
OSPFv3自动配置
Abstract
摘要
OSPFv3 is a candidate for deployments in environments where autoconfiguration is a requirement. One such environment is the IPv6 home network where users expect to simply plug in a router and have it automatically use OSPFv3 for intra-domain routing. This document describes the necessary mechanisms for OSPFv3 to be self-configuring. This document updates RFC 5340 by relaxing the HelloInterval/ RouterDeadInterval checking during OSPFv3 adjacency formation and adding hysteresis to the update of self-originated Link State Advertisements (LSAs).
OSPFv3是在需要自动配置的环境中进行部署的候选者。一个这样的环境是IPv6家庭网络，用户只需插入路由器，并让它自动使用OSPFv3进行域内路由。本文档描述了OSPFv3自我配置的必要机制。本文档通过在OSPFv3邻接形成期间放松HellInServal/RouterDeadInterval检查，并向自发式链路状态播发（LSA）的更新添加滞后来更新RFC 5340。
Status of This Memo
关于下段备忘
This is an Internet Standards Track document.
这是一份互联网标准跟踪文件。
This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Further information on Internet Standards is available in Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 5741第2节。
Information about the current status of this document, any errata, and how to provide feedback on it may be obtained at http://www.rfc-editor.org/info/rfc7503.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7503.
Copyright Notice
版权公告
Copyright (c) 2015 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2015 IETF信托基金和确定为文件作者的人员。版权所有。
This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License.
本文件受BCP 78和IETF信托有关IETF文件的法律规定的约束(http://trustee.ietf.org/license-info)自本文件出版之日起生效。请仔细阅读这些文件，因为它们描述了您对本文件的权利和限制。从本文件中提取的代码组件必须包括信托法律条款第4.e节中所述的简化BSD许可证文本，并提供简化BSD许可证中所述的无担保。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4
3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5
3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5
4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5
5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5
6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6
7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6
7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6
7.2. Duplicate Router ID Detection for Non-neighbors . . . . . 7
7.2.1. OSPFv3 Router Autoconfiguration LSA . . . . . . . . . 7
7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9
7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9
7.4. Change to RFC 2328, Section 13.4 ("Receiving
Self-Originated LSAs") . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Management Considerations . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. OSPFv3 Default Configuration . . . . . . . . . . . . . . . . 4
3. OSPFv3 HelloInterval/RouterDeadInterval Flexibility . . . . . 5
3.1. Wait Timer Reduction . . . . . . . . . . . . . . . . . . 5
4. OSPFv3 Minimal Authentication Configuration . . . . . . . . . 5
5. OSPFv3 Router ID Selection . . . . . . . . . . . . . . . . . 5
6. OSPFv3 Adjacency Formation . . . . . . . . . . . . . . . . . 6
7. OSPFv3 Duplicate Router ID Detection and Resolution . . . . . 6
7.1. Duplicate Router ID Detection for Neighbors . . . . . . . 6
7.2. Duplicate Router ID Detection for Non-neighbors . . . . . 7
7.2.1. OSPFv3 Router Autoconfiguration LSA . . . . . . . . . 7
7.2.2. Router-Hardware-Fingerprint TLV . . . . . . . . . . . 9
7.3. Duplicate Router ID Resolution . . . . . . . . . . . . . 9
7.4. Change to RFC 2328, Section 13.4 ("Receiving
Self-Originated LSAs") . . . . . . . . . . . . . . . . . 10
8. Security Considerations . . . . . . . . . . . . . . . . . . . 10
9. Management Considerations . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
11. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
11.1. Normative References . . . . . . . . . . . . . . . . . . 12
11.2. Informative References . . . . . . . . . . . . . . . . . 13
Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
OSPFv3 [OSPFV3] is a candidate for deployments in environments where autoconfiguration is a requirement. This document describes extensions to OSPFv3 to enable it to operate in these environments. In this mode of operation, the protocol is largely unchanged from the base OSPFv3 protocol specification [OSPFV3]. Since the goals of autoconfiguration and security can be conflicting, operators and network administrators should carefully consider their security requirements before deploying the solution described in this document. Refer to Section 8 for more information.
OSPFv3[OSPFv3]是在需要自动配置的环境中进行部署的候选者。本文档描述了OSPFv3的扩展，使其能够在这些环境中运行。在这种操作模式下，协议与基本OSPFv3协议规范[OSPFv3]基本相同。由于自动配置和安全性的目标可能是冲突的，因此操作员和网络管理员在部署本文档中描述的解决方案之前应仔细考虑其安全性要求。有关更多信息，请参阅第8节。
The following aspects of OSPFv3 autoconfiguration are described in this document:
本文档介绍了OSPFv3自动配置的以下方面：
1. Default OSPFv3 Configuration
1. 默认OSPFv3配置
2. HelloInterval/RouterDeadInterval Flexibility
2. HelloInterval/routerheadinterval灵活性
3. OSPFv3 Minimal Authentication Configuration
3. OSPFv3最小身份验证配置
4. Unique OSPFv3 Router ID Generation
4. 唯一OSPFv3路由器ID生成
5. OSPFv3 Adjacency Formation
5. OSPFv3邻接结构
6. Duplicate OSPFv3 Router ID Resolution
6. 重复的OSPFv3路由器ID解析
7. Self-Originated LSA Processing
7. 自创LSA处理
OSPFv3 [OSPFV3] is updated by allowing OSPFv3 adjacencies to be formed between OSPFv3 routers with differing HelloIntervals or RouterDeadIntervals (refer to Section 3). Additionally, hysteresis has been added to the processing of stale self-originated LSAs to mitigate the flooding overhead created by an OSPFv3 Router with a duplicate OSPFv3 Router ID in the OSPFv3 routing domain (refer to Section 7.4). Both updates are fully backward compatible.
OSPFv3[OSPFv3]通过允许在具有不同HellInterval或RouterReadInterval的OSPFv3路由器之间形成OSPFv3邻接来更新（参考第3节）。此外，滞后已添加到陈旧自源LSA的处理中，以减轻OSPFv3路由域中具有重复OSPFv3路由器ID的OSPFv3路由器产生的洪泛开销（参考第7.4节）。两个更新都完全向后兼容。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC-KEYWORDS].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC-关键词]中所述进行解释。
For complete autoconfiguration, OSPFv3 will need to choose suitable configuration defaults. These include:
为了完成自动配置，OSPFv3需要选择合适的默认配置。这些措施包括：
1. Area 0 Only - All autoconfigured OSPFv3 interfaces MUST be in area 0.
1. 仅限区域0-所有自动配置的OSPFv3接口必须位于区域0中。
2. OSPFv3 SHOULD be autoconfigured on all IPv6-capable interfaces on the router. An interface MAY be excluded if it is clear that running OSPFv3 on the interface is not required. For example, if manual configuration or another condition indicates that an interface is connected to an Internet Service Provider (ISP), there is typically no need to employ OSPFv3. In fact, [IPv6-CPE] specifically requires that IPv6 Customer Premise Equipment (CPE) routers not initiate any dynamic routing protocol by default on the router's WAN, i.e., ISP-facing, interface. In home networking environments, an interface where no OSPFv3 neighbors are found, but a DHCP IPv6 prefix can be acquired, may be considered an ISP-facing interface, and running OSPFv3 is unnecessary.
2. OSPFv3应该在路由器上所有支持IPv6的接口上自动配置。如果显然不需要在接口上运行OSPFv3，则可以排除接口。例如，如果手动配置或其他条件表明接口连接到Internet服务提供商（ISP），则通常不需要使用OSPFv3。事实上，[IPv6 CPE]特别要求IPv6客户前提设备（CPE）路由器在路由器的WAN（即面向ISP的接口）上默认不启动任何动态路由协议。在家庭网络环境中，找不到OSPFv3邻居但可以获取DHCP IPv6前缀的接口可能被视为面向ISP的接口，并且不需要运行OSPFv3。
3. OSPFv3 interfaces will be autoconfigured to an interface type corresponding to their Layer 2 capability. For example, Ethernet interfaces and Wi-Fi interfaces will be autoconfigured as OSPFv3 broadcast networks and Point-to-Point Protocol (PPP) interfaces will be autoconfigured as OSPFv3 Point-to-Point interfaces. Most extant OSPFv3 implementations do this already. autoconfigured operation over wireless networks requiring a point-to-multipoint (P2MP) topology and dynamic metrics based on wireless feedback is not within the scope of this document. However, autoconfiguration is not precluded in these environments.
3. OSPFv3接口将自动配置为与其第2层功能相对应的接口类型。例如，以太网接口和Wi-Fi接口将自动配置为OSPFv3广播网络，点对点协议（PPP）接口将自动配置为OSPFv3点对点接口。大多数现存的OSPFv3实现已经做到了这一点。需要点对多点（P2MP）拓扑和基于无线反馈的动态度量的无线网络上的自动配置操作不在本文档的范围内。但是，在这些环境中不排除自动配置。
4. OSPFv3 interfaces MAY use an arbitrary HelloInterval and RouterDeadInterval as specified in Section 3. Of course, an identical HelloInterval and RouterDeadInterval will still be required to form an adjacency with an OSPFv3 router not supporting autoconfiguration [OSPFV3].
4. OSPFv3接口可以使用第3节中规定的任意HelloInterval和RouterReadInterval。当然，与不支持自动配置的OSPFv3路由器[OSPFv3]邻接仍然需要相同的HelloInterval和RouterReadInterval。
5. All OSPFv3 interfaces SHOULD be autoconfigured to use an Interface Instance ID of 0 that corresponds to the base IPv6 unicast address family instance ID as defined in [OSPFV3-AF]. Similarly, if IPv4 unicast addresses are advertised in a separate autoconfigured OSPFv3 instance, the base IPv4 unicast address family instance ID value, i.e., 64, SHOULD be autoconfigured as the Interface Instance ID for all interfaces corresponding to the IPv4 unicast OSPFv3 instance [OSPFV3-AF].
5. 所有OSPFv3接口应自动配置为使用接口实例ID 0，该ID对应于[OSPFv3-AF]中定义的基本IPv6单播地址系列实例ID。类似地，如果IPv4单播地址在单独的自动配置的OSPFv3实例中播发，则应将基本IPv4单播地址系列实例ID值（即64）自动配置为与IPv4单播OSPFv3实例[OSPFv3-AF]对应的所有接口的接口实例ID。
autoconfigured OSPFv3 routers will not require an identical HelloInterval and RouterDeadInterval to form adjacencies. Rather, the received HelloInterval will be ignored and the received RouterDeadInterval will be used to determine OSPFv3 liveliness with the sending router. In other words, the Neighbor Inactivity Timer (Section 10 of [OSPFV2]) for each neighbor will reflect that neighbor's advertised RouterDeadInterval and MAY be different from other OSPFv3 routers on the link without impacting adjacency formation. A similar mechanism requiring additional signaling is proposed for all OSPFv2 and OSPFv3 routers [ASYNC-HELLO].
自动配置的OSPFv3路由器将不需要相同的HelloInterval和RouterReadInterval来形成邻接。相反，接收到的HelloInterval将被忽略，接收到的RouterDeadInterval将用于确定发送路由器的OSPFv3活跃度。换言之，每个邻居的邻居不活动计时器（OSPFV2的第10节）将反映该邻居的播发路由器主区间，并且可能不同于链路上的其他OSPFv3路由器，而不影响邻接形成。针对所有OSPFv2和OSPFv3路由器[ASYNC-HELLO]，提出了一种需要额外信令的类似机制。
In many situations, autoconfigured OSPFv3 routers will be deployed in environments where back-to-back ethernet connections are utilized. When this is the case, an OSPFv3 broadcast interface will not come up until the other OSPFv3 router is connected, and the routers will wait RouterDeadInterval seconds before forming an adjacency [OSPFV2]. In order to reduce this delay, an autoconfigured OSPFv3 router MAY reduce the wait interval to a value no less than (HelloInterval + 1). Reducing the setting will slightly increase the likelihood of the Designated Router (DR) flapping but is preferable to the long adjacency formation delay. Note that this value is not included in OSPFv3 Hello packets and does not impact interoperability.
在许多情况下，自动配置的OSPFv3路由器将部署在使用背对背以太网连接的环境中。在这种情况下，OSPFv3广播接口将不会出现，直到另一个OSPFv3路由器连接，路由器将在形成邻接之前等待RouterDeadInterval秒[OSPFV2]。为了减少这种延迟，自动配置的OSPFv3路由器可以将等待间隔减少到不小于（HelloInterval+1）的值。减少该设置将略微增加指定路由器（DR）摆动的可能性，但比长邻接形成延迟更可取。请注意，此值不包括在OSPFv3 Hello数据包中，并且不会影响互操作性。
In many deployments, the requirement for OSPFv3 authentication overrides the goal of complete OSPFv3 autoconfiguration. Therefore, it is RECOMMENDED that OSPFv3 routers supporting this specification minimally offer an option to explicitly configure a single password for HMAC-SHA authentication as described in [OSPFV3-AUTH-TRAILER]. It is RECOMMENDED that the password be entered as ASCII hexadecimal digits and that 32 or more digits be accepted to facilitate a password with a high degree of entropy. When configured, the password will be used on all autoconfigured interfaces with the Security Association Identifier (SA ID) set to 1 and HMAC-SHA-256 used as the authentication algorithm.
在许多部署中，对OSPFv3身份验证的要求覆盖了完成OSPFv3自动配置的目标。因此，建议支持此规范的OSPFv3路由器至少提供一个选项，用于显式配置HMAC-SHA身份验证的单个密码，如[OSPFv3-AUTH-TAILER]中所述。建议将密码输入为ASCII十六进制数字，并接受32位或更多数字，以便于密码具有高度的熵。配置后，密码将用于所有自动配置的接口，安全关联标识符（SA ID）设置为1，HMAC-SHA-256用作身份验证算法。
An OSPFv3 router requires a unique Router ID within the OSPFv3 routing domain for correct protocol operation. Existing Router ID selection algorithms (Appendix C.1 in [OSPFV2] and [OSPFV3]) are not viable since they are dependent on a unique IPv4 interface address that is not likely to be available in autoconfigured deployments. An
OSPFv3路由器需要在OSPFv3路由域内具有唯一的路由器ID，以实现正确的协议操作。现有的路由器ID选择算法（在[OSPFV2]和[OSPFV3]中的附录C.1）是不可行的，因为它们依赖于唯一的IPv4接口地址，而该地址在自动配置的部署中不太可能可用。一
OSPFv3 router implementing this specification will select a Router ID that has a high probability of uniqueness. A pseudorandom number SHOULD be used for the OSPFv3 Router ID. The generation SHOULD be seeded with a variable that is likely to be unique in the applicable OSPFv3 router deployment. A good choice of seed would be some portion or hash of the Router-Hardware-Fingerprint as described in Section 7.2.2.
实现此规范的OSPFv3路由器将选择具有高唯一性概率的路由器ID。OSPFv3路由器ID应使用伪随机数。生成过程中应使用一个变量进行播种，该变量在适用的OSPFv3路由器部署中可能是唯一的。一个好的种子选择是路由器硬件指纹的某部分或散列，如第7.2.2节所述。
Since there is a possibility of a Router ID collision, duplicate Router ID detection and resolution are required as described in Sections 7 and 7.3. OSPFv3 routers SHOULD maintain the last successfully chosen Router ID in nonvolatile storage to avoid collisions subsequent to when an autoconfigured OSPFv3 router is first added to the OSPFv3 routing domain.
由于存在路由器ID冲突的可能性，因此需要重复的路由器ID检测和解析，如第7节和第7.3节所述。OSPFv3路由器应在非易失性存储器中保存最后一个成功选择的路由器ID，以避免自动配置的OSPFv3路由器首次添加到OSPFv3路由域后发生冲突。
Since OSPFv3 uses IPv6 link-local addresses for all protocol messages other than messages sent on virtual links (which are not applicable to autoconfiguration), OSPFv3 adjacency formation can proceed as soon as a Router ID has been selected and the IPv6 link-local address has completed Duplicate Address Detection (DAD) as specified in IPv6 Stateless Address Autoconfiguration [SLAAC]. Otherwise, the only changes to the OSPFv3 base specification are supporting HelloInterval/RouterDeadInterval flexibility as described in Section 3 and duplicate Router ID detection and resolution as described in Sections 7 and 7.3.
由于OSPFv3对除在虚拟链路上发送的消息（不适用于自动配置）以外的所有协议消息使用IPv6链路本地地址，因此只要选择了路由器ID并且IPv6链路本地地址完成了重复地址检测（DAD），就可以进行OSPFv3邻接形成如IPv6无状态地址自动配置[SLAAC]中所述。否则，对OSPFv3基本规范的唯一更改是支持第3节中所述的HelloInterval/RouterReadiInterval灵活性，以及第7节和第7.3节中所述的重复路由器ID检测和解析。
There are two cases of duplicate OSPFv3 Router ID detection. One where the OSPFv3 router with the duplicate Router ID is directly connected and one where it is not. In both cases, the duplicate resolution is for one of the routers to select a new OSPFv3 Router ID.
存在两种重复OSPFv3路由器ID检测的情况。一个是直接连接具有重复路由器ID的OSPFv3路由器，另一个不是。在这两种情况下，重复的解决方案是让其中一个路由器选择一个新的OSPFv3路由器ID。
In this case, a duplicate Router ID is detected if any valid OSPFv3 packet is received with the same OSPFv3 Router ID but a different IPv6 link-local source address. Once this occurs, the OSPFv3 router with the numerically smaller IPv6 link-local address will need to select a new Router ID as described in Section 7.3. Note that the fact that the OSPFv3 router is a neighbor on a non-virtual interface implies that the router is directly connected. An OSPFv3 router implementing this specification should ensure that the inadvertent
在这种情况下，如果接收到任何具有相同OSPFv3路由器ID但具有不同IPv6链路本地源地址的有效OSPFv3数据包，则会检测到重复的路由器ID。一旦发生这种情况，具有较小IPv6链路本地地址的OSPFv3路由器将需要选择一个新的路由器ID，如第7.3节所述。请注意，OSPFv3路由器是非虚拟接口上的邻居这一事实意味着路由器是直接连接的。实施本规范的OSPFv3路由器应确保
connection of multiple router interfaces to the same physical link is not misconstrued as detection of an OSPFv3 neighbor with a duplicate Router ID.
将多个路由器接口连接到同一物理链路不会被误解为检测到具有重复路由器ID的OSPFv3邻居。
OSPFv3 routers implementing autoconfiguration, as specified herein, MUST originate an Autoconfiguration (AC) Link State Advertisement (LSA) including the Router-Hardware-Fingerprint Type-Length-Value (TLV). The Router-Hardware-Fingerprint TLV contains a variable-length value that has a very high probability of uniquely identifying the advertising OSPFv3 router. An OSPFv3 router implementing this specification MUST detect received Autoconfiguration LSAs with its Router ID specified in the LSA header. LSAs received with the local OSPFv3 Router's Router ID in the LSA header are perceived as self-originated (see Section 4.6 of [OSPFV3]). In these received Autoconfiguration LSAs, the Router-Hardware-Fingerprint TLV is compared against the OSPFv3 Router's own router hardware fingerprint. If the fingerprints are not equal, there is a duplicate Router ID conflict and the OSPFv3 router with the numerically smaller router hardware fingerprint MUST select a new Router ID as described in Section 7.3.
如本文所述，实现自动配置的OSPFv3路由器必须发起自动配置（AC）链路状态公告（LSA），包括路由器硬件指纹类型长度值（TLV）。路由器硬件指纹TLV包含一个可变长度值，该值具有非常高的唯一识别OSPFv3路由器的概率。实现此规范的OSPFv3路由器必须检测接收到的自动配置LSA，其路由器ID在LSA报头中指定。在LSA报头中使用本地OSPFv3路由器的路由器ID接收的LSA被认为是自源的（见[OSPFv3]第4.6节）。在这些接收到的自动配置LSA中，将路由器硬件指纹TLV与OSPFv3路由器自身的路由器硬件指纹进行比较。如果指纹不相等，则存在重复的路由器ID冲突，具有数字较小的路由器硬件指纹的OSPFv3路由器必须按照第7.3节所述选择新的路由器ID。
This new LSA is designated for information related to OSPFv3 autoconfiguration and, in the future, could be used for other autoconfiguration information, e.g., global IPv6 prefixes. However, this is beyond the scope of this document.
这个新的LSA被指定用于与OSPFv3自动配置相关的信息，并且将来可以用于其他自动配置信息，例如，全局IPv6前缀。但是，这超出了本文件的范围。
The OSPFv3 Autoconfiguration (AC) LSA has a function code of 15 and the S2/S1 bits set to 01 indicating Area Flooding Scope. The U bit will be set indicating that the OSPFv3 AC LSA should be flooded even if it is not understood. The Link State ID (LSID) value will be an integer index used to discriminate between multiple AC LSAs originated by the same OSPFv3 router. This specification only describes the contents of an AC LSA with an LSID of 0.
OSPFv3自动配置（AC）LSA的功能代码为15，S2/S1位设置为01，表示区域泛洪范围。U位将被设置，指示即使无法理解OSPFv3 AC LSA也应被淹没。链路状态ID（LSID）值将是一个整数索引，用于区分由同一OSPFv3路由器发起的多个AC LSA。本规范仅描述LSID为0的AC 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 |1|0|1| 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
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 |1|0|1| 15 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Link State ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Advertising Router |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS sequence number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LS checksum | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
+- TLVs -+
| ... |
OSPFv3 Autoconfiguration (AC) LSA
OSPFv3自动配置（AC）LSA
The format of the TLVs within the body of an AC LSA is the same as the format used by the Traffic Engineering Extensions to OSPFv2 [TE]. The LSA payload consists of one or more nested TLV triplets. The format of each TLV is:
AC LSA主体内TLV的格式与OSPFv2[TE]的流量工程扩展使用的格式相同。LSA有效载荷由一个或多个嵌套TLV三元组组成。每个TLV的格式为：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
TLV Format
TLV格式
The Length field defines the length of the value portion in octets (thus a TLV with no value portion would have a length of 0). The TLV is padded to 4-octet alignment; padding is not included in the length field (so a 3-octet value would have a length of 3, but the total size of the TLV would be 8 octets). Nested TLVs are also 32-bit aligned. For example, a 1-byte value would have the length field set to 1, and 3 octets of padding would be added to the end of the value portion of the TLV. Unrecognized types are ignored.
长度字段以八位字节定义值部分的长度（因此，没有值部分的TLV的长度为0）。TLV填充为4-八位组对齐；长度字段中不包括填充（因此3个八位字节的值的长度为3，但TLV的总大小为8个八位字节）。嵌套TLV也是32位对齐的。例如，一个1字节的值将把length字段设置为1，并在TLV的值部分的末尾添加3个八位字节的填充。将忽略无法识别的类型。
The new LSA is designated for information related to OSPFv3 autoconfiguration and, in the future, can be used other autoconfiguration information.
新的LSA指定用于与OSPFv3自动配置相关的信息，并且在将来可用于其他自动配置信息。
The Router-Hardware-Fingerprint TLV is the first TLV defined for the OSPFv3 Autoconfiguration (AC) LSA. It will have type 1 and MUST be advertised in the LSID OSPFv3 AC LSA with an LSID of 0. It SHOULD occur, at most, once and the first instance of the TLV will take precedence over subsequent TLV instances. The length of the Router-Hardware-Fingerprint is variable but must be 32 octets or greater. If the Router-Hardware-Fingerprint TLV is not present as the first TLV, the AC LSA is considered malformed and is ignored for the purposes of duplicate Router ID detection. Additionally, the event SHOULD be logged.
路由器硬件指纹TLV是为OSPFv3自动配置（AC）LSA定义的第一个TLV。它将具有类型1，并且必须在LSID为0的LSID OSPFv3 AC LSA中公布。它最多应该发生一次，TLV的第一个实例将优先于后续TLV实例。路由器硬件指纹的长度是可变的，但必须是32个八位字节或更大。如果路由器硬件指纹TLV不作为第一个TLV出现，则AC LSA被视为格式错误，并且出于重复路由器ID检测的目的被忽略。此外，应记录该事件。
The contents of the hardware fingerprint MUST have an extremely high probability of uniqueness. It SHOULD be constructed from the concatenation of a number of local values that themselves have a high likelihood of uniqueness, such as Media Access Control (MAC) addresses, CPU ID, or serial numbers. It is RECOMMENDED that one or more available universal tokens (e.g., IEEE 802 48-bit MAC addresses or IEEE EUI-64 Identifiers [EUI64]) associated with the OSPFv3 router be included in the hardware fingerprint. It MUST be based on hardware attributes that will not change across hard and soft restarts.
硬件指纹的内容必须具有极高的唯一性概率。它应该由许多本地值串联而成，这些值本身具有很高的唯一性，例如媒体访问控制（MAC）地址、CPU ID或序列号。建议在硬件指纹中包括与OSPFv3路由器相关联的一个或多个可用通用令牌（例如，IEEE 802 48位MAC地址或IEEE EUI-64标识符[EUI64]）。它必须基于硬件属性，这些属性在硬重启和软重启时不会改变。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | >32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Hardware Fingerprint |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | >32 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Router Hardware Fingerprint |
o
o
o
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Router-Hardware-Fingerprint TLV Format
路由器硬件指纹TLV格式
The OSPFv3 router selected to resolve the duplicate OSPFv3 Router ID condition must select a new OSPFv3 Router ID. The OSPFv3 router SHOULD reduce the possibility of a subsequent Router ID collision by checking the Link State Database (LSDB) for an OSPFv3 Autoconfiguration LSA with the newly selected Router ID and a different Router-Hardware-Fingerprint. If one is detected, a new Router ID should be selected without going through the resolution process (Section 7). After selecting a new Router ID, all self-
选择用于解决重复的OSPFv3路由器ID条件的OSPFv3路由器必须选择新的OSPFv3路由器ID。OSPFv3路由器应通过检查链路状态数据库（LSDB）来减少后续路由器ID冲突的可能性对于具有新选择的路由器ID和不同路由器硬件指纹的OSPFv3自动配置LSA。如果检测到一个路由器ID，则应选择一个新的路由器ID，而无需经过解析过程（第7节）。选择一个新的路由器ID后，所有的-
originated LSAs MUST be reoriginated, and any OSPFv3 neighbor adjacencies MUST be reestablished. The OSPFv3 router retaining the Router ID causing the conflict will reoriginate or flush any stale self-originated LSAs as described in Section 13.4 of [OSPFV2].
必须重新确定原始LSA的顺序，并且必须重新建立任何OSPFv3邻居邻接。如[OSPFV2]第13.4节所述，保留引起冲突的路由器ID的OSPFv3路由器将重新排序或刷新任何过时的自创LSA。
7.4. Change to RFC 2328, Section 13.4 ("Receiving Self-Originated LSAs")
7.4. 更改为RFC 2328，第13.4节（“接收自创LSA”）
RFC 2328 [OSPFV2], Section 13.4, describes the processing of received self-originated LSAs. If the received LSA doesn't exist, the receiving router will flush it from the OSPF routing domain. If the LSA is newer than the version in the LSDB, the receiving router will originate a newer version by advancing the LSA sequence number and reoriginating. Since it is possible for an autoconfigured OSPFv3 router to choose a duplicate OSPFv3 Router ID, OSPFv3 routers implementing this specification should detect when multiple instances of the same self-originated LSA are flushed or reoriginated since this is indicative of an OSPFv3 router with a duplicate Router ID in the OSPFv3 routing domain. When this condition is detected, the OSPFv3 router SHOULD delay self-originated LSA processing for LSAs that have recently been flushed or reoriginated. This specification recommends 10 seconds as the interval defining recent self-originated LSA processing and an exponential back-off of 1 to 8 seconds for the processing delay. This additional delay should allow for the mechanisms described in Section 7 to resolve the duplicate OSPFv3 Router ID conflict.
RFC 2328[OSPFV2]第13.4节描述了接收到的自源LSA的处理。如果接收到的LSA不存在，接收路由器将从OSPF路由域刷新它。如果LSA比LSDB中的版本更新，则接收路由器将通过推进LSA序列号并重新排序来发起更新的版本。由于自动配置的OSPFv3路由器可能选择重复的OSPFv3路由器ID，因此实现本规范的OSPFv3路由器应检测何时刷新或重新确定相同自源LSA的多个实例，因为这表示OSPFv3路由器在OSPFv3路由域中具有重复的路由器ID。当检测到这种情况时，OSPFv3路由器应延迟最近刷新或重新定序的LSA的自源LSA处理。本规范建议将10秒作为定义最近自创LSA处理的间隔，并将1到8秒作为处理延迟的指数后退。此额外延迟应允许第7节中描述的机制解决重复的OSPFv3路由器ID冲突。
Since this mechanism is useful in mitigating the flooding overhead associated with the inadvertent or malicious introduction of an OSPFv3 router with a duplicate Router ID into an OSPFv3 routing domain, it MAY be deployed outside of autoconfigured deployments. The detection of a self-originated LSA that is being repeatedly reoriginated or flushed SHOULD be logged.
由于此机制有助于减轻因无意或恶意将具有重复路由器ID的OSPFv3路由器引入OSPFv3路由域而产生的泛洪开销，因此可将其部署在自动配置的部署之外。应记录对重复重新定位或刷新的自创LSA的检测。
The goals of security and complete OSPFv3 autoconfiguration are somewhat contradictory. When no explicit security configuration takes place, autoconfiguration implies that additional devices placed in the network are automatically adopted as a part of the network. However, autoconfiguration can also be combined with password configuration (see Section 4) or future extensions for automatic pairing between devices. These mechanisms can help provide an automatically configured, securely routed network.
安全性和完整OSPFv3自动配置的目标有些矛盾。当没有进行明确的安全配置时，自动配置意味着放置在网络中的其他设备将自动作为网络的一部分。但是，自动配置也可以与密码配置（参见第4节）或设备之间自动配对的未来扩展相结合。这些机制有助于提供一个自动配置、安全路由的网络。
In deployments where a different authentication algorithm or encryption is required (or different per-interface keys are required), OSPFv3 IPsec [OSPFV3-IPSEC] or alternate OSPFv3
在需要不同身份验证算法或加密（或需要不同的每个接口密钥）的部署中，OSPFv3 IPsec[OSPFv3-IPsec]或备用OSPFv3
Authentication Trailer [OSPFV3-AUTH-TRAILER] algorithms MAY be used at the expense of additional configuration. The configuration and operational description of such deployments are beyond the scope of this document. However, a deployment could always revert to explicit configuration as described in Section 9 for features such as IPsec, per-interface keys, or alternate authentication algorithms.
认证拖车[OSPFV3-AUTH-TAILER]算法的使用可能会牺牲额外的配置。此类部署的配置和操作说明超出了本文档的范围。但是，对于IPsec、每个接口密钥或备用身份验证算法等功能，部署始终可以恢复到第9节中描述的显式配置。
The introduction, either malicious or accidental, of an OSPFv3 router with a duplicate Router ID is an attack point for OSPFv3 routing domains. This is due to the fact that OSPFv3 routers will interpret LSAs advertised by the router with the same Router ID as self-originated LSAs and attempt to flush them from the routing domain. The mechanisms in Section 7.4 will mitigate the effects of duplication.
恶意或意外引入具有重复路由器ID的OSPFv3路由器是OSPFv3路由域的攻击点。这是因为OSPFv3路由器将使用与自创LSA相同的路由器ID解释路由器播发的LSA，并尝试从路由域刷新它们。第7.4节中的机制将减轻重复的影响。
It is RECOMMENDED that OSPFv3 routers supporting this specification also support explicit configuration of OSPFv3 parameters as specified in Appendix C of [OSPFV3]. This would allow explicit override of autoconfigured parameters in situations where it is required (e.g., if the deployment requires multiple OSPFv3 areas). This is in addition to the authentication key configuration recommended in Section 4. Additionally, it is RECOMMENDED that OSPFv3 routers supporting this specification allow autoconfiguration to be completely disabled.
建议支持本规范的OSPFv3路由器也支持[OSPFv3]附录C中规定的OSPFv3参数的显式配置。这将允许在需要自动配置参数的情况下（例如，如果部署需要多个OSPFv3区域）显式覆盖自动配置参数。这是对第4节中建议的身份验证密钥配置的补充。此外，建议支持此规范的OSPFv3路由器允许完全禁用自动配置。
Since there is a small possibility of OSPFv3 Router ID collisions, manual configuration of OSPFv3 Router IDs is RECOMMENDED in OSPFv3 routing domains where route convergence due to a Router ID change is intolerable.
由于OSPFv3路由器ID冲突的可能性很小，建议在OSPFv3路由域中手动配置OSPFv3路由器ID，因为路由器ID更改导致的路由收敛是不可容忍的。
OSPFv3 routers supporting this specification MUST augment mechanisms for displaying or otherwise conveying OSPFv3 operational state to indicate whether or not the OSPFv3 router was autoconfigured and whether or not its OSPFv3 interfaces have been autoconfigured.
支持本规范的OSPFv3路由器必须增加显示或以其他方式传输OSPFv3操作状态的机制，以指示OSPFv3路由器是否已自动配置，以及其OSPFv3接口是否已自动配置。
This specification defines an OSPFv3 LSA Type for the OSPFv3 Autoconfiguration (AC) LSA, as described in Section 7.2.1. The value 15 has been allocated from the existing "OSPFv3 LSA Function Codes" registry for the OSPFv3 Autoconfiguration (AC) LSA.
本规范定义了OSPFv3自动配置（AC）LSA的OSPFv3 LSA类型，如第7.2.1节所述。值15已从OSPFv3自动配置（AC）LSA的现有“OSPFv3 LSA功能代码”注册表中分配。
This specification also creates a registry for OSPFv3 Autoconfiguration (AC) LSA TLVs. This registry has been placed in the existing OSPFv3 IANA registry, and new values will be allocated via IETF Review or, under exceptional circumstances, IESG Approval. [IANA-GUIDELINES]
本规范还为OSPFv3自动配置（AC）LSA TLV创建了一个注册表。该注册表已放置在现有的OSPFv3 IANA注册表中，新值将通过IETF审查或在特殊情况下通过IESG批准进行分配。[IANA-指南]
Three initial values are allocated:
分配了三个初始值：
o 0 is marked as Reserved.
o 0被标记为保留。
o 1 is Router-Hardware-Fingerprint TLV (Section 7.2.2).
o 1是路由器硬件指纹TLV（第7.2.2节）。
o 65535 is an Autoconfiguration-Experiment-TLV, a common value that can be used for experimental purposes.
o 65535是一个自动配置实验TLV，一个可用于实验目的的通用值。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[OSPFV2]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月<http://www.rfc-editor.org/info/rfc2328>.
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[OSPFV3]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月<http://www.rfc-editor.org/info/rfc5340>.
[OSPFV3-AF] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010, <http://www.rfc-editor.org/info/rfc5838>.
[OSPFV3-AF]Lindem，A.，Ed.，Mirtorabi，S.，Roy，A.，Barnes，M.，和R.Aggarwal，“OSPFV3中地址家庭的支持”，RFC 5838，2010年4月<http://www.rfc-editor.org/info/rfc5838>.
[OSPFV3-AUTH-TRAILER] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, March 2014, <http://www.rfc-editor.org/info/rfc7166>.
[OSPFV3-AUTH-TRAILER]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFV3支持认证拖车”，RFC 71662014年3月<http://www.rfc-editor.org/info/rfc7166>.
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[SLAAC] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless Address Autoconfiguration", RFC 4862, September 2007, <http://www.rfc-editor.org/info/rfc4862>.
[SLAAC]Thomson，S.，Narten，T.和T.Jinmei，“IPv6无状态地址自动配置”，RFC 48622007年9月<http://www.rfc-editor.org/info/rfc4862>.
[TE] Katz, D., Kompella, K., and D. Yeung, "Traffic Engineering (TE) Extensions to OSPF Version 2", RFC 3630, September 2003, <http://www.rfc-editor.org/info/rfc3630>.
[TE]Katz，D.，Kompella，K.，和D.Yeung，“OSPF版本2的交通工程（TE）扩展”，RFC 3630，2003年9月<http://www.rfc-editor.org/info/rfc3630>.
[ASYNC-HELLO] Anand, M., Grover, H., and A. Roy, "Asymmetric OSPF Hold Timer", Work in Progress, draft-madhukar-ospf-agr-asymmetric-01, June 2013.
[ASYNC-HELLO]Anand，M.，Grover，H.，和A.Roy，“非对称OSPF保持计时器”，正在进行的工作，draft-madhukar-OSPF-agr-不对称-012013年6月。
[EUI64] IEEE, "Guidelines for 64-bit Global Identifier (EUI-64)", Registration Authority Tutorial, March 1997, <http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>.
[EUI64]IEEE，“64位全局标识符（EUI-64）指南”，注册机构教程，1997年3月<http://standards.ieee.org/regauth/oui/tutorials/ EUI64.html>。
[IANA-GUIDELINES] Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA Considerations Section in RFCs", BCP 26, RFC 5226, May 2008, <http://www.rfc-editor.org/info/rfc5226>.
[IANA-GUIDELINES]Narten，T.和H.Alvestrand，“在RFCs中编写IANA注意事项部分的指南”，BCP 26，RFC 5226，2008年5月<http://www.rfc-editor.org/info/rfc5226>.
[IPv6-CPE] Singh, H., Beebee, W., Donley, C., and B. Stark, "Basic Requirements for IPv6 Customer Edge Routers", RFC 7084, November 2013, <http://www.rfc-editor.org/info/rfc7084>.
[IPv6 CPE]Singh，H.，Beebee，W.，Donley，C.，和B.Stark，“IPv6客户边缘路由器的基本要求”，RFC 70842013年11月<http://www.rfc-editor.org/info/rfc7084>.
[OSPFV3-IPSEC] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006, <http://www.rfc-editor.org/info/rfc4552>.
[OSPFV3-IPSEC]Gupta，M.和N.Melam，“OSPFV3的认证/保密”，RFC 45522006年6月<http://www.rfc-editor.org/info/rfc4552>.
Acknowledgments
致谢
This specification was inspired by the work presented in the HOMENET working group meeting in October 2011 in Philadelphia, Pennsylvania. In particular, we would like to thank Fred Baker, Lorenzo Colitti, Ole Troan, Mark Townsley, and Michael Richardson.
本规范的灵感来源于2011年10月在宾夕法尼亚州费城举行的HOMENET工作组会议上介绍的工作。我们要特别感谢弗雷德·贝克、洛伦佐·科利蒂、奥勒·特隆、马克·汤斯利和迈克尔·理查森。
Arthur Dimitrelis and Aidan Williams did prior work in OSPFv3 autoconfiguration in the expired Internet-Draft titled "Autoconfiguration of routers using a link state routing protocol". There are many similarities between the concepts and techniques in this document.
Arthur Dimitrelis和Aidan Williams在题为“使用链路状态路由协议自动配置路由器”的过期互联网草案中对OSPFv3自动配置做了前期工作。本文档中的概念和技术有许多相似之处。
Thanks for Abhay Roy and Manav Bhatia for comments regarding duplicate Router ID processing.
感谢Abhay Roy和Manav Bhatia对重复路由器ID处理的评论。
Thanks for Alvaro Retana and Michael Barnes for comments regarding OSPFv3 Instance ID autoconfiguration.
感谢Alvaro Retana和Michael Barnes对OSPFv3实例ID自动配置的评论。
Thanks to Faraz Shamim for review and comments.
感谢Faraz Shamim的审核和评论。
Thanks to Mark Smith for the requirement to reduce the adjacency formation delay in the back-to-back ethernet topologies that are prevalent in home networks.
感谢Mark Smith提出的减少家庭网络中流行的背靠背以太网拓扑中邻接形成延迟的要求。
Thanks to Les Ginsberg for document review and recommendations on OSPFv3 hardware fingerprint content.
感谢Les Ginsberg对OSPFv3硬件指纹内容的文档审查和建议。
Thanks to Curtis Villamizar for document review and analysis of duplicate Router ID resolution nuances.
感谢Curtis Villamizar对重复路由器ID解析细微差别的文档审查和分析。
Thanks to Uma Chunduri for comments during OSPF WG last call.
感谢Uma Chunduri在OSPF工作组最后一次通话中的评论。
Thanks to Martin Vigoureux for Routing Area Directorate review and comments.
感谢Martin Vigoureux对路由区域董事会的审查和评论。
Thanks to Adam Montville for Security Area Directorate review and comments.
感谢Adam Montville对安全区董事会的审查和评论。
Thanks to Qin Wu for Operations & Management Area Directorate review and comments.
感谢秦武对运营管理区董事会的审查和评论。
Thanks to Robert Sparks for General Area (GEN-ART) review and comments.
感谢Robert Sparks对一般领域（GEN-ART）的审查和评论。
Thanks to Rama Darbha for review and comments.
感谢Rama Darbha的审查和评论。
Special thanks to Adrian Farrel for his in-depth review, copious comments, and suggested text.
特别感谢阿德里安·法雷尔的深入评论、丰富的评论和建议文本。
Special thanks go to Markus Stenberg for his implementation of this specification in Bird.
特别感谢Markus Stenberg在Bird中实施本规范。
Special thanks also go to David Lamparter for his implementation of this specification in Quagga.
特别感谢David Lamparter在Quagga中实现了此规范。
This document was initially produced using the xml2rfc tool.
本文档最初是使用xml2rfc工具生成的。
Authors' Addresses
作者地址
Acee Lindem Cisco Systems 301 Midenhall Way Cary, NC 27513 United States
Acee Lindem思科系统301美国北卡罗来纳州米登霍尔大道卡里27513号
EMail: acee@cisco.com
EMail: acee@cisco.com
Jari Arkko Ericsson Jorvas, 02420 Finland
雅丽•阿尔科•爱立信•乔瓦斯，芬兰02420
EMail: jari.arkko@piuha.net
EMail: jari.arkko@piuha.net