Routing from IPv4 to IPv6 Networks

This document describes the IPv6 network transmission IPv4 packet routing scheme, based on the methods described in RFC6145 and 6052, along with a separate OSPFv3 route table of IPv4-IPv6 network Embedded IPv6 routing. At the same time, this article does not introduce any new IPv6 transition mechanism.

I. Introduction

1.1 Solutions

When ipv4 addresses are about to run out, people have come up with various solutions, such as vlsm and nat. These solutions only alleviate the crisis, and the emergence of ipv6 directly solves the problem. However, because ipv4 is still widely used, ipv4 and ipv6 will coexist for at least a period of time. Therefore, this article provides a route scheme for data packets to be transmitted when IPv4 is embedded in the IPv6 network.

1.2 solution described in RFC5565

However, such a scenario only supports intercommunication between IPv4 and IPv6 networks. In particular, when a pure IPv6 network is isolated, it only supports intercommunication between IPv4 networks. In this case, IPv4 packets are transmitted between the IPv6 network and IPv4 network. To transmit IPv4 data packets from the source IPv4 network to the destination IPv4 network, information that IPv4 may arrive must be exchanged between IPv4 networks.

In general, compared to operating an IPv4 IPv6 Dual-stack environment, a pure IPv6 network will reduce operating expenses and optimize operations. Some recommended solutions allow delivery of IPv4 services in a pure IPv6 network. This document mentions an engineering technology that separates the route tables used for the IPv4 Embedded IPv6 destination from the routing table for the local IPv6 destination.

1.3 OSPFv3 Solution

The OSPF protocol is mentioned in this article. The purpose of the OSPFv3 protocol is to support multiple instances. The maintenance of an IPv4-Based Embedded IPv6 route table simplifies implementation, troubleshooting, and operations. The local IPv6 route table also prevents overloading. A separate route table can be generated from a single route instance.

In addition, the article also mentions the solution mentioned in RFC5565, which describes this solution, that is, when IPv4 is embedded in IPv6, the network core is only the interconnection between IPv6 and IPv4 networks, it is called an IPv4 client network. P router supplier vro only supports the IPv6 core, but AFBRs supports IPv4 and IPv4 client interfaces. Routing solution, which defines the core AFBRs that run IBGP to exchange IPv4 routing information between [RFC5565] Using tunneling technology, through software such as MPLS, IPv4 packet forwarding involves LSP, GRE, and so on from an IPv4 client network.

In this document, we propose another scenario where there are several isolated IPv4 networks in section 1.1, called IPv4 client network routing solutions and IPv6 network interconnection. The IPv6 and IPv4 networks may or may not belong to the same Autonomous System (). An IPv4 client network and an IPv6 Network Boundary Node on the boundary are used as the home address translation border router (AFXLBR). IPv6 packets of IPv4 packets that can be translated by IPv4 addresses and IPv6 addresses are also supported, and vice versa, according to [RFC6145]. The scenario described in Figure 1 is displayed.

In this scenario, some isolated IPv4 networks are connected to each other. Due to the situation, it is most commonly used within an organization, an IPv6 prefix can be locally assigned and used by AFXLBRs (address translation border routing) to build an IPv4 Embedded IPv6 Address [RFC6052]. The embedded IPv4 address or prefix belongs to the network of the IPv4 client to connect to the AFXLBR. There is an AFXLBR that uses OSPFv3 to inject IPv4-IPv6 addresses and prefixes to IPv6 networks, and also installs an IPv4-Based Embedded IPv6 route released by other AFXLBRs.

When AFXLBR receives IPv4 packets from the local IPv4 client network to the remote IPv4 client network, it converts the IPv4 header to the related IPv6 Header [RFC6145]. During this process, the source and destination IPv4 addresses are also translated into IPv4-IPv6 embedded Address [RFC6052]. Then, the resulting IPv6 packet can be forwarded to the target IPv4 client network connected to the AFXLBR. The remote AFXLBR obtains the IPv4 source address and Destination Address [RFC6052], and then converts the received IPv6 packet header into an IPv4 header [RFC6145]. The resulting IPv4 packet is then forwarded according to the IPv4 route table maintained by the AFXLBR. In some cases, the preceding routing solution is very useful. One case is that some boundary nodes do not participate in the IBGP route exchange, or do not use IBGP at all. In another case, the network channel is not deployed in the IPv6 network, or the pure IPv6 Forwarding is preferred. Note that this routing solution is stateless, and IPv4 and IPv6 Header conversion is also performed on AFXLBR in two directions.

1.4 OSPFv3 special routing Topology

In general, IPv6 data packets embedded with IPv4 can be forwarded in the IPv6 network that implements OSPFv3, just like local IPv6 data packets. However, this requires an IPv4 Embedded IPv6 route to be extensive on the entire IPv6 network and storage vro. From a larger perspective, this is not desirable. In addition, because all IPv6 routes are stored in the same routing table, this will be inconvenient for routing and forwarding. If necessary, the required resources are managed according to the service category.

To achieve this goal, you need to configure a separate OSPFv3 instance [RFC5838] In the IPv6 network. This instance runs on all the participating AFXLBRs and a group of P routers connected to each other. A dedicated IPv4 address is embedded in the IPv6 topology to maintain these routers and to embed a dedicated IPv4 address into the IPv6 route table. The route table in the IPv6 network is only used for packet forwarding of IPv4 Embedded IPv6.

This article describes in detail how to use this method and related routing problems after the configuration is complete. This article focuses on the unicast routing protocol for IPv4 using OSPFv3 Embedded IPv6 data packets.

2. Backup

2.1 The Topology from IPv4 to IPv6

Before deploying an IPv4 Embedded IPv6 address and prefix and using a separate OSPFv3 route table, you must make a decision to set the router and its interfaces, whether it is part of the topology of the IPv4-IPv6 embedded in the IPv6 network. The existence of the topology for this embedded IPv4-IPv6 means that all AFXLBRs connected to the IPv4 client network (the address cluster border router) must be a member of this topology. A afxlbr must have at least one P router or other AFXLBR connected to the IPv6 network.

The topology of the embedded IPv4-IPv6 is a subnet of the entire IPv6 network. If all routers (including AFXLBRs and P routers) and all their interfaces are included, these two topologies converge. Generally, when the subnet contains multiple interconnected P routers, more routing paths are routed from an IPv4 client network to other IPv6 networks. However, this requires more routers in the IPv6 network to participate in the routing process of the IPv4-IPv6 embedded network. At the same time, the topology of the embedded IPv4-IPv6 must be continuous, non-segmented.

2.2 Maintain a dedicated IPv4 Embedded IPv6 route table

In an IPv6 network, to maintain an IPv4 Embedded IPv6 destination that contains the route in a separate IPv6 route table, OSPFv3 needs to use the mechanism defined in [RFC5838. The description assumes that the IPv6 network interconnection with the IPv4 network is under the same management mechanism, and the OSPFv3 instance ID (IID) is allocated locally and assigned to OSPFv3, among them, OSPFv3 is a dedicated IPv4 unicast Embedded IPv6 route IPv6 network. This IID is configured in the interface of the OSPFv3 router involved in embedding the IPv4-IPv6 topology.

A registry that configures the IID allocation range of OSPFv3 to be between 192 and 255, this range is reserved for "private" [RFC6969]. The "instance ID" field must be used in the packet header associated with the OSPFv3 instance of the IID OSPFv3 packet. In addition, the AF (secondary flag) field must be set in the OSPFv3 option field. When the request message is processed, only one link may be established when you receive the Hello message containing the same instance ID as the interface for receiving OSPFv3 instance IDs. This ensures that only interfaces configured as part of the IPv4 unicast OSPFv3 Embedded IPv6 topology are used for IPv4 Embedded IPv6 unicast routing.

3. IP packet Translation

When an IPv4 packet is transmitted over an IPv6 network, the IPv4 packet is translated into an IPv6 packet at the ingress AFXLBR, And the IPv4 packet is still at the egress of the AFXLBR. The rules specified for IP packet header conversion [RFC6145] are completed in a stateless manner. Follow the instructions below for address conversion.

Iv. IP packet Parsing

4.1 address translation

Before address translation, the IPv6 address prefix is assigned by the operator to form an IPv4 Embedded IPv6 address. The IPv6 prefix can be a well-known IPv6 prefix (WKP) 64: ff9b:/96, or the network-specific prefix of a unique organization. In the latter case, the IPv6 address prefix can be 32, 40, 48, 56, or 64 characters in length. In both cases, the IPv6 address prefix is used during the translation process between an IPv4 address and an IPv4-IPv6 embedded address. [RFC6052]

AFXLBR, the IPv6 Header entry of the IPv4 header, is translated into the source IPv6 address, the source IPv4 address of the destination IPv6 address, and the destination IPv4 address. During the translation process of the IPv4 header from the IPv6 Header at the egress AFXLBR, the source IPv6 address and the destination IPv6 address are translated into the corresponding source IPv4 address and destination IPv4 address respectively. Note that address translation is implemented in a stateless mode.

When an IPv6 WKP is used, [RFC6052] allows the IPv6 address of the world's unique IPv4 address to be embedded. The IPv6 address of the non-Global IPv4 address of the WKP is invalid because it contains all the packets received by the AFXLBR. When a client's IPv4 network and IPv6 transmission network belong to the same organization, you can also use a non-Global IPv4 address and a network-specific prefix [RFC6052].

5. Embedded routing of broadcast IPv4-IPV6

To forward IPv4 packets to the correct destination IPv6 network, IPv4 packets may be transmitted over the entire IPv6 network. This is the AFXLBRs of OSPFv3 used by the client network connected to IPv4. The scenario described in this document is that a group of AFXLBRs IPv4 client networks are interconnected with IPv6 networks. Both IPv4 and IPv6 networks belong to the same or different autonomous systems (), because of this, these IP address border routers act like Autonomous System border routers (ASBR ).

5.1 broadcast IPv4-Embedded IPv6 routing through an IPv6 Transmission Network

The IPv4 address prefix in the IPv4 client network is translated into an IPv4 Embedded IPv6 address prefix, which is assigned by the carrier and the method specified in [RFC6052. These routes will be advertised to IPv6. The traffic network advertisement scope includes the link status broadcast outside the autonomous system, that is, one or more attached Autonomous System border routers.

5.2 route Matrix

By default, measurements in the AS-External LSA that carry the IPv4-IPv6 embedded address or prefix are type 1 External measurements, which are comparable link state measurements, we assume, in most cases, the OSPFv2IPv4 network is used on the client. The measurement value of the path from the route entry added to the as to the asbr in OSPFv3. With ASBR configuration, you can set the measurement type 2 external measurement, which is considered to be much larger than any internal AS path measurement. More details about OSPFv3 specifications [RFC5340. In both cases, an external metric value may be required for an IPv4 network (using OSPFv2 or other routing protocols), but based on some routing policies, you can also specify that the details are beyond the scope of this article.

5.3 forwarding address

If the "forwarding address" field uses the IPv6 address carried by the external link status broadcast of the Autonomous System of OSPFv3, this address must also be an IPv4 address embedded in the IPv4 Embedded IPv6 address. However, because an address translation border router is sitting on the border between an IPv4 network and an IPv6 network, it is recommended that the "forwarding address" field be unavailable, the AFXLBR can be used to make forwarding decisions based on its IPv4 route table.

5.4 broadcast an IPv4 address to the Client Network

IPv4-IPv6 embedded routing, from an IPv4 client network is injected into the IPv6 network, after the relevant destination address and prefix are translated back to IPv4 address prefix, to an IPv4 client that is broadcast to another IPv4 client network. This operation is similar to a normal OSPFv3 operation. By default, the external link status broadcast of the autonomous system can be broadcast in a non-backbone area. IPv4 client networks can be configured to restrict broadcasts from IPv4 client networks. The IPv4 Embedded IPv6 route must not be published to any IPv6 client network, but can also be connected to the IPv6 transmission network.

Vi. IPv4 address and prefix Aggregation

In order to reduce the link status broadcast (LSA) and inject it into the IPv6 network, an implementation mechanism should be provided to provide the IPv4 Embedded IPv6 address and prefix before the advertisement of an AFXLBR with the total IPv4 address and prefix. In general, clustering should be based on routing policies, which is not discussed in this article.

VII. Forwarding

When forwarding IP data packets, there are three situations that apply to this article.

7.1 In an address translation boundary route, if IPv4 is isolated, the IPv4 address of the destination belongs to the network of the client of another IPv4 client and is connected to the IPv4 packet received on an interface, the packet header is translated into the packet described in section 4th of the corresponding IPv6 Header, and then the destination address to be forwarded is converted into the IPv4 address of the border routing broadcast to the Embedded IPv6 address of the IPv6 network.

7.2 In an address translation boundary route, if IPv4 packets embedded in IPv6 are received and the destination IPv4 address is in the IPv4 routing table, the packet header is translated into the corresponding IPv4 header and then grouped and forwarded.

7.3 In all embedded IPv4-IPv6 topology subsets of the IPv6 network, the IPv6 packet of the embedded IPv4 is received, but the embedded IPv4-IPv6 route table has found the route, then, the data packet is forwarded to the next hop of IPv6, just like operating a normal IPv6 data packet, without any translation processing.

8. backdoor connection

In some deployments, the IPv6 network and the IPv4 client network are interconnected, but they can also be directly connected to each other. A direct connection between IPv4 client networks is also known as a "backdoor" connection. Of course, it can be used to transmit IPv4 packets between IPv4 client networks. In general, backdoor connection is preferred, because in IPv6, translation is required because there is no address family.

9. Prevent routing loops

If the link status that can be received by another address translation border router is sent from the address translation border router to the client network, this may happen in the routing loop. To prevent loops, an address translation VBR must set the DN bit [RFC4576] to broadcast it to the client network in any link status. Also, the address translation VBR must ignore any received link status broadcast, which already has a bit set with a client network path.

10. Maximum Transmission Unit Problems

In IPv6, no new MTU problem is introduced in this article. If a separate OSPFv3 instance is used for IPv4 Embedded IPv6 routing, it is the same as the default instance for MTU processing OSPFv3 In the IPv6 network. However, MTU in an IPv6 network may be different from that of an IPv4 client. Because the IPv6 router will never split the data packet, the size of any IPv6 packet embedded in the IPv4 address of the packet must be equal to or less than the MTU of the IPv6 network. To meet this requirement, it is recommended that the address translation VBR execute IPv6 paths to discover each other. After the MTU is generated, the IPv4 header length must be "transmitted" to the IPv4 Client Network Considering the difference between the IPv4 header length and the IPv6 Header Length.

11. security considerations

There are several security aspects to be concerned about, as described in this document. OSPFv3 security considerations in the OSPFv3 traffic network, to handle as usual, especially the authentication mechanism [RFC6506] can be deployed. When a separate OSPFv3 instance is used to support the same Security Association (SA) [RFC4552] of IPv4 Embedded IPv6 routes, the same link is used, you must use an embedded IPv4 address instance, as specified in [RFC5838. Security NOTE Records [RFC6052] must also be well considered and properly executed, including the following: O is the IPv4 address used for embedding (see section 4.1) the IPv6 prefix of must be configured in AFXLBRs security mode for all authorized operations. This is to help prevent malicious attacks, cause network interruptions, denial of service, and possible information disclosure. Effective mechanisms (such as reverse path check) must implement IPv4 addresses embedded in IPv6 transmission networks (including AFXLBRs). Otherwise, they may be used as the source address of malicious packets to prevent spoofing. Ø in IPv4 and/or IPv6 networks, if a firewall is used, the configurations of the router must be consistent so that there are no IPv4 address filtering holes. The security processing details are out of scope.

12. Operation notes

This file is put together as an integrated solution to transmit IPv4 packets over an IPv6 network using a separate OSPFv3 route table based on the existing technology developed by IETF. You need to pay attention to the deployment and operations of these mechanisms. The Tunneling solution is recorded in [RFC5565] and the solution proposed in this document is used to transmit IPv4 packets over the IPv6 network, using different mechanisms. These two methods are interrelated, and they can coexist in the same network. If deployed, there is no conflict. To deploy a method, the operator determines the method to use. Note that each method has its own characteristics and requirements. For example, a tunneling solution requires a cross-AFBR softwires (Tunnel) Cross-IPv6 network and an IBGP to exchange routes for AFBRs [RFC5565]. The method in this file is as follows, the IPv4 AFXLBRs IPv6 packet header needs to be converted every [RFC6145].

The solution to be deployed, because some configurations are recorded here. You must first select an IPv6 prefix to form all IPv4 Embedded IPv6 address prefixes advertised by AFXLBRs In the IPv6 network. See section 4.1. Create an IPv6 network using a separate OSPFv3 instance in the embedded IPv4-IPv6 routing table. As described in section 3.2, such configuration is completed according to the mechanism described in [RFC5838. Please note that this document does not change any behavior of OSPFv3 and should be applicable to existing or common practices in the context of scalability. For example, OSPFv3's advertising traffic route is a key issue. With the solution described in this document, the IPv4 Embedded IPv6 address prefix injects AFXLBRs into some parts of the IPv6 network (see section 3.1) and an independent route table, the Embedded IPv6 route used for IPv4. 1) For the aggregated IPv4 address, be careful when designing the network described in Section 6 before the prefix of the IPv6 network advertisement. 2) the IPv4-Based Embedded IPv6 route of the estimator, the size of the route table that will be transmitted in the IPv6 network and separately stored in OSPFv3.