Internet Engineering Task Force (IETF) D. Cheng
Request for Comments: 6992 Huawei Technologies
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
A. Retana
Cisco Systems
July 2013
Internet Engineering Task Force (IETF) D. Cheng
Request for Comments: 6992 Huawei Technologies
Category: Informational M. Boucadair
ISSN: 2070-1721 France Telecom
A. Retana
Cisco Systems
July 2013
Routing for IPv4-Embedded IPv6 Packets
IPv4嵌入式IPv6数据包的路由
Abstract
摘要
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on the methods described in RFCs 6145 and 6052, along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network.
本文档描述了一种路由方案，其中基于RFCs 6145和6052中描述的方法，通过IPv6网络传输IPv4数据包，以及IPv6网络中IPv4嵌入IPv6路由的单独OSPFv3路由表。
Status of This Memo
关于下段备忘
This document is not an Internet Standards Track specification; it is published for informational purposes.
本文件不是互联网标准跟踪规范；它是为了提供信息而发布的。
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). Not all documents approved by the IESG are a candidate for any level of Internet Standard; see Section 2 of RFC 5741.
本文件是互联网工程任务组（IETF）的产品。它代表了IETF社区的共识。它已经接受了公众审查，并已被互联网工程指导小组（IESG）批准出版。并非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/rfc6992.
有关本文件当前状态、任何勘误表以及如何提供反馈的信息，请访问http://www.rfc-editor.org/info/rfc6992.
Copyright Notice
版权公告
Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved.
版权所有（c）2013 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. The Scenario ...............................................3
1.2. Routing Solution per RFC 5565 ..............................4
1.3. An Alternative Routing Solution with OSPFv3 ................4
1.4. OSPFv3 Routing with a Specific Topology ....................6
2. Requirements Language ...........................................7
3. Provisioning ....................................................7
3.1. Deciding on the IPv4-Embedded IPv6 Topology ................7
3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table ...7
4. Translation of IP Packets .......................................8
4.1. Address Translation ........................................8
5. Advertising IPv4-Embedded IPv6 Routes ...........................9
5.1. Advertising IPv4-Embedded IPv6 Routes through an
IPv6 Transit Network .......................................9
5.1.1. Routing Metrics .....................................9
5.1.2. Forwarding Address .................................10
5.2. Advertising IPv4 Addresses into Client Networks ...........10
6. Aggregation on IPv4 Addresses and Prefixes .....................10
7. Forwarding .....................................................10
8. Backdoor Connections ...........................................11
9. Prevention of Loops ............................................11
10. MTU Issues ....................................................11
11. Security Considerations .......................................12
12. Operational Considerations ....................................13
13. Acknowledgements ..............................................14
14. References ....................................................14
14.1. Normative References .....................................14
14.2. Informative References ...................................14
1. Introduction ....................................................2
1.1. The Scenario ...............................................3
1.2. Routing Solution per RFC 5565 ..............................4
1.3. An Alternative Routing Solution with OSPFv3 ................4
1.4. OSPFv3 Routing with a Specific Topology ....................6
2. Requirements Language ...........................................7
3. Provisioning ....................................................7
3.1. Deciding on the IPv4-Embedded IPv6 Topology ................7
3.2. Maintaining a Dedicated IPv4-Embedded IPv6 Routing Table ...7
4. Translation of IP Packets .......................................8
4.1. Address Translation ........................................8
5. Advertising IPv4-Embedded IPv6 Routes ...........................9
5.1. Advertising IPv4-Embedded IPv6 Routes through an
IPv6 Transit Network .......................................9
5.1.1. Routing Metrics .....................................9
5.1.2. Forwarding Address .................................10
5.2. Advertising IPv4 Addresses into Client Networks ...........10
6. Aggregation on IPv4 Addresses and Prefixes .....................10
7. Forwarding .....................................................10
8. Backdoor Connections ...........................................11
9. Prevention of Loops ............................................11
10. MTU Issues ....................................................11
11. Security Considerations .......................................12
12. Operational Considerations ....................................13
13. Acknowledgements ..............................................14
14. References ....................................................14
14.1. Normative References .....................................14
14.2. Informative References ...................................14
This document describes a routing scenario where IPv4 packets are transported over an IPv6 network, based on [RFC6145] and [RFC6052], along with a separate OSPFv3 routing table for IPv4-embedded IPv6 routes in the IPv6 network. This document does not introduce any new IPv6 transition mechanism.
本文档描述了基于[RFC6145]和[RFC6052]通过IPv6网络传输IPv4数据包的路由方案，以及IPv6网络中IPv4嵌入IPv6路由的单独OSPFv3路由表。本文档不介绍任何新的IPv6转换机制。
In this document, the following terminology is used:
本文件使用以下术语：
o An IPv4-embedded IPv6 address denotes an IPv6 address that contains an embedded 32-bit IPv4 address constructed according to the rules defined in [RFC6052].
o IPv4嵌入式IPv6地址表示包含根据[RFC6052]中定义的规则构造的嵌入式32位IPv4地址的IPv6地址。
o IPv4-embedded IPv6 packets are packets of which destination addresses are IPv4-embedded IPv6 addresses.
o IPv4嵌入式IPv6数据包是目标地址为IPv4嵌入式IPv6地址的数据包。
o AFBR (Address Family Border Router) [RFC5565] refers to an edge router that supports both IPv4 and IPv6 address families, but the backbone network it connects to only supports either the IPv4 or IPv6 address family.
o AFBR（地址族边界路由器）[RFC5565]是指同时支持IPv4和IPv6地址族的边缘路由器，但其连接的主干网络仅支持IPv4或IPv6地址族。
o AFXLBR (Address Family Translation Border Router) is defined in this document. It refers to a border router that supports both IPv4 and IPv6 address families located on the boundary of an IPv4- only network and an IPv6-only network and that is capable of performing IP header translation between IPv4 and IPv6 [RFC6145].
o 本文档中定义了AFXLBR（地址族转换边界路由器）。它是指一种边界路由器，它支持IPv4和IPv6地址族，位于仅IPv4网络和仅IPv6网络的边界上，并且能够在IPv4和IPv6之间执行IP头转换[RFC6145]。
Due to exhaustion of public IPv4 addresses, there has been a continuing effort within the IETF to investigate and specify IPv6 transitional techniques. In the course of the transition, it is certain that networks based on IPv4 and IPv6 technologies, respectively, will coexist at least for some time. One such scenario is the interconnection of IPv4-only and IPv6-only networks, and in particular, when an IPv6-only network serves as an interconnection between several segregated IPv4-only networks. In this scenario, IPv4 packets are transported over the IPv6 network between IPv4 networks. In order to forward an IPv4 packet from a source IPv4 network to the destination IPv4 network, IPv4 reachability information must be exchanged between the IPv4 networks via some mechanism.
由于公共IPv4地址耗尽，IETF内部一直在努力调查和指定IPv6过渡技术。在过渡过程中，可以肯定的是，分别基于IPv4和IPv6技术的网络将至少在一段时间内共存。其中一种情况是仅IPv4和仅IPv6网络的互连，特别是当仅IPv6网络充当多个隔离的仅IPv4网络之间的互连时。在这种情况下，IPv4数据包通过IPv6网络在IPv4网络之间传输。为了将IPv4数据包从源IPv4网络转发到目标IPv4网络，必须通过某种机制在IPv4网络之间交换IPv4可达性信息。
In general, running an IPv6-only network would reduce operational expenditures and optimize operations as compared to an IPv4-IPv6 dual-stack environment. Some proposed solutions allow the delivery of IPv4 services over an IPv6-only network. This document specifies an engineering technique that separates the routing table dedicated to IPv4-embedded IPv6 destinations from the routing table used for native IPv6 destinations.
一般来说，与IPv4-IPv6双栈环境相比，运行纯IPv6网络将减少运营开支并优化运营。一些建议的解决方案允许通过仅限IPv6的网络提供IPv4服务。本文档指定了一种工程技术，该技术将专用于IPv4嵌入式IPv6目标的路由表与用于本机IPv6目标的路由表分开。
OSPFv3 is designed to support multiple instances. Maintaining a separate routing table for IPv4-embedded IPv6 routes would simplify implementation, troubleshooting, and operation; it would also prevent overload of the native IPv6 routing table. A separate routing table can be generated from a separate routing instance.
OSPFv3旨在支持多个实例。为IPv4嵌入式IPv6路由维护单独的路由表将简化实现、故障排除和操作；它还可以防止本机IPv6路由表过载。可以从单独的路由实例生成单独的路由表。
The aforementioned scenario is described in [RFC5565], i.e., the IPv4-over-IPv6 scenario, where the network core is IPv6-only and the interconnected IPv4 networks are called IPv4 client networks. The P Routers (Provider Routers) in the core only support IPv6, but the AFBRs support IPv4 on interfaces facing IPv4 client networks and IPv6 on interfaces facing the core. The routing solution defined in [RFC5565] for this scenario is to run IBGP among AFBRs to exchange IPv4 routing information in the core, and the IPv4 packets are forwarded from one IPv4 client network to the other through a softwire using tunneling technology, such as MPLS, LSP, GRE, L2TPv3, etc.
[RFC5565]中描述了上述场景，即IPv4-over-IPv6场景，其中网络核心仅为IPv6，互连的IPv4网络称为IPv4客户端网络。核心中的P路由器（提供商路由器）仅支持IPv6，但AFBR在面向IPv4客户端网络的接口上支持IPv4，在面向核心的接口上支持IPv6。[RFC5565]中针对该场景定义的路由解决方案是在AFBR之间运行IBGP，以在核心中交换IPv4路由信息，并使用隧道技术（如MPLS、LSP、GRE、L2TPv3等）通过软线将IPv4数据包从一个IPv4客户端网络转发到另一个IPv4客户端网络。
In this document, we propose an alternative routing solution for the scenario described in Section 1.1 where several segregated IPv4 networks, called IPv4 client networks, are interconnected by an IPv6 network. The IPv6 network and the interconnected IPv4 networks may or may not belong to the same Autonomous System (AS). We refer to the border node on the boundary of an IPv4 client network and the IPv6 network as an Address Family Translation Border Router (AFXLBR), which supports both the IPv4 and IPv6 address families and is capable of translating an IPv4 packet to an IPv6 packet, and vice versa, according to [RFC6145]. The described scenario is illustrated in Figure 1.
在本文档中，我们为第1.1节中描述的场景提出了一种替代路由解决方案，其中多个分离的IPv4网络（称为IPv4客户端网络）通过IPv6网络互连。IPv6网络和互连的IPv4网络可能属于也可能不属于同一自治系统（AS）。根据[RFC6145]，我们将IPv4客户端网络和IPv6网络边界上的边界节点称为地址族转换边界路由器（AFXLBR），它支持IPv4和IPv6地址族，能够将IPv4数据包转换为IPv6数据包，反之亦然。所描述的场景如图1所示。
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client |----| |----| Client |
| Network| | IPv6 | | Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client |----| |----| Client |
| Network| | IPv6 | | Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1: Segregated IPv4 Networks Interconnected by an IPv6 Network
图1：由IPv6网络互连的隔离IPv4网络
Since the scenario occurs most commonly within an organization, an IPv6 prefix can be locally allocated and used by AFXLBRs to construct IPv4-embedded IPv6 addresses [RFC6052]. The embedded IPv4 address or prefix belongs to an IPv4 client network that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and it also installs IPv4-embedded IPv6 routes advertised by other AFXLBRs.
由于这种情况最常见于组织内部，因此可以在本地分配IPv6前缀，并由AFXLBR用于构造IPv4嵌入IPv6地址[RFC6052]。嵌入的IPv4地址或前缀属于连接到AFXLBR的IPv4客户端网络。AFXLBR使用OSPFv3将IPv4嵌入式IPv6地址和前缀注入IPv6网络，并安装由其他AFXLBR播发的IPv4嵌入式IPv6路由。
When an AFXLBR receives an IPv4 packet from a locally connected IPv4 client network destined to a remote IPv4 client network, it translates the IPv4 header to the relevant IPv6 header [RFC6145], and in that process, the source and destination IPv4 addresses are translated into IPv4-embedded IPv6 addresses, respectively [RFC6052]. The resulting IPv6 packet is then forwarded to the AFXLBR that connects to the destination IPv4 client network. The remote AFXLBR derives the IPv4 source and destination addresses from the IPv4- embedded IPv6 addresses, respectively [RFC6052], and translates the header of the received IPv6 packet to the relevant IPv4 header [RFC6145]. The resulting IPv4 packet is then forwarded according to the IPv4 routing table maintained on the AFXLBR.
当AFXLBR从本地连接的IPv4客户端网络接收到目的地为远程IPv4客户端网络的IPv4数据包时，它将IPv4报头转换为相关IPv6报头[RFC6145]，在此过程中，源和目标IPv4地址分别转换为IPv4嵌入IPv6地址[RFC6052]。然后，生成的IPv6数据包被转发到连接到目标IPv4客户端网络的AFXLBR。远程AFXLBR分别从IPv4嵌入的IPv6地址[RFC6052]派生IPv4源地址和目标地址，并将接收到的IPv6数据包的报头转换为相关的IPv4报头[RFC6145]。然后根据AFXLBR上维护的IPv4路由表转发生成的IPv4数据包。
There are use cases where the proposed routing solution is useful. One case is that some border nodes do not participate in IBGP for the exchange of routes, or IBGP is not used at all. Another case is when tunnels are not deployed in the IPv6 network, or native IPv6 forwarding is preferred. Note that with this routing solution, the IPv4 and IPv6 header translation performed in both directions by the AFXLBR is stateless.
在一些用例中，建议的路由解决方案是有用的。一种情况是，一些边界节点不参与交换路由的IBGP，或者根本不使用IBGP。另一种情况是，IPv6网络中未部署隧道，或者首选本机IPv6转发。请注意，使用此路由解决方案，AFXLBR在两个方向上执行的IPv4和IPv6头转换是无状态的。
In general, IPv4-embedded IPv6 packets can be forwarded just like native IPv6 packets with OSPFv3 running in the IPv6 network. However, this would require that IPv4-embedded IPv6 routes be flooded throughout the entire IPv6 network and stored on every router. This is not desirable from a scaling perspective. Moreover, since all IPv6 routes are stored in the same routing table, it would be inconvenient to manage the resource required for routing and forwarding based on traffic category, if so desired.
通常，IPv4嵌入的IPv6数据包可以像在IPv6网络中运行OSPFv3的本机IPv6数据包一样进行转发。然而，这将要求IPv4嵌入式IPv6路由遍布整个IPv6网络，并存储在每个路由器上。从缩放角度来看，这是不可取的。此外，由于所有IPv6路由都存储在同一个路由表中，因此如果需要，将不方便根据流量类别管理路由和转发所需的资源。
To improve the situation, a separate OSPFv3 routing table dedicated to the IPv4-embedded IPv6 topology can be constructed; that table would be solely used for routing IPv4-embedded IPv6 packets in the IPv6 network. The IPv4-embedded IPv6 topology includes all the participating AFXLBRs and a set of P Routers providing redundant connectivity with alternate routing paths.
为了改善这种情况，可以构建专用于IPv4嵌入式IPv6拓扑的单独OSPFv3路由表；该表将仅用于在IPv6网络中路由IPv4嵌入的IPv6数据包。IPv4嵌入式IPv6拓扑包括所有参与的AFXLBR和一组提供备用路由路径冗余连接的P路由器。
To realize this, a separate OSPFv3 instance is configured in the IPv6 network [RFC5838]. This instance operates on all participating AFXLBRs and a set of P routers that interconnect them. As a result, there would be a dedicated IPv4-embedded IPv6 topology that is maintained on all these routers, along with a dedicated IPv4-embedded IPv6 routing table. This routing table in the IPv6 network is solely for forwarding IPv4-embedded IPv6 packets.
为了实现这一点，在IPv6网络[RFC5838]中配置了一个单独的OSPFv3实例。此实例在所有参与的AFXLBR和一组互连它们的P路由器上运行。因此，将在所有这些路由器上维护专用的IPv4嵌入式IPv6拓扑，以及专用的IPv4嵌入式IPv6路由表。IPv6网络中的此路由表仅用于转发IPv4嵌入的IPv6数据包。
This document elaborates on how configuration is done with this method and on related routing issues.
本文档详细介绍了如何使用此方法进行配置以及相关的路由问题。
This document only focuses on unicast routing for IPv4-embedded IPv6 packets using OSPFv3.
本文档仅关注使用OSPFv3的IPv4嵌入式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]中所述进行解释。
Before deploying configurations that use a separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and prefixes, a decision must be made regarding the set of routers and their interfaces in the IPv6 network that should be part of the IPv4-embedded IPv6 topology.
在部署将单独的OSPFv3路由表用于IPv4嵌入式IPv6地址和前缀的配置之前，必须决定IPv6网络中应属于IPv4嵌入式IPv6拓扑的路由器集及其接口。
For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that connect to IPv4 client networks MUST be members of this topology. An AFXLBR MUST have at least one connection with a P Router in the IPv6 network or another AFXLBR.
对于此IPv4嵌入式IPv6拓扑，连接到IPv4客户端网络的所有AFXLBR都必须是此拓扑的成员。AFXLBR必须至少与IPv6网络中的P路由器或其他AFXLBR建立一个连接。
The IPv4-embedded IPv6 topology is a subtopology of the entire IPv6 network, and if all routers (including AFXLBRs and P routers) and all their interfaces are included, the two topologies converge. Generally speaking, when this subtopology contains more interconnected P Routers, there would be more routing paths across the IPv6 network from one IPv4 client network to the other; however, this requires more routers in the IPv6 network to participate in IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6 topology MUST be continuous with no partitions.
IPv4嵌入式IPv6拓扑是整个IPv6网络的子拓扑，如果包括所有路由器（包括AFXLBR和P路由器）及其所有接口，则这两种拓扑将聚合。一般来说，当此子策略包含更多互连的P路由器时，IPv6网络中从一个IPv4客户端网络到另一个IPv4客户端网络的路由路径将更多；但是，这需要IPv6网络中的更多路由器参与IPv4嵌入式IPv6路由。在任何情况下，IPv4嵌入式IPv6拓扑必须是连续的，没有分区。
In an IPv6 network, in order to maintain a separate IPv6 routing table that contains routes for IPv4-embedded IPv6 destinations only, OSPFv3 needs to use the mechanism defined in [RFC5838].
在IPv6网络中，为了维护仅包含IPv4嵌入式IPv6目的地路由的单独IPv6路由表，OSPFv3需要使用[RFC5838]中定义的机制。
It is assumed that the IPv6 network that is interconnected with IPv4 networks as described in this document is under one administration, and as such an OSPFv3 Instance ID (IID) is allocated locally and used for OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing in an IPv6 network. This IID is configured on OSPFv3 router interfaces that participate in the IPv4-embedded IPv6 topology.
假设如本文档所述，与IPv4网络互连的IPv6网络处于一个管理之下，因此，OSPFv3实例ID（IID）在本地分配，并用于专用于IPv6网络中单播IPv4嵌入式IPv6路由的OSPFv3操作。此IID在参与IPv4嵌入式IPv6拓扑的OSPFv3路由器接口上配置。
A locally configured OSPFv3 IID is allocated in the range 192 to 255, inclusive, in the "OSPFv3 Instance ID Address Family Values" registry; this range is reserved for "Private Use" [RFC6969]. This IID must be used to encode the "Instance ID" field in the packet header of OSPFv3 packets associated with the OSPFv3 instance.
本地配置的OSPFv3 IID在“OSPFv3实例ID地址系列值”注册表中的分配范围为192到255（含192到255）；此范围保留供“私人使用”[RFC6969]。此IID必须用于编码与OSPFv3实例关联的OSPFv3数据包头中的“实例ID”字段。
In addition, the AF-bit in the OSPFv3 Option field MUST be set.
此外，必须设置OSPFv3选项字段中的AF位。
During Hello packet processing, an adjacency may only be established when the received Hello packet contains the same Instance ID as the Instance ID configured on the receiving OSPFv3 interface. This insures that only interfaces configured as part of the OSPFv3 unicast IPv4-embedded IPv6 topology are used for IPv4-embedded IPv6 unicast routing.
在Hello分组处理期间，仅当接收到的Hello分组包含与在接收OSPFv3接口上配置的实例ID相同的实例ID时，才能建立邻接。这确保只有配置为OSPFv3单播IPv4嵌入式IPv6拓扑的一部分的接口用于IPv4嵌入式IPv6单播路由。
For more details, the reader is referred to [RFC5838].
有关更多详细信息，请参阅[RFC5838]。
When transporting IPv4 packets across an IPv6 network via the mechanism described above (Section 3.2), an IPv4 packet is translated to an IPv6 packet at the ingress AFXLBR, and the IPv6 packet is translated back to an IPv4 packet at the egress AFXLBR. IP packet header translation is accomplished in a stateless manner according to rules specified in [RFC6145]; the details of address translation are explained in the next subsection.
当通过上述机制（第3.2节）在IPv6网络上传输IPv4数据包时，IPv4数据包在入口AFXLBR处转换为IPv6数据包，IPv6数据包在出口AFXLBR处转换回IPv4数据包。根据[RFC6145]中规定的规则，以无状态方式完成IP数据包头转换；地址翻译的细节将在下一小节中解释。
Prior to address translation, an IPv6 prefix is allocated by the operator, and it is used to form IPv4-embedded IPv6 addresses.
在地址转换之前，运营商会分配一个IPv6前缀，用于形成IPv4嵌入式IPv6地址。
The IPv6 prefix can either be the IPv6 well-known prefix (WKP) 64: ff9b::/96 or a network-specific prefix that is unique to the organization; for the latter case, the IPv6 prefix length may be 32, 40, 48, 56, or 64. In either case, this IPv6 prefix is used during the address translation between an IPv4 address and an IPv4-embedded IPv6 address, as described in [RFC6052].
IPv6前缀可以是IPv6知名前缀（WKP）64:ff9b:：/96，也可以是组织特有的网络特定前缀；对于后一种情况，IPv6前缀长度可以是32、40、48、56或64。在任何一种情况下，在IPv4地址和IPv4嵌入IPv6地址之间的地址转换过程中都会使用此IPv6前缀，如[RFC6052]中所述。
During translation from an IPv4 header to an IPv6 header at an ingress AFXLBR, the source IPv4 address and destination IPv4 address are translated into the corresponding source IPv6 address and destination IPv6 address, respectively. During translation from an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 address and destination IPv6 address are translated into the corresponding source IPv4 address and destination IPv4 address, respectively. Note that address translation is accomplished in a stateless manner.
在入口AFXLBR处从IPv4标头转换为IPv6标头的过程中，源IPv4地址和目标IPv4地址将分别转换为相应的源IPv6地址和目标IPv6地址。在出口AFXLBR处从IPv6标头转换为IPv4标头期间，源IPv6地址和目标IPv6地址分别转换为相应的源IPv4地址和目标IPv4地址。请注意，地址转换是以无状态方式完成的。
When an IPv6 WKP is used, [RFC6052] allows only global IPv4 addresses to be embedded in the IPv6 address. An IPv6 address composed of a WKP and a non-global IPv4 address is hence invalid, and packets that contain such an address received by an AFXLBR are dropped.
使用IPv6 WKP时，[RFC6052]只允许在IPv6地址中嵌入全局IPv4地址。因此，由WKP和非全局IPv4地址组成的IPv6地址无效，包含AFXLBR接收的地址的数据包将被丢弃。
In the case where both the IPv4 client networks and the IPv6 transit network belong to the same organization, non-global IPv4 addresses may be used with a network-specific prefix [RFC6052].
在IPv4客户端网络和IPv6传输网络都属于同一组织的情况下，非全局IPv4地址可与网络特定前缀[RFC6052]一起使用。
In order to forward IPv4 packets to the proper destination across an IPv6 network, IPv4 reachability information needs to be disseminated throughout the IPv6 network. This is performed by AFXLBRs that connect to IPv4 client networks using OSPFv3.
为了通过IPv6网络将IPv4数据包转发到正确的目的地，需要在整个IPv6网络中传播IPv4可达性信息。这是由使用OSPFv3连接到IPv4客户端网络的AFXLBR执行的。
With the scenario described in this document, i.e., a set of AFXLBRs that interconnect multiple IPv4 client networks with an IPv6 network, the IPv4 networks and IPv6 networks belong to the same or separate Autonomous Systems (ASs), and as such, these AFXLBRs behave as AS Boundary Routers (ASBRs).
对于本文档中描述的场景，即一组将多个IPv4客户端网络与IPv6网络互连的AFXLBR，IPv4网络和IPv6网络属于相同或单独的自治系统（ASs），因此，这些AFXLBR的行为类似于边界路由器（ASBR）。
5.1. Advertising IPv4-Embedded IPv6 Routes through an IPv6 Transit Network
5.1. 通过IPv6传输网络发布IPv4嵌入IPv6路由
IPv4 addresses and prefixes in an IPv4 client network are translated into IPv4-embedded IPv6 addresses and prefixes, respectively, using the IPv6 prefix allocated by the operator and the method specified in [RFC6052]. These routes are then advertised by one or more attached ASBRs into the IPv6 transit network using AS-External-LSAs [RFC5340], i.e., with advertising scope comprising the entire Autonomous System.
IPv4客户端网络中的IPv4地址和前缀分别使用运营商分配的IPv6前缀和[RFC6052]中指定的方法转换为IPv4嵌入式IPv6地址和前缀。然后，一个或多个连接的ASBR使用外部LSA[RFC5340]将这些路由播发到IPv6传输网络中，即，播发范围包括整个自治系统。
By default, the metric in an AS-External-LSA that carries an IPv4- embedded IPv6 address or prefixes is a Type 1 external metric, which is comparable to the link state metric, and we assume that in most cases OSPFv2 is used in client IPv4 networks. This metric is added to the metric of the intra-AS path to the ASBR during the OSPFv3 route calculation. Through ASBR configuration, the metric can be set to a Type 2 external metric, which is considered much larger than the metric for any intra-AS path. Refer to the OSPFv3 specification [RFC5340] for more details. In either case, an external metric may take the same value as in an IPv4 network (using OSPFv2 or another routing protocol) but may also be specified based on some routing policy, the details of which are beyond the scope of this document.
默认情况下，承载IPv4嵌入IPv6地址或前缀的AS外部LSA中的度量是类型1外部度量，与链路状态度量相当，我们假设在大多数情况下，客户端IPv4网络中使用OSPFv2。在OSPFv3路由计算期间，该度量被添加到ASBR的AS内路径的度量中。通过ASBR配置，可以将度量设置为类型2外部度量，这被认为比任何内部AS路径的度量大得多。有关更多详细信息，请参阅OSPFv3规范[RFC5340]。在这两种情况下，外部度量可能采用与IPv4网络中相同的值（使用OSPFv2或其他路由协议），但也可能基于某些路由策略进行指定，其详细信息超出了本文档的范围。
If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is used to carry an IPv6 address, that address must also be an IPv4-embedded IPv6 address where the embedded IPv4 address is the destination address in an IPv4 client network. However, since an AFXLBR sits on the border of an IPv4 network and an IPv6 network, it is RECOMMENDED that the "Forwarding Address" field not be used, so that the AFXLBR can make the forwarding decision based on its own IPv4 routing table.
如果将OSPFv3作为外部LSA的“转发地址”字段用于承载IPv6地址，则该地址还必须是IPv4嵌入式IPv6地址，其中嵌入式IPv4地址是IPv4客户端网络中的目标地址。但是，由于AFXLBR位于IPv4网络和IPv6网络的边界上，因此建议不要使用“转发地址”字段，以便AFXLBR可以根据其自己的IPv4路由表做出转发决策。
IPv4-embedded IPv6 routes injected into the IPv6 network from one IPv4 client network MAY be advertised into another IPv4 client network after the associated destination addresses and prefixes are translated back to IPv4 addresses and prefixes, respectively. This operation is similar to normal OSPFv3 operation, wherein an AS-External-LSA can be advertised in a non-backbone area by default.
在关联的目标地址和前缀分别转换回IPv4地址和前缀后，从一个IPv4客户机网络注入IPv6网络的IPv4嵌入式IPv6路由可以播发到另一个IPv4客户机网络。此操作类似于正常的OSPFv3操作，其中默认情况下，AS外部LSA可以在非主干区域中播发。
An IPv4 client network can limit which advertisements it receives through configuration.
IPv4客户端网络可以通过配置限制接收哪些播发。
For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT be advertised into any IPv6 client networks that are also connected to the IPv6 transit network.
在本文档中，IPv4嵌入式IPv6路由不得播发到也连接到IPv6传输网络的任何IPv6客户端网络。
In order to reduce the amount of Link State Advertisements (LSAs) that are injected into the IPv6 network, an implementation should provide mechanisms to aggregate IPv4 addresses and prefixes at an AFXLBR prior to advertisement as IPv4-embedded IPv6 addresses and prefixes. In general, the aggregation practice should be based on routing policy, which is beyond the scope of this document.
为了减少注入IPv6网络的链路状态播发（LSA）数量，实现应提供在播发之前将AFXLBR处的IPv4地址和前缀聚合为IPv4嵌入IPv6地址和前缀的机制。一般来说，聚合实践应基于路由策略，这超出了本文档的范围。
There are three cases applicable to forwarding IP packets in the scenario described in this document:
在本文档描述的场景中，有三种情况适用于转发IP数据包：
1. On an AFXLBR, if an IPv4 packet is received on an interface connecting to an IPv4 segregated client network with a destination IPv4 address belonging to another IPv4 client network, the header of the packet is translated to the corresponding IPv6 header as described in Section 4, and the packet is then forwarded to the destination AFXLBR that advertised the IPv4-embedded IPv6 address into the IPv6 network.
1. 在AFXLBR上，如果在连接到目标IPv4地址属于另一个IPv4客户端网络的IPv4隔离客户端网络的接口上接收到IPv4数据包，则该数据包的报头将转换为第4节中所述的相应IPv6报头，然后，数据包被转发到目标AFXLBR，该目标AFXLBR将IPv4嵌入的IPv6地址播发到IPv6网络中。
2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the embedded destination IPv4 address is in its IPv4 routing table, the header of the packet is translated to the corresponding IPv4 header as described in Section 4, and the packet is then forwarded accordingly.
2. 在AFXLBR上，如果接收到IPv4嵌入式IPv6数据包，且嵌入式目标IPv4地址位于其IPv4路由表中，则数据包的报头将转换为第4节中所述的相应IPv4报头，然后相应地转发数据包。
3. On any router that is within the IPv4-embedded IPv6 topology subset of the IPv6 network, if an IPv4-embedded IPv6 packet is received and a route is found in the IPv4-embedded IPv6 routing table, the packet is forwarded to the IPv6 next hop, just like the handling for a normal IPv6 packet, without any translation.
3. 在IPv6网络的IPv4嵌入式IPv6拓扑子集内的任何路由器上，如果接收到IPv4嵌入式IPv6数据包并且在IPv4嵌入式IPv6路由表中找到路由，则该数据包将转发到IPv6下一跳，就像处理普通IPv6数据包一样，不进行任何转换。
The classification of an IPv4-embedded IPv6 packet is done according to the IPv6 prefix of the destination address, which is either the WKP (i.e., 64:ff9b::/96) or locally allocated as defined in [RFC6052].
IPv4嵌入式IPv6数据包的分类根据目标地址的IPv6前缀完成，该前缀为WKP（即64:ff9b:：/96）或按照[RFC6052]中的定义本地分配。
In some deployments, IPv4 client networks are interconnected across the IPv6 network but are also directly connected to each other. The direct connections between IPv4 client networks, sometimes called "backdoor" connections, can certainly be used to transport IPv4 packets between IPv4 client networks. In general, backdoor connections are preferred over the IPv6 network, since no address family translation is required.
在某些部署中，IPv4客户端网络跨IPv6网络互连，但也相互直接连接。IPv4客户端网络之间的直接连接（有时称为“后门”连接）当然可以用于在IPv4客户端网络之间传输IPv4数据包。通常情况下，IPv6网络首选后门连接，因为不需要地址族转换。
If an LSA sent from an AFXLBR into a client network could then be received by another AFXLBR, it would be possible for routing loops to occur. To prevent loops, an AFXLBR MUST set the DN bit [RFC4576] in any LSA that it sends to a client network. The AFXLBR MUST also ignore any LSA received from a client network that already has the DN bit set.
如果从AFXLBR发送到客户机网络的LSA可以被另一个AFXLBR接收，则可能会发生路由循环。为了防止循环，AFXLBR必须在发送到客户端网络的任何LSA中设置DN位[RFC4576]。AFXLBR还必须忽略从已经设置了DN位的客户端网络接收的任何LSA。
In the IPv6 network, there are no new MTU issues introduced by this document. If a separate OSPFv3 instance (per [RFC5838]) is used for IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is the same as that of the default OSPFv3 instance.
在IPv6网络中，本文档没有引入新的MTU问题。如果单独的OSPFv3实例（根据[RFC5838]）用于IPv4嵌入式IPv6路由，则IPv6网络中的MTU处理与默认OSPFv3实例相同。
However, the MTU in the IPv6 network may be different than that of IPv4 client networks. Since an IPv6 router will never fragment a packet, the packet size of any IPv4-embedded IPv6 packet entering the IPv6 network must be equal to or less than the MTU of the IPv6 network. In order to achieve this requirement, it is recommended
但是，IPv6网络中的MTU可能不同于IPv4客户端网络中的MTU。由于IPv6路由器不会对数据包进行分段，因此进入IPv6网络的任何IPv4嵌入式IPv6数据包的数据包大小必须等于或小于IPv6网络的MTU。为了达到这一要求，建议
that AFXLBRs perform IPv6 path discovery among themselves. The resulting MTU, after taking into account the difference between the IPv4 header length and the IPv6 header length, must be "propagated" into IPv4 client networks, e.g., included in the OSPFv2 Database Description packet.
AFXLBR在它们之间执行IPv6路径发现。在考虑IPv4报头长度和IPv6报头长度之间的差异后，产生的MTU必须“传播”到IPv4客户端网络，例如，包括在OSPFv2数据库描述数据包中。
The details of passing the proper MTU into IPv4 client networks are beyond the scope of this document.
将正确的MTU传递到IPv4客户端网络的详细信息超出了本文档的范围。
There are several security aspects that require attention in the deployment practices described in this document.
在本文档中描述的部署实践中，有几个安全方面需要注意。
In the OSPFv3 transit network, the security considerations for OSPFv3 are handled as usual, and in particular, authentication mechanisms described in [RFC6506] can be deployed.
在OSPFv3传输网络中，OSPFv3的安全注意事项照常处理，特别是可以部署[RFC6506]中描述的认证机制。
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 routing, the same Security Association (SA) [RFC4552] MUST be used by the embedded IPv4 address instance as other instances utilizing the same link, as specified in [RFC5838].
当使用单独的OSPFv3实例支持IPv4嵌入式IPv6路由时，嵌入式IPv4地址实例必须使用与使用相同链路的其他实例相同的安全关联（SA）[RFC4552]，如[RFC5838]中所述。
Security considerations as documented in [RFC6052] must also be thought through and properly implemented, including the following:
还必须仔细考虑并正确实施[RFC6052]中记录的安全注意事项，包括以下内容：
o The IPv6 prefix that is used to carry an embedded IPv4 address (refer to Section 4.1) must be configured by the authorized operator on all participating AFXLBRs in a secure manner. This is to help prevent a malicious attack resulting in network disruption, denial of service, and possible information disclosure.
o 用于承载嵌入式IPv4地址的IPv6前缀（请参阅第4.1节）必须由授权运营商以安全的方式在所有参与的AFXLBR上进行配置。这有助于防止恶意攻击导致网络中断、拒绝服务和可能的信息泄露。
o Effective mechanisms (such as reverse path checking) must be implemented in the IPv6 transit network (including AFXLBRs) to prevent spoofing of embedded IPv4 addresses, which otherwise might be used as source addresses of malicious packets.
o 必须在IPv6传输网络（包括AFXLBR）中实施有效的机制（如反向路径检查），以防止对嵌入式IPv4地址的欺骗，否则这些地址可能被用作恶意数据包的源地址。
o If firewalls are used in IPv4 and/or IPv6 networks, configuration of the routers must be consistent, so that there are no holes in IPv4 address filtering.
o 若在IPv4和/或IPv6网络中使用防火墙，则路由器的配置必须一致，以便IPv4地址过滤中不存在漏洞。
The details of security handling are beyond the scope of this document.
安全处理的细节超出了本文件的范围。
This document puts together some mechanisms based on existing technologies developed by the IETF as an integrated solution to transport IPv4 packets over an IPv6 network using a separate OSPFv3 routing table. There are several aspects of these mechanisms that require attention for deployment and operation.
本文档将IETF开发的基于现有技术的一些机制整合在一起，作为使用单独的OSPFv3路由表在IPv6网络上传输IPv4数据包的集成解决方案。这些机制有几个方面需要注意部署和操作。
The tunnel-based solution documented in [RFC5565] and the solution proposed in this document are both used for transporting IPv4 packets over an IPv6 network, using different mechanisms. The two methods are not related to each other, and they can coexist in the same network if so deployed, without any conflict.
[RFC5565]中介绍的基于隧道的解决方案和本文档中提出的解决方案都用于使用不同的机制通过IPv6网络传输IPv4数据包。这两种方法互不相关，如果这样部署，它们可以共存于同一网络中，而不会产生任何冲突。
If one approach is to be deployed, the operator will decide which approach to use. Note that each approach has its own characteristics and requirements. For example, the tunnel-based solution requires a mesh of inter-AFBR softwires (tunnels) spanning the IPv6 network, as well as IBGP to exchange routes between AFBRs [RFC5565]; the approach in this document requires AFXLBRs that are capable of performing IPv4-IPv6 packet header translation per [RFC6145].
如果要部署一种方法，操作员将决定使用哪种方法。请注意，每种方法都有自己的特点和要求。例如，基于隧道的解决方案需要跨越IPv6网络的AFBR间软线（隧道）网，以及IBGP来交换AFBR之间的路由[RFC5565]；本文档中的方法要求AFXLBR能够按照[RFC6145]执行IPv4-IPv6数据包头转换。
To deploy the solution as documented here, some configurations are required. An IPv6 prefix must first be chosen that is used to form all the IPv4-embedded IPv6 addresses and prefixes advertised by AFXLBRs in the IPv6 network; refer to Section 4.1 for details. The IPv4-embedded IPv6 routing table is created by using a separate OSPFv3 instance in the IPv6 network. As described in Section 3.2, this configuration is accomplished according to the mechanism described in [RFC5838].
要按此处所述部署解决方案，需要进行一些配置。必须首先选择一个IPv6前缀，该前缀用于形成IPv6网络中AFXLBR播发的所有IPv4嵌入IPv6地址和前缀；有关详细信息，请参阅第4.1节。IPv4嵌入式IPv6路由表是通过在IPv6网络中使用单独的OSPFv3实例创建的。如第3.2节所述，该配置根据[RFC5838]中所述的机制完成。
Note that this document does not change any behavior of OSPFv3, and the existing or common practice should apply in the context of scalability. For example, the amount of routes that are advertised by OSPFv3 is one key concern. With the solution as described in this document, IPv4-embedded IPv6 addresses and prefixes will be injected by AFXLBRs into some part of the IPv6 network (see Section 3.1 for details), and a separate routing table will be used for IPv4-embedded IPv6 routing. Care must be taken during network design such that 1) aggregations are performed on IPv4 addresses and prefixes before being advertised in the IPv6 network as described in Section 6, and 2) estimates are made as to the amount of IPv4-embedded IPv6 routes that would be disseminated in the IPv6 network and to the size of the separate OSPFv3 routing table.
请注意，本文档不会改变OSPFv3的任何行为，现有的或通用的实践应适用于可伸缩性环境。例如，OSPFv3公布的路由数量是一个关键问题。使用本文档中所述的解决方案，AFXLBR将IPv4嵌入式IPv6地址和前缀注入IPv6网络的某些部分（有关详细信息，请参阅第3.1节），并将为IPv4嵌入式IPv6路由使用单独的路由表。在网络设计过程中必须注意：1）按照第6节所述，在IPv6网络中发布之前，对IPv4地址和前缀执行聚合，以及2）估计将在IPv6网络中传播的IPv4嵌入式IPv6路由的数量以及单独的OSPFv3路由表的大小。
Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand, and Brian Carpenter for their comments.
非常感谢Acee Lindem、Dan Wing、Joel Halpern、Mike Shand和Brian Carpenter的评论。
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2119]Bradner，S.，“RFC中用于表示需求水平的关键词”，BCP 14，RFC 2119，1997年3月。
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a Link State Advertisement (LSA) Options Bit to Prevent Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", RFC 4576, June 2006.
[RFC4576]Rosen，E.，Psenak，P.，和P.Pillay Esnault，“使用链路状态公告（LSA）选项位防止BGP/MPLS IP虚拟专用网络（VPN）中的循环”，RFC 45762006年6月。
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5565]Wu，J.，Cui，Y.，Metz，C.和E.Rosen，“软线网格框架”，RFC 55652009年6月。
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC5838]Lindem，A.，Mirtorabi，S.，Roy，A.，Barnes，M.，和R.Aggarwal，“OSPFv3中地址家庭的支持”，RFC 5838，2010年4月。
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
[RFC6145]Li，X.，Bao，C.，和F.Baker，“IP/ICMP翻译算法”，RFC 61452011年4月。
[RFC6969] Retana, A. and D. Cheng, "OSPFv3 Instance ID Registry Update", RFC 6969, July 2013.
[RFC6969]Retana，A.和D.Cheng，“OSPFv3实例ID注册表更新”，RFC 69692013年7月。
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.
[RFC4552]Gupta，M.和N.Melam，“OSPFv3的认证/保密”，RFC 4552，2006年6月。
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[RFC5340]Coltun，R.，Ferguson，D.，Moy，J.，和A.Lindem，“IPv6的OSPF”，RFC 53402008年7月。
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC6052]Bao，C.，Huitema，C.，Bagnulo，M.，Boucadair，M.，和X.Li，“IPv4/IPv6转换器的IPv6寻址”，RFC 6052010年10月。
[RFC6506] Bhatia, M., Manral, V., and A. Lindem, "Supporting Authentication Trailer for OSPFv3", RFC 6506, February 2012.
[RFC6506]Bhatia，M.，Manral，V.，和A.Lindem，“OSPFv3的支持认证拖车”，RFC 65062012年2月。
Authors' Addresses
作者地址
Dean Cheng Huawei Technologies 2330 Central Expressway Santa Clara, California 95050 USA
Dean Cheng Huawei Technologies美国加利福尼亚州圣克拉拉中央高速公路2330号95050
EMail: dean.cheng@huawei.com
EMail: dean.cheng@huawei.com
Mohamed Boucadair France Telecom Rennes, 35000 France
Mohamed Boucadair法国电信雷恩，35000法国
EMail: mohamed.boucadair@orange.com
EMail: mohamed.boucadair@orange.com
Alvaro Retana Cisco Systems 7025 Kit Creek Rd. Research Triangle Park, North Carolina 27709 USA
美国北卡罗来纳州三角研究公园Kit Creek路7025号阿尔瓦罗·雷塔纳思科系统公司27709
EMail: aretana@cisco.com
EMail: aretana@cisco.com