Internet Engineering Task Force (IETF) I. Chen
Request for Comments: 7949 Ericsson
Updates: 5838 A. Lindem
Category: Standards Track Cisco
ISSN: 2070-1721 R. Atkinson
Consultant
August 2016
Internet Engineering Task Force (IETF) I. Chen
Request for Comments: 7949 Ericsson
Updates: 5838 A. Lindem
Category: Standards Track Cisco
ISSN: 2070-1721 R. Atkinson
Consultant
August 2016
OSPFv3 over IPv4 for IPv6 Transition
用于IPv6转换的IPv4上的OSPFv3
Abstract
摘要
This document defines a mechanism to use IPv4 to transport OSPFv3 packets. Using OSPFv3 over IPv4 with the existing OSPFv3 Address Family extension can simplify transition from an OSPFv2 IPv4-only routing domain to an OSPFv3 dual-stack routing domain. This document updates RFC 5838 to support virtual links in the IPv4 unicast address family when using OSPFv3 over IPv4.
本文档定义了使用IPv4传输OSPFv3数据包的机制。将OSPFv3 over IPv4与现有的OSPFv3地址系列扩展一起使用，可以简化从仅OSPFv2 IPv4路由域到OSPFv3双堆栈路由域的转换。本文档更新了RFC 5838，以在IPv4上使用OSPFv3时支持IPv4单播地址系列中的虚拟链路。
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 7841.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。有关互联网标准的更多信息，请参见RFC 7841第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/rfc7949.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc7949.
Copyright Notice
版权公告
Copyright (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2016 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 ....................................................2
1.1. IPv4-Only Use Case .........................................3
2. Requirements Language ...........................................4
3. Encapsulation in IPv4 ...........................................4
3.1. Source Address .............................................6
3.2. Destination Address ........................................6
3.3. OSPFv3 Header Checksum .....................................6
3.4. Operation over Virtual Links ...............................7
4. Management Considerations .......................................7
4.1. Coexistence with OSPFv2 ....................................7
5. Security Considerations .........................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
Acknowledgments ...................................................10
Authors' Addresses ................................................11
1. Introduction ....................................................2
1.1. IPv4-Only Use Case .........................................3
2. Requirements Language ...........................................4
3. Encapsulation in IPv4 ...........................................4
3.1. Source Address .............................................6
3.2. Destination Address ........................................6
3.3. OSPFv3 Header Checksum .....................................6
3.4. Operation over Virtual Links ...............................7
4. Management Considerations .......................................7
4.1. Coexistence with OSPFv2 ....................................7
5. Security Considerations .........................................8
6. References ......................................................8
6.1. Normative References .......................................8
6.2. Informative References .....................................9
Acknowledgments ...................................................10
Authors' Addresses ................................................11
Using OSPFv3 [RFC5340] over IPv4 [RFC791] with the existing OSPFv3 address family extension can simplify transition from an IPv4-only routing domain to an IPv6 [RFC2460] or dual-stack routing domain. Dual-stack routing protocols, such as the Border Gateway Protocol [RFC4271], have an advantage during the transition, because both IPv4 and IPv6 address families can be advertised using either IPv4 or IPv6 transport. Some IPv4-specific and IPv6-specific routing protocols share enough similarities in their protocol packet formats and protocol signaling that it is trivial to deploy an initial IPv6 routing domain by transporting the routing protocol over IPv4, thereby allowing IPv6 routing domains to be deployed and tested before decommissioning IPv4 and moving to an IPv6-only network.
将IPv4[RFC791]上的OSPFv3[RFC5340]与现有的OSPFv3地址系列扩展一起使用，可以简化从仅IPv4路由域到IPv6[RFC2460]或双堆栈路由域的转换。双栈路由协议（如边界网关协议[RFC4271]）在转换期间具有优势，因为IPv4和IPv6地址族都可以使用IPv4或IPv6传输进行公告。某些特定于IPv4和特定于IPv6的路由协议在其协议包格式和协议信令方面具有足够的相似性，因此通过IPv4传输路由协议来部署初始IPv6路由域非常简单，因此，允许在停用IPv4并移动到仅限IPv6的网络之前部署和测试IPv6路由域。
In the case of the Open Shortest Path First (OSPF) interior gateway routing protocol (IGP), OSPFv2 [RFC2328] is the IGP deployed over IPv4, while OSPFv3 [RFC5340] is the IGP deployed over IPv6. OSPFv3 further supports multiple address families [RFC5838], including both the IPv6 unicast address family and the IPv4 unicast address family. Consequently, it is possible to deploy OSPFv3 over IPv4 without any changes to either OSPFv3 or IPv4. During the transition to IPv6, future OSPF extensions can focus on OSPFv3, and OSPFv2 can move to maintenance mode.
在开放最短路径优先（OSPF）内部网关路由协议（IGP）的情况下，OSPFv2[RFC2328]是通过IPv4部署的IGP，而OSPFv3[RFC5340]是通过IPv6部署的IGP。OSPFv3还支持多个地址系列[RFC5838]，包括IPv6单播地址系列和IPv4单播地址系列。因此，可以通过IPv4部署OSPFv3，而无需对OSPFv3或IPv4进行任何更改。在向IPv6过渡期间，未来的OSPF扩展可以集中在OSPFv3上，而OSPFv2可以转移到维护模式。
This document specifies how to use IPv4 to transport OSPFv3 packets. The mechanism takes advantage of the fact that OSPFv2 and OSPFv3 share the same IP protocol number, 89. Additionally, the OSPF packet header for both OSPFv2 and OSPFv3 includes the OSPF header version
本文档指定如何使用IPv4传输OSPFv3数据包。该机制利用了OSPFv2和OSPFv3共享相同的IP协议号89这一事实。此外，OSPFv2和OSPFv3的OSPF数据包报头都包括OSPF报头版本
(i.e., the field that distinguishes an OSPFv2 packet from an OSPFv3 packet) in the same location (i.e., the same offset from the start of the header).
（即，区分OSPFv2分组和OSPFv3分组的字段）位于相同位置（即，从报头开始的相同偏移量）。
If the IPv4 topology and IPv6 topology are not identical, the most likely cause is that some parts of the network deployment have not yet been upgraded to support both IPv4 and IPv6. In situations where the IPv4 deployment is a superset of the IPv6 deployment, it is expected that OSPFv3 packets would be transported over IPv4, until the rest of the network deployment is upgraded to support IPv6 in addition to IPv4. In situations where the IPv6 deployment is a superset of the IPv4 deployment, it is expected that OSPFv3 would be transported over IPv6.
如果IPv4拓扑和IPv6拓扑不相同，最可能的原因是网络部署的某些部分尚未升级以同时支持IPv4和IPv6。在IPv4部署是IPv6部署的超集的情况下，预计OSPFv3数据包将通过IPv4传输，直到网络部署的其余部分升级为除IPv4外支持IPv6。在IPv6部署是IPv4部署的超集的情况下，预计OSPFv3将通过IPv6传输。
Throughout this document, "OSPF" is used when the text applies to both OSPFv2 and OSPFv3. "OSPFv2" or "OSPFv3" is used when the text is specific to one version of the OSPF protocol. Similarly, "IP" is used when the text describes either version of the Internet Protocol. "IPv4" or "IPv6" is used when the text is specific to a single version of the Internet Protocol.
在本文件中，当文本同时适用于OSPFv2和OSPFv3时，使用“OSPF”。当文本特定于OSPF协议的一个版本时，使用“OSPFv2”或“OSPFv3”。同样，当文本描述互联网协议的任一版本时，使用“IP”。当文本特定于单一版本的Internet协议时，使用“IPv4”或“IPv6”。
OSPFv3 only requires IPv6 link-local addresses to form adjacencies, and does not require IPv6 global-scope addresses to establish an IPv6 routing domain. However, IPv6 over Ethernet [RFC2464] uses a different EtherType (0x86dd) from IPv4 (0x0800) and the Address Resolution Protocol (ARP) (0x0806) [RFC826] used with IPv4.
OSPFv3只需要IPv6链路本地地址来形成邻接，不需要IPv6全局作用域地址来建立IPv6路由域。但是，以太网上的IPv6[RFC2464]使用与IPv4（0x0800）不同的以太网类型（0x86dd）以及与IPv4一起使用的地址解析协议（ARP）（0x0806）[RFC826]。
Some existing deployed link-layer equipment only supports IPv4 and ARP. Such equipment contains hardware filters keyed on the EtherType field of the Ethernet frame to filter which frames will be accepted by that link-layer equipment. Because IPv6 uses a different EtherType, IPv6 framing for OSPFv3 will not work with that equipment. In other cases, Point-to-Point Protocol (PPP) might be used over a serial interface, but again only IPv4 over PPP might be supported over such an interface. It is hoped that equipment with such limitations will be eventually upgraded or replaced.
一些现有部署的链路层设备仅支持IPv4和ARP。此类设备包含键入以太网帧的EtherType字段的硬件过滤器，以过滤该链路层设备将接受哪些帧。由于IPv6使用不同的以太网类型，OSPFv3的IPv6帧将无法与该设备一起工作。在其他情况下，可以在串行接口上使用点对点协议（PPP），但在这样的接口上可能只支持IPv4 over PPP。希望有这些限制的设备最终将得到升级或更换。
In some locations, especially locations with less communications infrastructure, satellite communications (SATCOM) are used to reduce deployment costs for data networking. SATCOM often has lower cost to deploy than running new copper or optical cables over long distances to connect remote areas. Also, in a wide range of locations including places with good communications infrastructure, Very Small Aperture Terminals (VSATs) often are used by banks and retailers to connect their branches and stores to a central location.
在一些地方，特别是通信基础设施较少的地方，卫星通信（SATCOM）用于降低数据网络的部署成本。卫星通信的部署成本通常比长距离使用新的铜缆或光缆连接偏远地区要低。此外，在广泛的地点，包括具有良好通信基础设施的地点，银行和零售商通常使用甚小孔径终端（VSAT）将其分行和商店连接到中心地点。
Some widely deployed VSAT equipment has either (A) Ethernet interfaces that only support the Ethernet Address Resolution Protocol (ARP) and IPv4, or (B) serial interfaces that only support IPv4 and PPP packets. Such deployments and equipment still can deploy and use OSPFv3 over IPv4 today, and then later migrate to OSPFv3 over IPv6 after equipment is upgraded or replaced. This can have lower operational costs than running OSPFv2 and then trying to make a flag-day switch to OSPFv3. By running OSPFv3 over IPv4 now, the eventual transition to dual-stack, and then to IPv6-only, can be orchestrated.
一些广泛部署的VSAT设备具有（A）只支持以太网地址解析协议（ARP）和IPv4的以太网接口，或（B）只支持IPv4和PPP数据包的串行接口。这些部署和设备现在仍然可以通过IPv4部署和使用OSPFv3，然后在设备升级或更换后通过IPv6迁移到OSPFv3。这比运行OSPFv2然后尝试将卖旗日切换到OSPFv3的运营成本更低。通过现在在IPv4上运行OSPFv3，最终可以协调到双栈，然后到仅IPv6的过渡。
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119].
本文件中的关键词“必须”、“不得”、“必需”、“应”、“不应”、“应”、“不应”、“建议”、“可”和“可选”应按照[RFC2119]中所述进行解释。
An OSPFv3 packet can be directly encapsulated within an IPv4 packet as the payload, without the IPv6 packet header, as illustrated in Figure 1. For OSPFv3 transported over IPv4, the IPv4 packet has an IPv4 protocol type of 89, denoting that the payload is an OSPF packet. The payload of the IPv4 packet consists of an OSPFv3 packet, beginning with the OSPF packet header having its OSPF version field set to 3.
OSPFv3数据包可以直接封装在IPv4数据包中作为有效负载，而不需要IPv6数据包头，如图1所示。对于通过IPv4传输的OSPFv3，IPv4数据包的IPv4协议类型为89，表示有效负载是OSPF数据包。IPv4数据包的有效负载由OSPFv3数据包组成，从OSPF数据包头开始，其OSPF版本字段设置为3。
An OSPFv3 packet followed by an OSPF link-local signaling (LLS) extension data block [RFC5613] encapsulated in an IPv4 packet is illustrated in Figure 2.
图2显示了一个OSPFv3数据包，其后是封装在IPv4数据包中的OSPF链路本地信令（LLS）扩展数据块[RFC5613]。
Since an IPv4 header without options is only 20 octets long and is shorter than an IPv6 header, an OSPFv3 packet encapsulated in a 20-octet IPv4 header is shorter than an OSPFv3 packet encapsulated in an IPv6 header. Consequently, the link MTU for IPv6 is sufficient to transport an OSPFv3 packet encapsulated in a 20-octet IPv4 header. If the link MTU is not sufficient to transport an OSPFv3 packet in IPv4, then OSPFv3 can rely on IP fragmentation and reassembly [RFC791].
由于没有选项的IPv4报头只有20个八位字节长，并且比IPv6报头短，因此封装在20个八位字节IPv4报头中的OSPFv3数据包比封装在IPv6报头中的OSPFv3数据包短。因此，IPv6的链路MTU足以传输封装在20八位组IPv4报头中的OSPFv3数据包。如果链路MTU不足以在IPv4中传输OSPFv3数据包，则OSPFv3可以依赖IP碎片和重组[RFC791]。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 4 | IHL |Type of Service| Total Length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identification |Flags| Fragment Offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Time to Live | Protocol (89) | Header Checksum | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Source Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Destination Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Options | Padding | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 3 | Type | Packet length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Router ID | OSPFv3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Area ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum | Instance ID | 0 | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| OSPFv3 Body ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 4 | IHL |Type of Service| Total Length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Identification |Flags| Fragment Offset | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Time to Live | Protocol (89) | Header Checksum | IPv4
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Source Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Destination Address | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Options | Padding | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| 3 | Type | Packet length | ^
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Router ID | OSPFv3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Header
| Area ID | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| Checksum | Instance ID | 0 | v
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ ---
| OSPFv3 Body ... |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Note: "IHL" stands for Internet Header Length.
注：“IHL”代表互联网报头长度。
Figure 1: An IPv4 Packet Encapsulating an OSPFv3 Packet
图1：封装OSPFv3数据包的IPv4数据包
+---------------+
| IPv4 Header |
+---------------+
| OSPFv3 Header |
|...............|
| |
| OSPFv3 Body |
| |
+---------------+
| |
| LLS Data |
| |
+---------------+
+---------------+
| IPv4 Header |
+---------------+
| OSPFv3 Header |
|...............|
| |
| OSPFv3 Body |
| |
+---------------+
| |
| LLS Data |
| |
+---------------+
Figure 2: The IPv4 Packet Encapsulating an OSPFv3 Packet with a Trailing OSPF Link-Local Signaling Data Block
图2:IPv4数据包封装了一个OSPFv3数据包和一个后续OSPF链路本地信令数据块
For OSPFv3 over IPv4, the source address is the primary IPv4 address for the interface over which the packet is transmitted. All OSPFv3 routers on the link should share the same IPv4 subnet for IPv4 transport to function correctly.
对于IPv4上的OSPFv3，源地址是传输数据包的接口的主IPv4地址。链路上的所有OSPFv3路由器应共享相同的IPv4子网，以便IPv4传输正常运行。
While OSPFv2 operates on a subnet, OSPFv3 operates on a link [RFC5340]. Accordingly, an OSPFv3 router implementation MAY support adjacencies with OSPFv3 neighbors on different IPv4 subnets. If this is supported, the IPv4 data plane MUST resolve IPv4 addresses to Layer 2 addresses using ARP on multi-access networks and point-to-point over LAN [RFC5309] for direct next hops on different IPv4 subnets. When OSPFv3 adjacencies on different IPv4 subnets are supported, Bidirectional Forwarding Detection (BFD) [RFC5881] cannot be used for adjacency loss detection since BFD is restricted to a single subnet.
OSPFv2在子网上运行，而OSPFv3在链路上运行[RFC5340]。因此，OSPFv3路由器实现可支持与不同IPv4子网上的OSPFv3邻居的邻接。如果支持此功能，IPv4数据平面必须使用多址网络上的ARP和LAN上的点对点[RFC5309]将IPv4地址解析为第2层地址，以便在不同的IPv4子网上进行直接下一跳。当支持不同IPv4子网上的OSPFv3邻接时，双向转发检测（BFD）[RFC5881]不能用于邻接丢失检测，因为BFD仅限于一个子网。
As defined in OSPFv2, the IPv4 destination address of an OSPF protocol packet is either an IPv4 multicast address or the IPv4 unicast address of an OSPFv2 neighbor. Two well-known link-local multicast addresses are assigned to OSPFv2, the AllSPFRouters address (224.0.0.5) and the AllDRouters address (224.0.0.6). The multicast address used depends on the OSPF packet type, the OSPF interface type, and the OSPF router's role on multi-access networks.
如OSPFv2中所定义，OSPF协议包的IPv4目标地址是IPv4多播地址或OSPFv2邻居的IPv4单播地址。向OSPFv2分配了两个众所周知的链路本地多播地址：AllSPFRouters地址（224.0.0.5）和AllDrooters地址（224.0.0.6）。使用的多播地址取决于OSPF数据包类型、OSPF接口类型以及OSPF路由器在多址网络上的角色。
Thus, for an OSPFv3-over-IPv4 packet to be sent to AllSPFRouters, the destination address field in the IPv4 packet MUST be 224.0.0.5. For an OSPFv3-over-IPv4 packet to be sent to AllDRouters, the destination address field in the IPv4 packet MUST be 224.0.0.6.
因此，要将OSPFv3-over-IPv4数据包发送到所有SPFROUTERS，IPv4数据包中的目标地址字段必须为224.0.0.5。要将OSPFv3-over-IPv4数据包发送到AllDrooter，IPv4数据包中的目标地址字段必须为224.0.0.6。
When an OSPF router sends a unicast OSPF packet over a connected interface, the destination of such an IP packet is the address assigned to the receiving interface. Thus, a unicast OSPFv3 packet transported in an IPv4 packet would specify the OSPFv3 neighbor's IPv4 address as the destination address.
当OSPF路由器通过连接的接口发送单播OSPF分组时，这种IP分组的目的地是分配给接收接口的地址。因此，在IPv4数据包中传输的单播OSPFv3数据包将指定OSPFv3邻居的IPv4地址作为目标地址。
For IPv4 transport, the pseudo-header used in the checksum calculation will contain the IPv4 source and destination addresses, the OSPFv3 protocol ID, and the OSPFv3 length from the OSPFv3 header (Appendix A.3.1 of [RFC5340]). The format is similar to the UDP pseudo-header as described in [RFC768] and is illustrated in Figure 3.
对于IPv4传输，校验和计算中使用的伪报头将包含IPv4源地址和目标地址、OSPFv3协议ID以及来自OSPFv3报头的OSPFv3长度（RFC5340的附录A.3.1）。该格式类似于[RFC768]中描述的UDP伪报头，如图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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Protocol (89) | OSPFv3 Packet 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination Address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 0 | Protocol (89) | OSPFv3 Packet Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Pseudo-header for OSPFv3 over IPv4
图3:IPv4上OSPFv3的伪报头
When an OSPF router sends an OSPF packet over a virtual link, the receiving router might not be directly connected to the sending router. Thus, the destination IP address of the IP packet must be a reachable unicast IP address for the virtual link endpoint. Because IPv6 is the presumed Internet protocol and an IPv4 destination is not routable, the OSPFv3 address family extension [RFC5838] specifies that only virtual links in the IPv6 address family are supported.
当OSPF路由器通过虚拟链路发送OSPF数据包时，接收路由器可能不会直接连接到发送路由器。因此，IP分组的目的地IP地址必须是虚拟链路端点的可到达单播IP地址。由于IPv6是假定的Internet协议，并且IPv4目标不可路由，因此OSPFv3地址系列扩展[RFC5838]指定仅支持IPv6地址系列中的虚拟链路。
As illustrated in Figure 1, this document specifies OSPFv3 transport over IPv4. As a result, OSPFv3 virtual links can be supported with IPv4 address families by simply setting the IPv4 destination address to a reachable IPv4 unicast address for the virtual link endpoint. Hence, the restriction in Section 2.8 of RFC 5838 [RFC5838] is relaxed since virtual links can now be supported for IPv4 address families as long as the transport is also IPv4. If IPv4 transport, as specified herein, is used for IPv6 address families, virtual links cannot be supported. Hence, in OSPF routing domains that require virtual links, the IP transport MUST match the address family (IPv4 or IPv6).
如图1所示，本文档指定了IPv4上的OSPFv3传输。因此，只要将IPv4目标地址设置为虚拟链路端点的可访问IPv4单播地址，IPv4地址族就可以支持OSPFv3虚拟链路。因此，RFC 5838[RFC5838]第2.8节中的限制被放宽，因为只要传输也是IPv4，IPv4地址族现在就可以支持虚拟链路。如果此处指定的IPv4传输用于IPv6地址系列，则无法支持虚拟链路。因此，在需要虚拟链路的OSPF路由域中，IP传输必须与地址系列（IPv4或IPv6）匹配。
Since OSPFv2 [RFC2328] and OSPFv3 over IPv4 as described herein use exactly the same protocol and IPv4 addresses, OSPFv2 packets may be delivered to the OSPFv3 process and vice versa. When this occurs, the mismatched protocol packets will be dropped due to validation of the version in the first octet of the OSPFv2/OSPFv3 protocol header. Note that this will not prevent the packets from being delivered to the correct protocol process as standard socket implementations will deliver a copy to each socket matching the selectors.
由于如本文所述的IPv4上的OSPFv2[RFC2328]和OSPFv3使用完全相同的协议和IPv4地址，因此可以将OSPFv2分组传送到OSPFv3进程，反之亦然。发生这种情况时，由于验证OSPFv2/OSPFv3协议头的第一个八位组中的版本，将丢弃不匹配的协议数据包。请注意，这不会阻止将数据包传递到正确的协议进程，因为标准套接字实现将向与选择器匹配的每个套接字传递一个副本。
Implementations of OSPFv3 over IPv4 transport SHOULD implement separate counters for a protocol mismatch and SHOULD provide means to suppress the ospfIfRxBadPacket and ospfVirtIfRxBadPacket SNMP notifications as described in [RFC4750] and the ospfv3IfRxBadPacket and ospv3VirtIfRxBadPacket SNMP notifications as described in [RFC5643] when an OSPFv2 packet is received by the OSPFv3 process or vice versa.
通过IPv4传输实现OSPFv3应针对协议不匹配实施单独的计数器，并应提供抑制[RFC4750]中所述OSPFIRTIFRXBADPACKET和OSPFIRTIFRXBADPACKET SNMP通知的方法，以及[RFC5643]中所述ospfv3IfRxBadPacket和ospv3VirtIfRxBadPacket SNMP通知的方法当OSPFv3进程接收到OSPFv2数据包时，反之亦然。
OSPFv3 [RFC5340] relies on IPsec [RFC4301] for authentication and confidentiality. "Authentication/Confidentiality in OSPFv3" [RFC4552] specifies how IPsec is used with OSPFv3 over IPv6 transport. In order to use OSPFv3 with IPv4 transport as specified herein, further work such as "Authentication/Confidentiality in OSPFv2" [IPsec-OSPF] would be required.
OSPFv3[RFC5340]依赖IPsec[RFC4301]进行身份验证和保密。“OSPFv3中的身份验证/机密性”[RFC4552]指定IPsec如何通过IPv6传输与OSPFv3一起使用。为了将OSPFv3与本文规定的IPv4传输一起使用，需要进一步的工作，例如“OSPFv2中的身份验证/机密性”[IPsec OSPF]。
An optional OSPFv3 Authentication Trailer [RFC7166] also has been defined as an alternative to using IPsec. The calculation of the authentication data in the Authentication Trailer includes the source IPv6 address to protect an OSPFv3 router from man-in-the-middle attacks. For IPv4 encapsulation as described herein, the IPv4 source address should be placed in the first 4 octets of Apad followed by the hexadecimal value 0x878FE1F3 repeated (L-4)/4 times, where L is the length of the hash measured in octets.
可选的OSPFv3身份验证尾部[RFC7166]也被定义为使用IPsec的替代方案。身份验证尾部中身份验证数据的计算包括源IPv6地址，以保护OSPFv3路由器免受中间人攻击。对于本文所述的IPv4封装，IPv4源地址应置于Apad的前4个八位字节中，后跟十六进制值0x878FE1F3重复（L-4）/4次，其中L是以八位字节为单位测量的哈希长度。
The processing of the optional Authentication Trailer is contained entirely within the OSPFv3 protocol. In other words, each OSPFv3 router instance is responsible for the authentication, without involvement from IPsec or any other IP-layer function. Consequently, except for calculation of the Apad value, transporting OSPFv3 packets using IPv4 does not change the generation or validation of the optional OSPFv3 Authentication Trailer.
可选身份验证尾部的处理完全包含在OSPFv3协议中。换句话说，每个OSPFv3路由器实例负责身份验证，而不涉及IPsec或任何其他IP层功能。因此，除了计算Apad值外，使用IPv4传输OSPFv3数据包不会改变可选OSPFv3认证尾部的生成或验证。
[RFC791] Postel, J., "Internet Protocol", STD 5, RFC 791, DOI 10.17487/RFC0791, September 1981, <http://www.rfc-editor.org/info/rfc791>.
[RFC791]Postel，J.，“互联网协议”，STD 5，RFC 791，DOI 10.17487/RFC07911981年9月<http://www.rfc-editor.org/info/rfc791>.
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，DOI 10.17487/RFC2119，1997年3月<http://www.rfc-editor.org/info/rfc2119>.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, DOI 10.17487/RFC2328, April 1998, <http://www.rfc-editor.org/info/rfc2328>.
[RFC2328]Moy，J.，“OSPF版本2”，STD 54，RFC 2328，DOI 10.17487/RFC2328，1998年4月<http://www.rfc-editor.org/info/rfc2328>.
[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, DOI 10.17487/RFC2460, December 1998, <http://www.rfc-editor.org/info/rfc2460>.
[RFC2460]Deering，S.和R.Hinden，“互联网协议，第6版（IPv6）规范”，RFC 2460，DOI 10.17487/RFC2460，1998年12月<http://www.rfc-editor.org/info/rfc2460>.
[RFC5309] Shen, N., Ed., and A. Zinin, Ed., "Point-to-Point Operation over LAN in Link State Routing Protocols", RFC 5309, DOI 10.17487/RFC5309, October 2008, <http://www.rfc-editor.org/info/rfc5309>.
[RFC5309]Shen，N.，Ed.，和A.Zinin，Ed.，“链路状态路由协议下局域网上的点对点操作”，RFC 5309，DOI 10.17487/RFC5309，2008年10月<http://www.rfc-editor.org/info/rfc5309>.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, DOI 10.17487/RFC5340, July 2008, <http://www.rfc-editor.org/info/rfc5340>.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 5340，DOI 10.17487/RFC5340，2008年7月<http://www.rfc-editor.org/info/rfc5340>.
[RFC5838] Lindem, A., Ed., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, DOI 10.17487/RFC5838, April 2010, <http://www.rfc-editor.org/info/rfc5838>.
[RFC5838]Lindem，A.，Ed.，Mirtorabi，S.，Roy，A.，Barnes，M.，和R.Aggarwal，“OSPFv3中地址家庭的支持”，RFC 5838，DOI 10.17487/RFC5838，2010年4月<http://www.rfc-editor.org/info/rfc5838>.
[IPsec-OSPF] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv2", Work in Progress, draft-gupta-ospf-ospfv2-sec-01, August 2009.
[IPsec OSPF]Gupta，M.和N.Melam，“OSPFv2的认证/保密”，正在进行的工作，草稿-Gupta-OSPF-OSPFv2-sec-012009年8月。
[RFC768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, DOI 10.17487/RFC0768, August 1980, <http://www.rfc-editor.org/info/rfc768>.
[RFC768]Postel，J.，“用户数据报协议”，STD 6，RFC 768，DOI 10.17487/RFC0768，1980年8月<http://www.rfc-editor.org/info/rfc768>.
[RFC826] Plummer, D., "Ethernet Address Resolution Protocol: Or Converting Network Protocol Addresses to 48.bit Ethernet Address for Transmission on Ethernet Hardware", STD 37, RFC 826, DOI 10.17487/RFC0826, November 1982, <http://www.rfc-editor.org/info/rfc826>.
[RFC826]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址以便在以太网硬件上传输”，STD 37，RFC 826，DOI 10.17487/RFC0826，1982年11月<http://www.rfc-editor.org/info/rfc826>.
[RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet Networks", RFC 2464, DOI 10.17487/RFC2464, December 1998, <http://www.rfc-editor.org/info/rfc2464>.
[RFC2464]克劳福德，M.，“通过以太网传输IPv6数据包”，RFC 2464，DOI 10.17487/RFC2464，1998年12月<http://www.rfc-editor.org/info/rfc2464>.
[RFC4271] Rekhter, Y., Ed., Li, T., Ed., and S. Hares, Ed., "A Border Gateway Protocol 4 (BGP-4)", RFC 4271, DOI 10.17487/RFC4271, January 2006, <http://www.rfc-editor.org/info/rfc4271>.
[RFC4271]Rekhter，Y.，Ed.，Li，T.，Ed.，和S.Hares，Ed.，“边境网关协议4（BGP-4）”，RFC 4271，DOI 10.17487/RFC4271，2006年1月<http://www.rfc-editor.org/info/rfc4271>.
[RFC4301] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, DOI 10.17487/RFC4301, December 2005, <http://www.rfc-editor.org/info/rfc4301>.
[RFC4301]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 4301，DOI 10.17487/RFC4301，2005年12月<http://www.rfc-editor.org/info/rfc4301>.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, DOI 10.17487/RFC4552, June 2006, <http://www.rfc-editor.org/info/rfc4552>.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，DOI 10.17487/RFC4552，2006年6月<http://www.rfc-editor.org/info/rfc4552>.
[RFC4750] Joyal, D., Ed., Galecki, P., Ed., Giacalone, S., Ed., Coltun, R., and F. Baker, "OSPF Version 2 Management Information Base", RFC 4750, DOI 10.17487/RFC4750, December 2006, <http://www.rfc-editor.org/info/rfc4750>.
[RFC4750]Joyal，D.，Ed.，Galecki，P.，Ed.，Giacalone，S.，Ed.，Coltun，R.，和F.Baker，“OSPF版本2管理信息库”，RFC 4750，DOI 10.17487/RFC4750，2006年12月<http://www.rfc-editor.org/info/rfc4750>.
[RFC5613] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Yeung, "OSPF Link-Local Signaling", RFC 5613, DOI 10.17487/RFC5613, August 2009, <http://www.rfc-editor.org/info/rfc5613>.
[RFC5613]Zinin，A.，Roy，A.，Nguyen，L.，Friedman，B.，和D.Yeung，“OSPF链路本地信令”，RFC 5613，DOI 10.17487/RFC5613，2009年8月<http://www.rfc-editor.org/info/rfc5613>.
[RFC5643] Joyal, D., Ed., and V. Manral, Ed., "Management Information Base for OSPFv3", RFC 5643, DOI 10.17487/RFC5643, August 2009, <http://www.rfc-editor.org/info/rfc5643>.
[RFC5643]Joyal，D.，Ed.，和V.Manral，Ed.，“OSPFv3的管理信息库”，RFC 5643，DOI 10.17487/RFC5643，2009年8月<http://www.rfc-editor.org/info/rfc5643>.
[RFC5881] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD) for IPv4 and IPv6 (Single Hop)", RFC 5881, DOI 10.17487/RFC5881, June 2010, <http://www.rfc-editor.org/info/rfc5881>.
[RFC5881]Katz，D.和D.Ward，“IPv4和IPv6（单跳）的双向转发检测（BFD）”，RFC 5881，DOI 10.17487/RFC5881，2010年6月<http://www.rfc-editor.org/info/rfc5881>.
[RFC7166] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 7166, DOI 10.17487/RFC7166, March 2014, <http://www.rfc-editor.org/info/rfc7166>.
[RFC7166]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFv3的支持认证拖车”，RFC 7166，DOI 10.17487/RFC7166，2014年3月<http://www.rfc-editor.org/info/rfc7166>.
Acknowledgments
致谢
The authors would like to thank Alexander Okonnikov for his thorough review and valuable feedback and Suresh Krishnan for pointing out that clear specification for the pseudo-header used in the OSPFv3 packet checksum calculation was required. The authors would also like to thank Wenhu Lu for acting as document shepherd.
作者要感谢Alexander Okonnikov的全面审查和宝贵反馈，并感谢Suresh Krishnan指出，OSPFv3数据包校验和计算中使用的伪报头需要明确的规范。作者还想感谢陆文虎担任文件管理员。
Authors' Addresses
作者地址
Ing-Wher Chen Ericsson
陈爱立信
Email: ichen@kuatrotech.com
Email: ichen@kuatrotech.com
Acee Lindem Cisco
安赛林登思科
Email: acee@cisco.com
Email: acee@cisco.com
RJ Atkinson Consultant
RJ阿特金森顾问公司
Email: rja.lists@gmail.com
Email: rja.lists@gmail.com