+--------+   +--------+
                 |  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 Inter-connected by an IPv6 Network

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 according to [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.

When an AFXLBR receives an IPv4 packet from a locally connected IPv4 client network and destined to a remote IPv4 client network, it translates the IPv4 header to the relevant IPv6 header according to [RFC6145], and in that process, source and destination IPv4 address are translated into IPv4-embedded IPv6 addresses, respectively, according to [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, according to [RFC6052], and translates the header of the received IPv6 packet to the relevant IPv4 header according to [RFC6145]. The resulting IPv4 packet is then forwarded according to the IPv4 routing table maintained on the AFXLBR.

There are use cases where the proposed routing solution is useful. One case is that some border nodes do not participate in i-BGP for routes exchange, or i-BGP 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.

1.4. OSPFv3 Routing with a Specific Topology

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 IPv4-embedded IPv6 routes to be flooded throughout the entire IPv6 network and stored on every router. This is not desirable from the 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.

To improve the situation, a separate OSPFv3 routing table can be constructed that is dedicated to the IPv4-embedded IPv6 topology, and that table is solely used for routing IPv4-embedded IPv6 packets in the IPv6 network. The IPv4-embedded IPv6 topology includes all the participating AFXLBR routers and a set of P(rovider) Routers providing redundant connectivity with alternate routing paths.

There are two methods to build a separate OSPFv3 routing table for IPv4-embedded IPv6 routes:

• The first one is to run a separate OSPFv3 instance for IPv4-embedded IPv6 topology in the IPv6 network according to [RFC5838].
• The second one is to stay with the existing OSPFv3 instance that already operates in the IPv6 network, but maintain a separate IPv4-embedded IPv6 topology, according to [I-D.ietf-ospf-mt-ospfv3].

With either method, there would be a dedicated IPv4-embedded IPv6 topology that is maintained on all participating AFXLBR and P Routers, along with a dedicated IPv4-embedded IPv6 routing table. This routing table is then used solely in the IPv6 network for IPv4-embedded IPv6 packets.

It would be an operator's preference as which method is to be used. This document elaborates on how configuration is done for each method and related routing issues that are common to both.

This document only focuses on unicast routing for IPv4-embedded IPv6 packets using OSPFv3.

2. Requirements Language

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].

3. Provisioning

3.1. Deciding the IPv4-embedded IPv6 Topology

Before deploying configurations that use a separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and prefixes, a decision must be made on the set of routers and their interfaces in the IPv6 network that should be part of the IPv4-embedded IPv6 topology.

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.

The IPv4-embedded IPv6 topology is a sub-topology 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 sub-topology contains more inter-connected 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.

3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table

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 either in [RFC5838] or in [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as described in Section 3.3 and Section 3.4, respectively.

3.3. OSPFv3 Topology with a Separate Instance ID

It is assumed that the IPv6 network that is inter-connected with IPv4 networks 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.

The range for a locally configured OSPFv3 IID is from 192 to 255, inclusive, and this IID must be used to encode the "Instance ID" field in the packet header of OSPFv3 packets associated with the OSPFv3 instance.

In addition, the "AF" bit in the OSPFv3 Option field MUST be set.

During Hello packet processing, an adjacency may only be established when the received Hello packet contains the same Instance ID as 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.

For more details, the reader is referred to [RFC5838].

3.4. OSPFv3 Topology with the Default Instance

Similar to that as described in the previous section, an OSPFv3 multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3 operation including unicast IPv4-embedded IPv6 routing in an IPv6 network. This MT-ID is configured on each OSPFv3 router interface that participates in this routing topology.

The range for a locally configured OSPFv3 MT-ID is from 32 to 255, inclusive, and this MT-ID must be used to encode the "MT-ID" field included in extended Link State Advertisements (LSAs) for the IPv4-embedded IPv6 unicast topology as documented in [I-D.ietf-ospf-mt-ospfv3].

In addition, the MT bit in the OSPFv3 Option field MUST be set.

For more details, the reader is referred to [I-D.ietf-ospf-mt-ospfv3].

4. IP Packets Translation

When transporting IPv4 packets across an IPv6 network with the mechanism described above, 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. The IP packet header translation is accomplished in stateless manner according to rules specified in [RFC6145], with the address translation details explained in the next sub-section.

4.1. Address Translation

Prior to address translation, an IPv6 prefix is allocated by the operator and it is used to form IPv4-embedded IPv6 addresses.

The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 64:ff9b::/96, or a network-specific prefix that is unique to the organzation; and 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].

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 IPv6 source address and destination IPv6 address, respectively, and 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 IPv4 source address and destination IPv4 address, respectively. Note that the address translation is accomplished in a stateless manner.

When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only global IPv4 addresses to be embedded in the IPv6 address. An IPv6 address composed with a WKP and a non-global IPv4 address is hence invalid, and packets that contain such address received by an AFXLBR are dropped.

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].

5. Advertising IPv4-embedded IPv6 Routes

In order to forward IPv4 packets to the proper destination across an IPv6 network, IPv4 reachability needs to be disseminated throughout the IPv6 network and this is performed by AFXLBRs that connect to IPv4 client networks using OSPFv3.

With the scenario described in this document, i.e., a set of AFXLBRs that inter-connect a bunch of IPv4 client networks with an IPv6 network, the IPv4 networks and IPv6 networks belong to the same or separate Autonomous Systems, and as such, these AFXLBRs behave as AS Boundary Routers (ASBRs).

5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit Network

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.

5.1.1. Routing Metrics

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 detail. 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 outside of the scope of this document.

5.1.2. Forwarding Address

If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is used to carry an IPv6 address, that 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 is not used, so that the AFXLBR can make the forwarding decision based on its own IPv4 routing table.

5.2. Advertising IPv4 Addresses into Client Networks

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.

An IPv4 client network can limit which advertisements it receives through configuration.

For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT be advertised into any IPv6 client networks that also connected to the IPv6 transit network.

6. Aggregation on IPv4 Addresses and Prefixes

In order to reduce the amount of LSAs that are injected to the IPv6 network, an implementation should provide mechanisms to aggregate IPv4 addresses and prefixes at AFXLBR prior to advertisement as IPv4-embedded IPv6 addresses and prefixes. In general, the aggregation practice should be based on routing policy, which is outside of the scope of this document.

7. Forwarding

There are three cases in forwarding IP packets in the scenario described in this document:

1. On an AFXLBR, if an IPv4 packet that is received on an interface connecting to an IPv4 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.
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.
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.

The classification of IPv4-embedded IPv6 packet is according to the IPv6 prefix of the destination address, which is either the Well Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in [RFC6052].

8. Backdoor Connections

In some deployments, IPv4 client networks are inter-connected across the IPv6 network, but also directly connected to each other. The direct connections between IPv4 client networks, as 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 there requires no address family translation.

9. Prevention of Loops

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 sent.

10. MTU Issues

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. If a separate OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is used for IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is the same as that of the default OSPFv3 topology.

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 that AFXLBRs perform IPv6 path discovery among themselves and the resulting MTU, after taking into account of 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.

The details of passing the proper MTU into IPv4 client networks are beyond the scope of this document.

11. Security Considerations

There are several security aspects that require attention in the deployment practice described in this document.

In the OSPFv3 transit network, the security considerations for OSPFv3 are covered in [RFC5340], and in particular, IPsec can be used for OSPFv3 authentication and confidentiality as suggested in [RFC5838].

When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 routing, the same Security Association (SA) (refer to [RFC4552] ) must be used by the embedded IPv4 address instance as other instances utilizing the same link as specified in [RFC5838].

Security considerations as currently documented in [RFC6052] must also be thought through with proper implementation including the following:

• 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 an malicious attack resulting in network disruption, denial of service, and possible information disclosure.
• Effective mechanisms (such as reverse path checking) must be implemented in the IPv6 transit network (including AFXLIBR nodes) to prevent spoofing on embedded IPv4 addresses, which, otherwise, might be used as source addresses of malicious packets.
• If firewalls are used in IPv4 and/or IPv6 networks, the configuration on the routers must be consistent so there are no holes in the IPv4 address filtering.

The details of security handling are beyond the scope of this document.

12. Operational Considerations

This document put together some mechanisms based on existing technologies developed by IETF as an integrated solution to transport IPv4 packets over an IPv6 network using a separate OSPFv3 routing table. There are several aspects that require attention for the deployment and operation.

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, with different mechanisms. The two methods are not related to each other, and they can co-exist in the same network if so deployed, without any conflict.

If one approach is to be deployed, it is the operator's decision for the choice. Note that each approach has its own characteristics and requirements. E.g., the tunnel-based solution requries 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 AFXLBR capable of perfoming IPv4-IPv6 packet header translation per [RFC6145].

To deploy the solution as documented here, there requires some configurations. An IPv6 prefix must first be chosen that is used to form all the IPv4-embedded IPv6 addresses and prefixes advertised by AFXLBR in the IPv6 network; the detail is referred to Section 4.1. If the IPv4-embedded IPv6 routing table is created by using a separate OSPFv3 instance in the IPv6 network, configuration is accomplished according to [RFC5838], as described in Section 3.3, and if the default OSPFv3 instance is used instead, configuration is accomplished according to [I-D.ietf-ospf-mt-ospfv3], as described in Section 3.4.

With the solution as described in this document, IPv4-embedded IPv6 addresses and prefixes will be injected by AFXLBR 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 the network design, such that 1) aggregation 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 the amount of IPv4-embedded IPv6 routes that would be disseminated in the IPv6 network, and the size of the separate OSPFv3 routing table. Note this document does not change any behavior of OSPFv3, and the existing or common practice should apply.

13. IANA Considerations

No new IANA assignments are required for this document.

14. Acknowledgements

Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and Brian Carpenter for their comments.

15. References

15.1. Normative References

[RFC2119]	Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997.
[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.
[RFC5565]	Wu, J., Cui, Y., Metz, C. and E. Rosen, "Softwire Mesh Framework", RFC 5565, June 2009.
[RFC5838]	Lindem, A., Mirtorabi, S., Roy, A., Barnes, M. and R. Aggarwal, "Support of Address Families in OSPFv3", RFC 5838, April 2010.
[RFC6145]	Li, X., Bao, C. and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.

15.2. Informative References

[RFC6052]	Bao, C., Huitema, C., Bagnulo, M., Boucadair, M. and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
[RFC5340]	Coltun, R., Ferguson, D., Moy, J. and A. Lindem, "OSPF for IPv6", RFC 5340, July 2008.
[I-D.ietf-ospf-mt-ospfv3]	Mirtorabi, S. and A. Roy, "Multi-topology routing in OSPFv3 (MT-OSPFv3)", Internet-Draft draft-ietf-ospf-mt-ospfv3-03, July 2007.
[RFC4552]	Gupta, M. and N. Melam, "Authentication/Confidentiality for OSPFv3", RFC 4552, June 2006.

Authors' Addresses