Internet Engineering Task Force (IETF) A. Lindem, Ed.
Request for Comments: 5838 Ericsson
Category: Standards Track S. Mirtorabi
ISSN: 2070-1721 A. Roy
M. Barnes
Cisco Systems
R. Aggarwal
Juniper Networks
April 2010
Internet Engineering Task Force (IETF) A. Lindem, Ed.
Request for Comments: 5838 Ericsson
Category: Standards Track S. Mirtorabi
ISSN: 2070-1721 A. Roy
M. Barnes
Cisco Systems
R. Aggarwal
Juniper Networks
April 2010
Support of Address Families in OSPFv3
OSPFv3中地址家庭的支持
Abstract
摘要
This document describes a mechanism for supporting multiple address families (AFs) in OSPFv3 using multiple instances. It maps an AF to an OSPFv3 instance using the Instance ID field in the OSPFv3 packet header. This approach is fairly simple and minimizes extensions to OSPFv3 for supporting multiple AFs.
本文档描述了一种使用多个实例支持OSPFv3中多地址族（AFs）的机制。它使用OSPFv3数据包头中的实例ID字段将AF映射到OSPFv3实例。这种方法相当简单，并且最小化了对OSPFv3的扩展，以支持多个AFs。
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/rfc5838.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc5838.
Copyright Notice
版权公告
Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2010 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. Design Considerations . . . . . . . . . . . . . . . . . . 2
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Instance ID Values for New AFs . . . . . . . . . . . . . . 3
2.2. OSPFv3 Options Changes . . . . . . . . . . . . . . . . . . 4
2.3. Advertising Prefixes in AFs Other Than IPv6 . . . . . . . 4
2.4. Changes to the Hello Packet Processing . . . . . . . . . . 4
2.5. Next-Hop Calculation for IPv4 Unicast and Multicast AFs . 5
2.6. AS-External-LSA and NSSA-LSA Forwarding Address for
IPv4 Unicast and IPv4 Multicast AFs . . . . . . . . . . . 5
2.7. Database Description Maximum Transmission Unit (MTU)
Specification for Non-IPv6 AFs . . . . . . . . . . . . . . 6
2.8. Operation over Virtual Links . . . . . . . . . . . . . . . 8
3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. Design Considerations . . . . . . . . . . . . . . . . . . 2
1.2. Requirements Notation . . . . . . . . . . . . . . . . . . 3
2. Protocol Details . . . . . . . . . . . . . . . . . . . . . . . 3
2.1. Instance ID Values for New AFs . . . . . . . . . . . . . . 3
2.2. OSPFv3 Options Changes . . . . . . . . . . . . . . . . . . 4
2.3. Advertising Prefixes in AFs Other Than IPv6 . . . . . . . 4
2.4. Changes to the Hello Packet Processing . . . . . . . . . . 4
2.5. Next-Hop Calculation for IPv4 Unicast and Multicast AFs . 5
2.6. AS-External-LSA and NSSA-LSA Forwarding Address for
IPv4 Unicast and IPv4 Multicast AFs . . . . . . . . . . . 5
2.7. Database Description Maximum Transmission Unit (MTU)
Specification for Non-IPv6 AFs . . . . . . . . . . . . . . 6
2.8. Operation over Virtual Links . . . . . . . . . . . . . . . 8
3. Backward Compatibility . . . . . . . . . . . . . . . . . . . . 8
4. Security Considerations . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9
6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
6.1. Normative References . . . . . . . . . . . . . . . . . . . 11
6.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 12
OSPFv3 [OSPFV3] has been defined to support the base IPv6 unicast address family (AF). There are requirements to advertise other AFs in OSPFv3, including multicast IPv6, unicast IPv4, and multicast IPv4. This document supports these other AFs in OSPFv3 by mapping each AF to a separate Instance ID and OSPFv3 instance.
OSPFv3[OSPFv3]已定义为支持基本IPv6单播地址系列（AF）。在OSPFv3中需要公布其他AFs，包括多播IPv6、单播IPv4和多播IPv4。本文档通过将每个AF映射到单独的实例ID和OSPFv3实例来支持OSPFv3中的这些其他AFs。
This section describes the rationale for using the multiple Instance ID approach to support multiple address families in OSPFv3. As described earlier, OSPFv3 is designed to support multiple instances. Hence, mapping an instance to an address family doesn't introduce any new mechanisms to the protocol. It minimizes the protocol extensions required, and it simplifies the implementation. The presence of a separate link state database per address family is also easier to debug and operate. Additionally, it doesn't change the existing instance, area, and interface-based configuration model in most OSPFv3 implementations.
本节介绍了在OSPFv3中使用多实例ID方法支持多地址族的基本原理。如前所述，OSPFv3设计用于支持多个实例。因此，将实例映射到地址族不会给协议引入任何新机制。它最小化了所需的协议扩展，并简化了实现。每个地址族都有一个单独的链接状态数据库，这也更易于调试和操作。此外，它不会改变大多数OSPFv3实现中现有的基于实例、区域和接口的配置模型。
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-关键词]中所述进行解释。
Currently, the entire Instance ID number space is used for IPv6 unicast. This specification assigns different Instance ID ranges to different AFs in order to support other AFs in OSPFv3. Each Instance ID implies a separate OSPFv3 instance with its own neighbor adjacencies, link state database, protocol data structures, and shortest path first (SPF) computation.
目前，整个实例ID号空间用于IPv6单播。本规范为不同的AFs分配不同的实例ID范围，以支持OSPFv3中的其他AFs。每个实例ID表示一个单独的OSPFv3实例，该实例具有自己的邻居邻接、链路状态数据库、协议数据结构和最短路径优先（SPF）计算。
Additionally, the current Link State Advertisements (LSAs) defined to advertise IPv6 unicast prefixes can be used to advertise prefixes from other AFs without modification.
此外，定义用于播发IPv6单播前缀的当前链路状态播发（LSA）可用于播发来自其他AFs的前缀，而无需修改。
It should be noted that OSPFv3 runs on top of IPv6 and uses IPv6 link local addresses for OSPFv3 control packets. Therefore, it is required that IPv6 be enabled on an OSPFv3 link, although the link may not be participating in any IPv6 AFs.
应该注意的是，OSPFv3运行在IPv6之上，并为OSPFv3控制数据包使用IPv6链路本地地址。因此，要求在OSPFv3链路上启用IPv6，尽管该链路可能不参与任何IPv6 AFs。
Instance ID zero is already defined by default for the IPv6 unicast AF. When this specification is used to support multiple AFs, we define the following ranges for different AFs. The first value of each range is the default value for the corresponding AF.
默认情况下，已为IPv6单播AF定义了实例ID 0。当此规范用于支持多个AFs时，我们为不同的AFs定义以下范围。每个范围的第一个值是对应AF的默认值。
Instance ID # 0 - # 31 IPv6 unicast AF
Instance ID # 32 - # 63 IPv6 multicast AF
Instance ID # 64 - # 95 IPv4 unicast AF
Instance ID # 96 - # 127 IPv4 multicast AF
Instance ID # 128 - # 255 Unassigned
Instance ID # 0 - # 31 IPv6 unicast AF
Instance ID # 32 - # 63 IPv6 multicast AF
Instance ID # 64 - # 95 IPv4 unicast AF
Instance ID # 96 - # 127 IPv4 multicast AF
Instance ID # 128 - # 255 Unassigned
OSPFv3 Instance IDs
OSPFv3实例ID
A new AF-bit is added to the OSPFv3 Options field. The V6-bit is only applicable to the IPv6 unicast AF.
新的AF位添加到OSPFv3选项字段。V6位仅适用于IPv6单播AF。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+-+-+--+
| | | | | | | | | | | | | | | |AF|*|*|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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+-+-+--+
| | | | | | | | | | | | | | | |AF|*|*|DC|R|N|x|E|V6|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+--+-+-+-+-+--+
The Options field
选项字段
OSPFv3 Options
OSPFv3选项
V6-bit The V6-bit is used in OSPFv3 to exclude a node from IPv6 unicast route calculation but allow it in the SPF calculation for other address families. Since the Instance ID now denotes the AF explicitly, this bit is ignored in AFs other than IPv6 unicast.
V6位在OSPFv3中使用V6位从IPv6单播路由计算中排除节点，但允许它在其他地址族的SPF计算中使用。由于实例ID现在显式表示AF，因此在AFs中，除了IPv6单播之外，该位将被忽略。
AF-bit When an OSPFv3 router is supporting AFs as described in this specification, it MUST set the AF-bit in the OSPFv3 Options field of Hello packets, Database Description packets, and LSAs.
AF位当OSPFv3路由器如本规范所述支持AFs时，它必须在Hello数据包、数据库描述数据包和LSA的OSPFv3选项字段中设置AF位。
Each prefix advertised in OSPFv3 has a prefix Length field [OSPFV3]. This facilitates advertising prefixes of different lengths in different AFs. The existing LSAs defined in OSPFv3 are used for this and there is no need to define new LSAs.
OSPFv3中公布的每个前缀都有一个前缀长度字段[OSPFv3]。这有助于在不同的AFs中宣传不同长度的前缀。OSPFv3中定义的现有LSA用于此目的，无需定义新的LSA。
Prefixes that don't conform to the AF of an OSPFv3 instance MUST NOT be used in the route computation for that instance.
不符合OSPFv3实例AF的前缀不得用于该实例的路由计算。
When an OSPFv3 router does not support this specification and it is configured with the corresponding Instance ID, packets could be black holed. This could happen due to misconfiguration or a router software downgrade. Black holing is possible because a router that doesn't support this specification can still be included in the SPF calculated path as long as it establishes adjacencies using the Instance ID corresponding to the AF. Note that Router-LSAs and Network-LSAs are AF independent.
当OSPFv3路由器不支持此规范并且配置了相应的实例ID时，数据包可能会被黑洞。这可能是由于配置错误或路由器软件降级造成的。黑洞是可能的，因为不支持此规范的路由器仍然可以包括在SPF计算路径中，只要它使用对应于AF的实例ID建立邻接。请注意，路由器LSA和网络LSA是AF独立的。
In order to avoid the above situation, Hello packet processing is changed in order to only establish adjacencies with routers that have the AF-bit set in their Options field.
为了避免上述情况，改变Hello分组处理，以便仅与在其选项字段中设置了AF位的路由器建立邻接。
Receiving Hello packets is specified in section 4.2.2.1 of [OSPFV3]. The following check is added to Hello packet reception:
[OSPFV3]第4.2.2.1节规定了接收Hello数据包。以下检查添加到Hello数据包接收：
o When an OSPFv3 router participates in an AF (sets the AF-bit in the Options field), it MUST discard Hello packets having the AF-bit clear in the Options field. The only exception is the Base IPv6 unicast AF, where this check MUST NOT be done (for backward compatibility).
o 当OSPFv3路由器参与AF（在选项字段中设置AF位）时，它必须丢弃在选项字段中清除AF位的Hello数据包。唯一的例外是基本IPv6单播AF，其中不得执行此检查（为了向后兼容性）。
OSPFv3 runs on top of IPv6 and uses IPv6 link local addresses for OSPFv3 control packets and next-hop calculations. Although IPv6 link local addresses could be used as next hops for IPv4 address families, it is desirable to have IPv4 next-hop addresses. For example, in the IPv4 multicast AF, the Protocol Independent Multicast (PIM) [PIM] neighbor address and the next-hop address should both be IPv4 addresses in order for the Reverse Path Forwarding (RPF) lookup to work correctly. Troubleshooting is also easier when the prefix address and next-hop address are in the same AF.
OSPFv3运行在IPv6之上，使用IPv6链路本地地址进行OSPFv3控制数据包和下一跳计算。虽然IPv6链路本地地址可以用作IPv4地址系列的下一个跃点，但最好使用IPv4下一个跃点地址。例如，在IPv4多播AF中，协议独立多播（PIM）[PIM]邻居地址和下一跳地址都应该是IPv4地址，以便反向路径转发（RPF）查找正常工作。当前缀地址和下一跳地址位于同一AF中时，故障排除也更容易。
In order to achieve this, the link's IPv4 address will be advertised in the "link local address" field of the IPv4 instance's Link-LSA. This address is placed in the first 32 bits of the "link local address" field and is used for IPv4 next-hop calculations. The remaining bits MUST be set to zero.
为了实现这一点，将在IPv4实例的链路LSA的“链路本地地址”字段中公布链路的IPv4地址。此地址位于“链路本地地址”字段的前32位，用于IPv4下一跳计算。剩余的位必须设置为零。
We denote a Direct Interface Address (DIA) as an IPv4 or IPv6 address that is both directly reachable via an attached link and has an available layer 3 to layer 2 mapping. Note that there is no explicit need for the IPv4 link addresses to be on the same subnet. An implementation SHOULD resolve layer 3 to layer 2 mappings via the Address Resolution Protocol (ARP) [ARP] or Neighbor Discovery (ND) [ND] for a DIA even if the IPv4 address is not on the same subnet as the router's interface IP address.
我们将直接接口地址（DIA）表示为IPv4或IPv6地址，该地址可通过连接的链路直接访问，并且具有可用的第3层到第2层映射。请注意，IPv4链路地址不需要明确位于同一子网上。实现应通过DIA的地址解析协议（ARP）[ARP]或邻居发现（ND）[ND]解析第3层到第2层的映射，即使IPv4地址与路由器的接口IP地址不在同一子网中。
2.6. AS-External-LSA and NSSA-LSA Forwarding Address for IPv4 Unicast and IPv4 Multicast AFs
2.6. 作为IPv4单播和IPv4多播AFs的外部LSA和NSSA-LSA转发地址
For OSPFv3, this address is an IPv6 host address (128 bits). If included, data traffic for the advertised destination will be forwarded to this address. For IPv4 unicast and IPv4 multicast AFs, the Forwarding Address in AS-external-LSAs and NSSA-LSAs MUST encode an IPv4 address. To achieve this, the IPv4 Forwarding Address is
对于OSPFv3，此地址是IPv6主机地址（128位）。如果包含，则播发目的地的数据流量将转发到此地址。对于IPv4单播和IPv4多播AFs，AS外部LSA和NSSA LSA中的转发地址必须编码IPv4地址。为了实现这一点，IPv4转发地址是
advertised by placing it in the first 32 bits of the Forwarding Address field in AS-external-LSAs and NSSA-LSAs. The remaining bits MUST be set to zero.
通过将其放置在AS外部LSA和NSSA LSA中转发地址字段的前32位来播发。剩余的位必须设置为零。
2.7. Database Description Maximum Transmission Unit (MTU) Specification for Non-IPv6 AFs
2.7. 非IPv6 AFs的数据库描述最大传输单元（MTU）规范
For address families other than IPv6, both the MTU for the instance address family and the IPv6 MTU used for OSPFv3 maximum packet determination MUST be considered. The MTU in the Database Description packet MUST always contain the MTU corresponding to the advertised address family. For example, if the instance corresponds to an IPv4 address family, the IPv4 MTU for the interface MUST be specified in the interface MTU field. As specified in Section 10.6 of [OSPFV2], the Database Description packet will be rejected if the MTU is greater than the receiving interface's MTU for the address family corresponding to the instance. This behavior will assure that an adjacency is not formed and address family specific routes are not installed over a path with conflicting MTUs.
对于IPv6以外的地址系列，必须同时考虑实例地址系列的MTU和用于OSPFv3最大数据包确定的IPv6 MTU。数据库描述数据包中的MTU必须始终包含与播发地址系列对应的MTU。例如，如果实例对应于IPv4地址系列，则必须在接口MTU字段中指定接口的IPv4 MTU。如[OSPFV2]第10.6节所述，如果MTU大于接收接口对应实例的地址族的MTU，则数据库描述数据包将被拒绝。此行为将确保不会形成邻接，并且不会在具有冲突MTU的路径上安装特定于地址族的路由。
The value used for OSPFv3 maximum packet size determination MUST also be compatible for an adjacency to be established. Since only a single MTU field is specified, the M6-bit is defined by this specification. If the M6-bit is clear, the specified MTU SHOULD also be checked against the IPv6 MTU, and the Database Description packet SHOULD be rejected if the MTU is larger than the receiving interface's IPv6 MTU. An OSPFv3 router SHOULD NOT set the M6-bit if its IPv6 MTU and address family specific MTU are the same.
用于OSPFv3最大数据包大小确定的值也必须与要建立的邻接兼容。由于只指定了一个MTU字段，因此本规范定义了M6位。如果M6位已清除，则还应对照IPv6 MTU检查指定的MTU，如果MTU大于接收接口的IPv6 MTU，则应拒绝数据库描述数据包。如果OSPFv3路由器的IPv6 MTU和特定于地址系列的MTU相同，则不应设置M6位。
If the IPv6 and IPv4 MTUs differ, the M6-bit MUST be set for non-IPv6 address families. If the M6-bit is set, the IPv6 MTU is dictated by the presence or absence of an IPv6 MTU TLV in the link-local signaling (LLS) [LLS] block. If this TLV is present, it carries the IPv6 MTU that SHOULD be compared with the local IPv6 MTU. If this TLV is absent, the minimum IPv6 MTU of 1280 octets SHOULD be used for the comparison (refer to [IPV6]).
如果IPv6和IPv4 MTU不同，则必须为非IPv6地址系列设置M6位。如果设置了M6位，则IPv6 MTU取决于链路本地信令（LLS）[LLS]块中是否存在IPv6 MTU TLV。如果存在此TLV，则它携带应与本地IPv6 MTU进行比较的IPv6 MTU。如果没有此TLV，则应使用1280个八位字节的最小IPv6 MTU进行比较（请参阅[IPv6]）。
If the M6-bit is set in a received Database Description packet for a non-IPv6 address family, the receiving router MUST NOT check the Interface MTU in the Database Description packet against the receiving interface's IPv6 MTU.
如果在接收到的非IPv6地址系列的数据库描述数据包中设置了M6位，则接收路由器不得根据接收接口的IPv6 MTU检查数据库描述数据包中的接口MTU。
The figure below graphically depicts the changed fields in octets 20-23 of the OSPFv3 Database Description packet:
下图以图形方式描述了OSPFv3数据库描述数据包的八位字节20-23中的更改字段：
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
| Interface MTU | 0 |0|0|0|M6|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
| Interface MTU | 0 |0|0|0|M6|0|I|M|MS|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+--+-+-+-+--+
OSPFv3 Database Description Packet Changes
OSPFv3数据库描述数据包更改
The changed fields in the Database Description packet are described below. The remaining fields are unchanged from [OSPFV3].
数据库描述数据包中更改的字段如下所述。其余字段与[OSPFV3]相同。
Interface MTU The size in octets of the largest address family specific datagram that can be sent on the associated interface without fragmentation. The MTUs of common Internet link types can be found in Table 7-1 of [MTUDISC]. The Interface MTU SHOULD be set to 0 in Database Description packets sent over virtual links.
接口MTU最大地址系列特定数据报的大小（以八位字节为单位），可在相关接口上发送，无需分段。常见互联网链接类型的MTU可在[MTUDISC]的表7-1中找到。在通过虚拟链接发送的数据库描述数据包中，接口MTU应设置为0。
M6-bit The IPv6 MTU bit - this bit indicates that the sender is using a different IPv6 MTU than the MTU for the AF.
M6位IPv6 MTU位-此位表示发送方使用的IPv6 MTU与AF的MTU不同。
An IPv6 MTU TLV can be optionally carried in an LLS block as described above. This TLV carries the IPv6 MTU for the interface. The length field of the TLV is set to 4 bytes.
如上所述，IPv6 MTU TLV可以可选地在LLS块中承载。此TLV承载接口的IPv6 MTU。TLV的长度字段设置为4字节。
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 17 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 17 | 4 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| IPv6 MTU |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format of IPv6 MTU TLV
IPv6 MTU TLV的格式
Only one instance of the IPv6 MTU TLV MAY appear in the LLS block. Instances subsequent to the first are not processed, and the LLS inconsistency SHOULD be logged.
LLS块中只能出现一个IPv6 MTU TLV实例。不处理第一个实例之后的实例，应记录LLS不一致性。
OSPFv3 control packets sent over a virtual link are IPv6 packets and may traverse multiple hops. Therefore, there MUST be a global IPv6 address associated with the virtual link so that OSPFv3 control packets are forwarded correctly by the intermediate hops between virtual link endpoints. Although this requirement can be satisfied in IPv6 unicast AFs, it will not function in other AFs as there will not be a routable global IPv6 address or forwarding path. Therefore, virtual links are not supported in AFs other than IPv6 unicast.
通过虚拟链路发送的OSPFv3控制数据包是IPv6数据包，可以跨越多个跃点。因此，必须有一个与虚拟链路相关联的全局IPv6地址，以便通过虚拟链路端点之间的中间跳正确转发OSPFv3控制数据包。虽然这一要求可以在IPv6单播AFs中得到满足，但由于没有可路由的全局IPv6地址或转发路径，它在其他AFs中不起作用。因此，除IPv6单播外，AFs中不支持虚拟链路。
All modifications to OSPFv3 apply exclusively to the support of address families other than the IPv6 unicast AF using multiple OSPFv3 instances as described in this specification. These modifications are not applicable to IPv6 unicast topologies and do not preclude future single instance mechanisms for supporting multiple address families.
对OSPFv3的所有修改仅适用于使用多个OSPFv3实例的IPv6单播AF以外的地址族的支持，如本规范所述。这些修改不适用于IPv6单播拓扑，也不排除将来支持多地址族的单实例机制。
In this section, we will define a non-capable OSPFv3 router as one not supporting this specification. When multiple AFs are supported as defined herein, each new AF will have a corresponding Instance ID and can interoperate with the existing non-capable OSPFv3 routers in an IPv6 unicast topology. Furthermore, when a non-capable OSPFv3 router uses an Instance ID that is reserved for a given AF, no adjacency will be formed with this router since the AF-bit in the Options field will be clear in its OSPFv3 Hello packets. Therefore, there are no backward compatibility issues. AFs can be gradually deployed without disturbing OSPFv3 routing domains with non-capable OSPFv3 routers.
在本节中，我们将把不支持OSPFv3的路由器定义为不支持此规范的路由器。当如本文所定义支持多个AF时，每个新AF将具有相应的实例ID，并且可以在IPv6单播拓扑中与现有的不具备能力的OSPFv3路由器进行互操作。此外，当不具备能力的OSPFv3路由器使用为给定AF保留的实例ID时，将不会与该路由器形成邻接，因为选项字段中的AF位将在其OSPFv3 Hello数据包中清除。因此，不存在向后兼容性问题。AFs可以在不干扰OSPFv3路由域的情况下逐步部署，且OSPFv3路由器不具备能力。
IPsec [IPsec] can be used for OSPFv3 authentication and confidentiality as described in [OSPFV3-AUTH]. When multiple OSPFv3 instances use the same interface, they all MUST use the same Security Association (SA), since the SA selectors do not provide selection based on data in OSPFv3 Header fields (e.g., the Instance ID). This restriction is documented in Section 8 of [OSPFV3-AUTH].
IPsec[IPsec]可用于OSPFv3身份验证和机密性，如[OSPFv3-AUTH]所述。当多个OSPFv3实例使用同一接口时，它们都必须使用相同的安全关联（SA），因为SA选择器不提供基于OSPFv3头字段中数据的选择（例如，实例ID）。[OSPFV3-AUH]第8节记录了该限制。
Security considerations for OSPFv3 are covered in [OSPFV3].
[OSPFv3]中介绍了OSPFv3的安全注意事项。
The following IANA assignments were made from existing registries.
以下IANA分配来自现有登记处。
o The AF-bit was assigned from the OSPFv3 Options registry as defined in Section 2.2.
o AF位是根据第2.2节中的定义从OSPFv3选项注册表分配的。
o The M6-bit was assigned from the DD Packet Flags registry as defined in Section 2.7
o M6位是根据第2.7节中的定义从DD数据包标志注册表分配的
o The TLV type (17) for the IPv6 MTU TLV was assigned from the OSPF LLS TLVs registry.
o IPv6 MTU TLV的TLV类型（17）是从OSPF LLS TLV注册表分配的。
IANA created a new registry, "OSPFv3 Instance ID Address Family Values", for assignment of the mapping of OSPFv3 Instance IDs to address families when this specification is used to support multiple address families. Note that the Instance ID field MAY be used for applications other than the support of multiple address families. However, if it is being used for address families as described in this specification, the assignments herein SHOULD be honored.
IANA创建了一个新的注册表“OSPFv3实例ID地址族值”，用于在使用该规范支持多个地址族时，将OSPFv3实例ID映射到地址族。请注意，实例ID字段可用于支持多个地址族以外的应用程序。但是，如果它用于本规范中描述的地址族，则应遵守此处的分配。
+-------------+----------------------+--------------------+
| Value/Range | Designation | Assignment Policy |
+-------------+----------------------+--------------------+
| 0 | Base IPv6 Unicast AF | Already assigned |
| | | |
| 1-31 | IPv6 Unicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 32 | Base IPv6 Multicast | Already assigned |
| | | |
| 33-63 | IPv6 Multicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 64 | Base IPv4 Unicast AF | Already assigned |
| | | |
| 65-95 | IPv4 Unicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 96 | Base IPv4 Multicast | Already assigned |
| | | |
| 97-127 | IPv4 Multicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 128-255 | Unassigned | Standards Action |
+-------------+----------------------+--------------------+
+-------------+----------------------+--------------------+
| Value/Range | Designation | Assignment Policy |
+-------------+----------------------+--------------------+
| 0 | Base IPv6 Unicast AF | Already assigned |
| | | |
| 1-31 | IPv6 Unicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 32 | Base IPv6 Multicast | Already assigned |
| | | |
| 33-63 | IPv6 Multicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 64 | Base IPv4 Unicast AF | Already assigned |
| | | |
| 65-95 | IPv4 Unicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 96 | Base IPv4 Multicast | Already assigned |
| | | |
| 97-127 | IPv4 Multicast AFs | Already assigned |
| | dependent on local | |
| | policy | |
| | | |
| 128-255 | Unassigned | Standards Action |
+-------------+----------------------+--------------------+
OSPFv3 Address Family Use of Instance IDs
OSPFv3解决实例ID的系列使用
o Instance IDs 0-127 are assigned by this specification.
o 实例ID 0-127由该规范分配。
o Instance IDs in the range 128-255 are not assigned at this time. Before any assignments can be made in this range, there MUST be a Standards Track RFC including an IANA Considerations section explicitly specifying the AF Instance IDs being assigned.
o 此时未分配128-255范围内的实例ID。在此范围内进行任何分配之前，必须有一个标准跟踪RFC，包括一个IANA注意事项部分，明确指定分配的AF实例ID。
[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月。
[IPsec] Kent, S. and K. Seo, "Security Architecture for the Internet Protocol", RFC 4301, December 2005.
[IPsec]Kent，S.和K.Seo，“互联网协议的安全架构”，RFC 43012005年12月。
[OSPFV2] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[OSPFV2]Moy，J.，“OSPF版本2”，STD 54，RFC 23281998年4月。
[OSPFV3] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[OSPFV3]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[OSPFV3-AUTH] Gupta, M. and S. Melam, "Authentication/ Confidentiality for OSPFv3", RFC 4552, June 2006.
[OSPFV3-AUTH]Gupta，M.和S.Melam，“OSPFV3的认证/保密”，RFC 45522006年6月。
[RFC-KEYWORDS] Bradner, S., "Key words for use in RFC's to Indicate Requirement Levels", RFC 2119, March 1997.
[RFC-关键词]Bradner，S.，“RFC中用于表示需求水平的关键词”，RFC 211997年3月。
[ARP] 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, November 1982.
[ARP]Plummer，D.，“以太网地址解析协议：或将网络协议地址转换为48位以太网地址，以便在以太网硬件上传输”，STD 37，RFC 826，1982年11月。
[LLS] Zinin, A., Roy, A., Nguyen, L., Friedman, B., and D. Young, "OSPF Link-Local Signaling", RFC 5613, August 2009.
[LLS]Zinin，A.，Roy，A.，Nguyen，L.，Friedman，B.，和D.Young，“OSPF链路本地信令”，RFC 56132009年8月。
[MTUDISC] Mogul, J. and S. Deering, "Path MTU Discovery", RFC 1191, November 1990.
[MTUDISC]Mogul，J.和S.Deering，“MTU发现路径”，RFC191990年11月。
[ND] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
[ND]Narten，T.，Nordmark，E.，Simpson，W.，和H.Soliman，“IP版本6（IPv6）的邻居发现”，RFC 48612007年9月。
[PIM] Fenner, B., Handley, M., Holbrook, H., and I. Kouvelas, "Protocol Independent Multicast - Sparse Mode (PIM-SM): Protocol Specification (Revised)", RFC 4601, August 2006.
[PIM]Fenner，B.，Handley，M.，Holbrook，H.，和I.Kouvelas，“协议独立多播-稀疏模式（PIM-SM）：协议规范（修订版）”，RFC 4601，2006年8月。
The RFC text was produced using Marshall Rose's xml2rfc tool.
RFC文本是使用Marshall Rose的xml2rfc工具生成的。
Thanks to Tom Henderson and the folks at Boeing for implementing this document in the Quagga routing suite, http:www.quagga.net.
感谢Tom Henderson和波音公司的人员在Quagga路由套件http:www.Quagga.net中实现了本文档。
Thanks to Nischal Sheth for review and comments.
感谢Nischal Sheth的审查和评论。
Thanks to Christian Vogt for comments during the Gen-ART review.
感谢Christian Vogt在Gen艺术评论中的评论。
Thanks to Adrian Farrel for comments during the IESG review.
感谢Adrian Farrel在IESG审查期间的评论。
Thanks to Alfred Hoenes for comments during the editing process.
感谢阿尔弗雷德·霍恩斯在编辑过程中的评论。
Authors' Addresses
作者地址
Acee Lindem (editor) Ericsson 102 Carric Bend Court Cary, NC 27519 USA
爱立信102卡里克本德法院卡里，美国北卡罗来纳州27519
EMail: acee.lindem@ericsson.com
EMail: acee.lindem@ericsson.com
Sina Mirtorabi Cisco Systems 3 West Plumeria Drive San Jose, CA 95134 USA
新浪Mirtorabi思科系统3西普洛玛丽亚大道圣何塞，加利福尼亚州95134
EMail: smirtora@cisco.com
EMail: smirtora@cisco.com
Abhay Roy Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞市西塔斯曼大道225号，邮编95134
EMail: akr@cisco.com
EMail: akr@cisco.com
Michael Barnes Cisco Systems 225 West Tasman Drive San Jose, CA 95134 USA
美国加利福尼亚州圣何塞西塔斯曼大道225号，邮编95134
EMail: mjbarnes@cisco.com
EMail: mjbarnes@cisco.com
Rahul Aggarwal Juniper Networks 1194 N. Mathilda Ave. Sunnyvale, CA 94089 USA
Rahul Aggarwal Juniper Networks 1194 N.Mathilda Ave.Sunnyvale，加利福尼亚州94089
EMail: rahul@juniper.net
EMail: rahul@juniper.net