draft-ietf-ospf-ipv4-embedded-ipv6-routing-07.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-08.txt 
Network Working Group D. Cheng Network Working Group D. Cheng
Internet-Draft Huawei Technologies Internet-Draft Huawei Technologies
Intended status: Informational M. Boucadair Intended status: Informational M. Boucadair
Expires: August 5, 2013 France Telecom Expires: September 30, 2013 France Telecom
A. Retana A. Retana
Cisco Systems Cisco Systems
February 1, 2013 March 29, 2013
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-07 draft-ietf-ospf-ipv4-embedded-ipv6-routing-08
Abstract Abstract
This document describes routing packets destined to IPv4-embedded This document describes routing packets destined to IPv4-embedded
IPv6 addresses across an IPv6 core using OSPFv3 with a separate IPv6 addresses across an IPv6 core using OSPFv3 with a separate
routing table. routing table.
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 5, 2013. This Internet-Draft will expire on September 30, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
1.1. The Scenario . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. The Scenario . . . . . . . . . . . . . . . . . . . . . . 3
1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . . 4 1.2. Routing Solution per RFC5565 . . . . . . . . . . . . . . 4
1.3. An Alternative Routing Solution with OSPFv3 . . . . . . . 4 1.3. An Alternative Routing Solution with OSPFv3 . . . . . . . 4
1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 6 1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 6
2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 7
3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 7 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 7 3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . 7
3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 7
Table . . . . . . . . . . . . . . . . . . . . . . . . . . 8 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7
3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 8 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8
3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 8 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . 8
4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 9 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 9
4.1. Address Translation . . . . . . . . . . . . . . . . . . . 9 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 9
5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 10
5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 10 Transit Network . . . . . . . . . . . . . . . . . . . . . 10
5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 10
5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 10 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . 10
5.2. Advertising IPv4 Addresses into Client Networks . . . . . 11 5.2. Advertising IPv4 Addresses into Client Networks . . . . . 10
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 11 6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . 11
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 11 7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . 11
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 12 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . 12
9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12
10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12 10. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 11. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. Security Considerations . . . . . . . . . . . . . . . . . . . 13
13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 13. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 14. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14
14.1. Normative References . . . . . . . . . . . . . . . . . . . 14 15. References . . . . . . . . . . . . . . . . . . . . . . . . . 14
14.2. Informative References . . . . . . . . . . . . . . . . . . 14 15.1. Normative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 15.2. Informative References . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document describes a routing scenario where IPv4 packets are This document describes a routing scenario where IPv4 packets are
transported over an IPv6 network, based on [RFC6145] and [RFC6052], transported over an IPv6 network, based on [RFC6145] and [RFC6052],
along with a separate OSPFv3 routing table for IPv4-embedded IPv6 along with a separate OSPFv3 routing table for IPv4-embedded IPv6
routes in the IPv6 network. This document does not introduce any new routes in the IPv6 network. This document does not introduce any new
IPv6 transition mechanism. IPv6 transition mechanism.
In this document the following terminology is used: In this document the following terminology is used:
o An IPv4-embedded IPv6 address denotes an IPv6 address which o An IPv4-embedded IPv6 address denotes an IPv6 address which
contains an embedded 32-bit IPv4 address constructed according to contains an embedded 32-bit IPv4 address constructed according to
skipping to change at page 3, line 41 skipping to change at page 3, line 38
performing IP header translation between IPv4 and IPv6 according performing IP header translation between IPv4 and IPv6 according
to [RFC6145]. to [RFC6145].
1.1. The Scenario 1.1. The Scenario
Due to exhaustion of public IPv4 addresses, there has been a Due to exhaustion of public IPv4 addresses, there has been a
continuing effort within the IETF on IPv6 transitional techniques. continuing effort within the IETF on IPv6 transitional techniques.
In the course of the transition, it is certain that networks based on In the course of the transition, it is certain that networks based on
IPv4 and IPv6 technologies respectively, will co-exist at least for IPv4 and IPv6 technologies respectively, will co-exist at least for
some time. One scenario of this co-existence is the inter-connection some time. One scenario of this co-existence is the inter-connection
of IPv4-only and IPv6-only networks, and in particular, when an IPv6- of IPv4-only and IPv6-only networks, and in particular, when an
only network serves as inter-connection between several segregated IPv6-only network serves as inter-connection between several
IPv4-only networks. In this scenario, IPv4 packets are transported segregated IPv4-only networks. In this scenario, IPv4 packets are
over the IPv6 network between IPv4 networks. In order to forward an transported over the IPv6 network between IPv4 networks. In order to
IPv4 packet from a source IPv4 network to the destination IPv4 forward an IPv4 packet from a source IPv4 network to the destination
network, IPv4 reachability information must be exchanged between the IPv4 network, IPv4 reachability information must be exchanged between
IPv4 networks by some mechanism. the IPv4 networks by some mechanism.
In general, running an IPv6-only network would reduce OPEX and In general, running an IPv6-only network would reduce OPEX and
optimize the operation compared to IPv4-IPv6 dual-stack environment. optimize the operation compared to IPv4-IPv6 dual-stack environment.
Some solutions have been proposed to allow delivery of IPv4 services Some solutions have been proposed to allow delivery of IPv4 services
over an IPv6-only network. This document focuses on an engineering over an IPv6-only network. This document focuses on an engineering
technique which aims to separate the routing table dedicated to IPv4- technique which aims to separate the routing table dedicated to
embedded IPv6 destinations from native IPv6 ones. IPv4-embedded IPv6 destinations from native IPv6 ones.
Maintaining a separate routing table for IPv4-embedded IPv6 routes Maintaining a separate routing table for IPv4-embedded IPv6 routes
optimizes IPv4 packets forwarding. It also prevents overload of the optimizes IPv4 packets forwarding. It also prevents overload of the
native IPv6 routing tables. A separate routing table can be native IPv6 routing tables. A separate routing table can be
generated from a separate routing instance or a separate routing generated from a separate routing instance or a separate routing
topology. topology.
1.2. Routing Solution per RFC5565 1.2. Routing Solution per RFC5565
The aforementioned scenario is described in [RFC5565], i.e., IPv4- The aforementioned scenario is described in [RFC5565], i.e., IPv4
over-IPv6 scenario, where the network core is IPv6-only, and the -over-IPv6 scenario, where the network core is IPv6-only, and the
inter-connected IPv4 networks are called IPv4 client networks. The P inter-connected IPv4 networks are called IPv4 client networks. The P
routers in the core only support IPv6 but the AFBRs (Address Family Routers in the core only support IPv6 but the AFBRs (Address Family
Border Routers) support IPv4 on interfaces facing IPv4 client Border Routers) support IPv4 on interfaces facing IPv4 client
networks, and IPv6 on interfaces facing the core. The routing networks, and IPv6 on interfaces facing the core. The routing
solution defined in [RFC5565] for this scenario is to run i-BGP among solution defined in [RFC5565] for this scenario is to run i-BGP among
AFBRs to exchange IPv4 routing information in the core, and the IPv4 AFBRs to exchange IPv4 routing information in the core, and the IPv4
packets are forwarded from one IPv4 client network to the other packets are forwarded from one IPv4 client network to the other
through a softwire using tunneling technology such as MPLS LSP, GRE, through a softwire using tunneling technology such as MPLS LSP, GRE,
L2TPv3, etc. L2TPv3, etc.
1.3. An Alternative Routing Solution with OSPFv3 1.3. An Alternative Routing Solution with OSPFv3
In this document, we propose an alternative routing solution for the In this document, we propose an alternative routing solution for the
scenario described in Section 1.1, where several segregated IPv4 scenario described in Section 1.1, where several segregated IPv4
networks, called IPv4 client networks, are interconnected by an IPv6 networks, called IPv4 client networks, are inter-connected by an IPv6
network. We refer to the border node on the boundary of an IPv4 network, which belongs to a different Autonomous System from those of
client network and the IPv6 network as an Address Family Translation the IPv4 networks. We refer to the border node on the boundary of an
Border Router (AFXLBR), which supports both the IPv4 and IPv6 address IPv4 client network and the IPv6 network as an Address Family
families, and is capable of translating an IPv4 packet to an IPv6 Translation Border Router (AFXLBR), which supports both the IPv4 and
packet, and vice versa, according to [RFC6145]. The described IPv6 address families, and is capable of translating an IPv4 packet
scenario is illustrated in Figure 1. to an IPv6 packet, and vice versa, according to [RFC6145]. The
described scenario is illustrated in Figure 1.
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
| \ / | | \ / |
| \ / | | \ / |
| \ / | | \ / |
| X | | X |
skipping to change at page 6, line 44 skipping to change at page 6, line 31
throughout the entire IPv6 network and stored on every router. This throughout the entire IPv6 network and stored on every router. This
is not desirable from the scaling perspective. Moreover, since all is not desirable from the scaling perspective. Moreover, since all
IPv6 routes are stored in the same routing table, it would be IPv6 routes are stored in the same routing table, it would be
inconvenient to manage the resource required for routing and inconvenient to manage the resource required for routing and
forwarding based on traffic category, if so desired. forwarding based on traffic category, if so desired.
To improve the situation, a separate OSPFv3 routing table can be To improve the situation, a separate OSPFv3 routing table can be
constructed that is dedicated to the IPv4-embedded IPv6 topology, and constructed that is dedicated to the IPv4-embedded IPv6 topology, and
that table is solely used for routing IPv4-embedded IPv6 packets in that table is solely used for routing IPv4-embedded IPv6 packets in
the IPv6 network. The IPv4-embedded IPv6 topology includes all the the IPv6 network. The IPv4-embedded IPv6 topology includes all the
participating AFXLBR routers and a set of P routers providing participating AFXLBR routers and a set of P Routers providing
redundant connectivity with alternate routing paths. redundant connectivity with alternate routing paths.
There are two methods to build a separate OSPFv3 routing table for There are two methods to build a separate OSPFv3 routing table for
IPv4-embedded IPv6 routes: IPv4-embedded IPv6 routes:
o The first one is to run a separate OSPFv3 instance for IPv4- o The first one is to run a separate OSPFv3 instance for
embedded IPv6 topology in the IPv6 network according to [RFC5838]. IPv4-embedded IPv6 topology in the IPv6 network according to
[RFC5838].
o The second one is to stay with the existing OSPFv3 instance that o The second one is to stay with the existing OSPFv3 instance that
already operates in the IPv6 network, but maintain a separate already operates in the IPv6 network, but maintain a separate
IPv4-embedded IPv6 topology, according to IPv4-embedded IPv6 topology, according to
[I-D.ietf-ospf-mt-ospfv3]. [I-D.ietf-ospf-mt-ospfv3].
With either method, there would be a dedicated IPv4-embedded IPv6 With either method, there would be a dedicated IPv4-embedded IPv6
topology that is maintained on all participating AFXLBR and P topology that is maintained on all participating AFXLBR and P
routers, along with a dedicated IPv4-embedded IPv6 routing table. Routers, along with a dedicated IPv4-embedded IPv6 routing table.
This routing table is then used solely in the IPv6 network for IPv4- This routing table is then used solely in the IPv6 network for
embedded IPv6 packets. IPv4-embedded IPv6 packets.
It would be an operator's preference as which method is to be used. 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 This document elaborates on how configuration is done for each method
and related routing issues that are common to both. and related routing issues that are common to both.
This document only focuses on unicast routing for IPv4-embedded IPv6 This document only focuses on unicast routing for IPv4-embedded IPv6
packets using OSPFv3. packets using OSPFv3.
2. Requirements Language 2. Requirements Language
skipping to change at page 7, line 39 skipping to change at page 7, line 28
3. Provisioning 3. Provisioning
3.1. Deciding the IPv4-embedded IPv6 Topology 3.1. Deciding the IPv4-embedded IPv6 Topology
Before deploying configurations that use a separate OSPFv3 routing Before deploying configurations that use a separate OSPFv3 routing
table for IPv4-embedded IPv6 addresses and prefixes, a decision must table for IPv4-embedded IPv6 addresses and prefixes, a decision must
be made on the set of routers and their interfaces in the IPv6 be made on the set of routers and their interfaces in the IPv6
network that should be part of the IPv4-embedded IPv6 topology. network that should be part of the IPv4-embedded IPv6 topology.
For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs that
connect to IPv4 client networks MUST be members of this topology, and connect to IPv4 client networks MUST be members of this topology. An
also at least some of their network core facing interfaces along with AFXLBR MUST have at least one connection with a P Router in the IPv6
some P routers in the IPv6 network. network or another AFXLBR.
The IPv4-embedded IPv6 topology is a sub-topology of the entire IPv6 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 network, and if all routers (including AFXLBRs and P-routers) and all
their interfaces are included, the two topologies converge. In their interfaces are included, the two topologies converge.
general, as more P routers and their interfaces are configured on Generally speaking, when this sub-topology contains more inter-
this sub-topology, it would increase the inter-connectivity and connected P Routers, there would be more routing paths across the
potentially, there would be more routing paths across the network IPv6 network from one IPv4 client network to the other; however, this
from one IPv4 client network to the other, at the cost of more requires more routers in the IPv6 network to participate in
routers needing to participate in IPv4-embedded IPv6 routing. In any IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6
case, the IPv4-embedded IPv6 topology MUST be continuous with no topology MUST be continuous with no partitions.
partitions.
3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table
In an IPv6 network, in order to maintain a separate IPv6 routing In an IPv6 network, in order to maintain a separate IPv6 routing
table that contains routes for IPv4-embedded IPv6 destinations only, table that contains routes for IPv4-embedded IPv6 destinations only,
OSPFv3 needs to use the mechanism defined either in [RFC5838] or in OSPFv3 needs to use the mechanism defined either in [RFC5838] or in
[I-D.ietf-ospf-mt-ospfv3] with the required configuration, as [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
described in the following sub-sections. described in Section 3.3 and Section 3.4, respectively.
3.3. OSPFv3 Topology with a Separate Instance ID 3.3. OSPFv3 Topology with a Separate Instance ID
It is assumed that the IPv6 network that is inter-connected with IPv4
It is assumed that the scenario described in this document is under a networks in this document is under a single Autonomous System and as
single Autonomous System and, as such, an OSPFv3 instance ID (IID) is such, an OSPFv3 instance ID (IID) is allocated locally and used for
allocated locally and used for OSPFv3 operation dedicated to unicast OSPFv3 operation dedicated to unicast IPv4-embedded IPv6 routing in
IPv4-embedded IPv6 routing in an IPv6 network. This IID is an IPv6 network. This IID is configured on OSPFv3 router interfaces
configured on OSPFv3 router interfaces that participate in the IPv4- that participate in the IPv4-embedded IPv6 topology.
embedded IPv6 topology.
The range for a locally configured OSPFv3 IID is from 192 to 255, 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" inclusive, and this IID must be used to encode the "Instance ID"
field in the packet header of OSPFv3 packets associated with the field in the packet header of OSPFv3 packets associated with the
OSPFv3 instance. OSPFv3 instance.
In addition, the "AF" bit in the OSPFv3 Option field MUST be set. In addition, the "AF" bit in the OSPFv3 Option field MUST be set.
During Hello packet processing, an adjacency may only be established During Hello packet processing, an adjacency may only be established
when the received Hello packet contains the same Instance ID as when the received Hello packet contains the same Instance ID as
skipping to change at page 8, line 44 skipping to change at page 8, line 31
interfaces configured as part of the OSPFv3 unicast IPv4-embedded interfaces configured as part of the OSPFv3 unicast IPv4-embedded
IPv6 topology are used for IPv4-embedded IPv6 unicast routing. IPv6 topology are used for IPv4-embedded IPv6 unicast routing.
For more details, the reader is referred to [RFC5838]. For more details, the reader is referred to [RFC5838].
3.4. OSPFv3 Topology with the Default Instance 3.4. OSPFv3 Topology with the Default Instance
Similar to that as described in the previous section, an OSPFv3 Similar to that as described in the previous section, an OSPFv3
multi-topology ID (MT-ID) is locally allocated and used for 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 operation including unicast IPv4-embedded IPv6 routing in an IPv6
network. This MTID is configured on each OSPFv3 router interface network. This MT-ID is configured on each OSPFv3 router interface
that participates in this routing topology. that participates in this routing topology.
The range for a locally configured OSPFv3 MT-ID is from 32 to 255, 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 inclusive, and this MT-ID must be used to encode the "MT-ID" field
included in extended Link State Advertisements (LSAs) for the IPv4- included in extended Link State Advertisements (LSAs) for the
embedded IPv6 unicast topology as documented in IPv4-embedded IPv6 unicast topology as documented in
[I-D.ietf-ospf-mt-ospfv3]. [I-D.ietf-ospf-mt-ospfv3].
In addition, the MT bit in the OSPFv3 Option field must be set. In addition, the MT bit in the OSPFv3 Option field MUST be set.
For more details, the reader is referred to For more details, the reader is referred to
[I-D.ietf-ospf-mt-ospfv3]. [I-D.ietf-ospf-mt-ospfv3].
4. IP Packets Translation 4. IP Packets Translation
When transporting IPv4 packets across an IPv6 network with the When transporting IPv4 packets across an IPv6 network with the
mechanism described above, an IPv4 packet is translated to an IPv6 mechanism described above, an IPv4 packet is translated to an IPv6
packet at the ingress AFXLBR, and the IPv6 packet is translated back packet at the ingress AFXLBR, and the IPv6 packet is translated back
to an IPv4 packet at the egress AFXLBR. The IP packet header to an IPv4 packet at the egress AFXLBR. The IP packet header
translation is accomplished in stateless manner according to rules translation is accomplished in stateless manner according to rules
specified in [RFC6145], with the address translation details specified in [RFC6145], with the address translation details
explained in the next sub-section. explained in the next sub-section.
4.1. Address Translation 4.1. Address Translation
Prior to address translation, an IPv6 prefix is allocated by the Prior to address translation, an IPv6 prefix is allocated by the
Autonomous System and it is used to form IPv4-embedded IPv6 Autonomous System and it is used to form IPv4-embedded IPv6
addresses. addresses.
The IPv6 prefix can either be the well-known IPv6 prefix (WKP) 64: The IPv6 prefix can either be the well-known IPv6 prefix (WKP)
ff9b::/96, or a network-specific prefix that is unique to the 64:ff9b::/96, or a network-specific prefix that is unique to the
Autonomous System; and for the latter case, the IPv6 prefix length Autonomous System; and for the latter case, the IPv6 prefix length
may be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is 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 used during the address translation between an IPv4 address and an
IPv4-embedded IPv6 address, as described in [RFC6052]. IPv4-embedded IPv6 address, as described in [RFC6052].
During translation from an IPv4 header to an IPv6 header at an During translation from an IPv4 header to an IPv6 header at an
ingress AFXLBR, the source IPv4 address and destination IPv4 address ingress AFXLBR, the source IPv4 address and destination IPv4 address
are translated into the corresponding IPv6 source address and are translated into the corresponding IPv6 source address and
destination IPv6 address, respectively, and during translation from destination IPv6 address, respectively, and during translation from
an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6 an IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6
address and destination IPv6 address are translated into the address and destination IPv6 address are translated into the
corresponding IPv4 source address and destination IPv4 address, corresponding IPv4 source address and destination IPv4 address,
respectively. Note that the address translation is accomplished in a respectively. Note that the address translation is accomplished in a
stateless manner. stateless manner.
When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only
global IPv4 addresses to be embedded in the IPv6 address. An AFXLBR global IPv4 addresses to be embedded in the IPv6 address. An IPv6
MUST NOT translate packets in which an address is composed of the WKP address composed with a WKP and a non-global IPv4 address is hence
and a non-global IPv4 address; they MUST drop these packets. 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 In the case where both the IPv4 client networks and the IPv6 transit
network belong to the same organization, non-global IPv4 addresses network belong to the same organization, non-global IPv4 addresses
may be used with a network-specific prefix [RFC6052]. may be used with a network-specific prefix [RFC6052].
5. Advertising IPv4-embedded IPv6 Routes 5. Advertising IPv4-embedded IPv6 Routes
In order to forward IPv4 packets to the proper destination across an In order to forward IPv4 packets to the proper destination across an
IPv6 network, IPv4 reachability needs to be disseminated throughout IPv6 network, IPv4 reachability needs to be disseminated throughout
the IPv6 network and this is performed by AFXLBRs that connect to the IPv6 network and this is performed by AFXLBRs that connect to
skipping to change at page 10, line 31 skipping to change at page 10, line 18
IPv4 addresses and prefixes in an IPv4 client network are translated IPv4 addresses and prefixes in an IPv4 client network are translated
into IPv4-embedded IPv6 addresses and prefixes, respectively, using into IPv4-embedded IPv6 addresses and prefixes, respectively, using
the IPv6 prefix allocated by the Autonomous System and the method the IPv6 prefix allocated by the Autonomous System and the method
specified in [RFC6052]. These routes are then advertised by one or specified in [RFC6052]. These routes are then advertised by one or
more attached ASBRs into the IPv6 transit network using AS-External- more attached ASBRs into the IPv6 transit network using AS-External-
LSAs [RFC5340], i.e., with advertising scope comprising the entire LSAs [RFC5340], i.e., with advertising scope comprising the entire
Autonomous System. Autonomous System.
5.1.1. Routing Metrics 5.1.1. Routing Metrics
By default, the metric in an AS-External-LSA that carries an IPv4- By default, the metric in an AS-External-LSA that carries an
embedded IPv6 address or prefixes is a Type 1 external metric, which IPv4-embedded IPv6 address or prefixes is a Type 1 external metric,
is comparable to the link state metric and we assume that in most which is comparable to the link state metric and we assume that in
cases, OSPFv2 is used in client IPv4 networks. This metric is added most cases, OSPFv2 is used in client IPv4 networks. This metric is
to the metric of the intra-AS path to the ASBR during the OSPFv3 added to the metric of the intra-AS path to the ASBR during the
route calculation. Through ASBR configuration, the metric can be set OSPFv3 route calculation. Through ASBR configuration, the metric can
to a Type 2 external metric, which is considered much larger than the be set to a Type 2 external metric, which is considered much larger
metric for any intra-AS path. Refer to the OSPFv3 specification than the metric for any intra-AS path. Refer to the OSPFv3
[RFC5340] for more detail. In either case, an external metric may specification [RFC5340] for more detail. In either case, an external
take the same value as in an IPv4 network (using OSPFv2 or another metric may take the same value as in an IPv4 network (using OSPFv2 or
routing protocol), but may also be specified based on some routing another routing protocol), but may also be specified based on some
policy; the details of which are outside of the scope of this routing policy; the details of which are outside of the scope of this
document. document.
5.1.2. Forwarding Address 5.1.2. Forwarding Address
If the "Forwarding Address" field of an OSPFv3 AS-External-LSA is 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 used to carry an IPv6 address, that must also be an IPv4-embedded
IPv6 address where the embedded IPv4 address is the destination IPv6 address where the embedded IPv4 address is the destination
address in an IPv4 client network. However, since an AFXLBR sits on 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 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 that the "Forwarding Address" field is not used, so that the AFXLBR
skipping to change at page 11, line 26 skipping to change at page 11, line 13
through configuration. through configuration.
For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT
be advertised into any IPv6 client networks that also connected to be advertised into any IPv6 client networks that also connected to
the IPv6 transit network. the IPv6 transit network.
6. Aggregation on IPv4 Addresses and Prefixes 6. Aggregation on IPv4 Addresses and Prefixes
In order to reduce the amount of LSAs that are injected to the IPv6 In order to reduce the amount of LSAs that are injected to the IPv6
network, an implementation should provide mechanisms to aggregate network, an implementation should provide mechanisms to aggregate
IPv4 addresses and prefixes at AFXLBR prior to advertisement as IPv4- IPv4 addresses and prefixes at AFXLBR prior to advertisement as
embedded IPv6 addresses and prefixes. In general, the aggregation IPv4-embedded IPv6 addresses and prefixes. In general, the
practice should be based on routing policy, which is outside of the aggregation practice should be based on routing policy, which is
scope of this document. outside of the scope of this document.
7. Forwarding 7. Forwarding
There are three cases in forwarding IP packets in the scenario There are three cases in forwarding IP packets in the scenario
described in this document: described in this document:
1. On an AFXLBR, if an IPv4 packet that is received on an interface 1. On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 client network with a destination IPv4 connecting to an IPv4 client network with a destination IPv4
address belonging to another IPv4 client network, the header of address belonging to another IPv4 client network, the header of
the packet is translated to the corresponding IPv6 header as the packet is translated to the corresponding IPv6 header as
skipping to change at page 12, line 20 skipping to change at page 12, line 9
The classification of IPv4-embedded IPv6 packet is according to the The classification of IPv4-embedded IPv6 packet is according to the
IPv6 prefix of the destination address, which is either the Well IPv6 prefix of the destination address, which is either the Well
Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in Known Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in
[RFC6052]. [RFC6052].
8. Backdoor Connections 8. Backdoor Connections
In some deployments, IPv4 client networks are inter-connected across In some deployments, IPv4 client networks are inter-connected across
the IPv6 network, but also directly connected to each other. The the IPv6 network, but also directly connected to each other. The
"backdoor" connections between IPv4 client networks can certainly be direct connections between IPv4 client networks, as sometimes called
used to transport IPv4 packets between IPv4 client networks. In "backdoor" connections, can certainly be used to transport IPv4
general, backdoor connections are preferred over the IPv6 network, packets between IPv4 client networks. In general, backdoor
since there requires no address family translation. connections are preferred over the IPv6 network since there requires
no address family translation.
9. Prevention of Loops 9. Prevention of Loops
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.
10. Prevention of Loops
If an LSA sent from an AFXLBR into a client network could then be 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 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 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 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 ignore any LSA received from a client network that already has the
DN-bit sent. DN-bit sent.
10. MTU Issues 11. MTU Issues
In the IPv6 network, there are no new MTU issues introduced by this In the IPv6 network, there are no new MTU issues introduced by this
document. If a separate OSPFv3 instance (per [RFC5838]) is used for document. If a separate OSPFv3 instance (per [RFC5838]) is used for
IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
the same as that of the default OSPFv3 instance. If a separate 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 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 IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
the same as that of the default OSPFv3 topology. the same as that of the default OSPFv3 topology.
However, the MTU in the IPv6 network may be different than that of However, the MTU in the IPv6 network may be different than that of
skipping to change at page 13, line 12 skipping to change at page 13, line 19
network. In order to achieve this requirement, it is recommended network. In order to achieve this requirement, it is recommended
that AFXLBRs perform IPv6 path discovery among themselves and the that AFXLBRs perform IPv6 path discovery among themselves and the
resulting MTU, after taking into account of the difference between resulting MTU, after taking into account of the difference between
the IPv4 header length and the IPv6 header length, must be the IPv4 header length and the IPv6 header length, must be
"propagated" into IPv4 client networks, e.g., included in the OSPFv2 "propagated" into IPv4 client networks, e.g., included in the OSPFv2
Database Description packet. Database Description packet.
The details of passing the proper MTU into IPv4 client networks are The details of passing the proper MTU into IPv4 client networks are
beyond the scope of this document. beyond the scope of this document.
11. Security Considerations 12. Security Considerations
There are several security aspects that require attention in the There are several security aspects that require attention in the
deployment practice described in this document. deployment practice described in this document.
In the OSPFv3 transit network, the security considerations for OSPFv3 In the OSPFv3 transit network, the security considerations for OSPFv3
are covered in [RFC5340], and in particular, IPsec can be used for are covered in [RFC5340], and in particular, IPsec can be used for
OSPFv3 authentication and confidentiality as suggested in [RFC5838]. OSPFv3 authentication and confidentiality as suggested in [RFC5838].
When a separate OSPFv3 instance is used to support IPv4-embedded IPv6 When a separate OSPFv3 instance is used to support IPv4-embedded IPv6
routing, the same Security Association (SA) (refer to [RFC4552] ) routing, the same Security Association (SA) (refer to [RFC4552] )
must be used by the embedded IPv4 address instance as other instances must be used by the embedded IPv4 address instance as other instances
utilizing the same link as specified in [RFC5838]. utilizing the same link as specified in [RFC5838].
Security considerations as currently documented in [RFC6052] must Security considerations as currently documented in [RFC6052] must
also be thought through with proper implementation in this also be thought through with proper implementation including the
engineering practice including the following: following:
o The IPv6 prefix that is used to carry an embedded IPv4 address o The IPv6 prefix that is used to carry an embedded IPv4 address
(refer to Section 4.1) must be configured by the authorized (refer to Section 4.1) must be configured by the authorized
operator on all participating AFXLBRs in a secure manner. This is operator on all participating AFXLBRs in a secure manner. This is
to help prevent an malicious attack resulting in network to help prevent an malicious attack resulting in network
disruption, denial of service, and possible information disruption, denial of service, and possible information
disclosure. disclosure.
o Effective mechanisms (such as reverse path checking) must be o Effective mechanisms (such as reverse path checking) must be
implemented in the IPv6 transit network (including AFXLIBR nodes) implemented in the IPv6 transit network (including AFXLIBR nodes)
to prevent spoofing on embedded IPv4 addresses, which, otherwise, to prevent spoofing on embedded IPv4 addresses, which, otherwise,
might be used as source addresses of malicious packets. might be used as source addresses of malicious packets.
o If firewalls are used in IPv4 and/or IPv6 networks, the o If firewalls are used in IPv4 and/or IPv6 networks, the
configuration on the routers must be consistent so there are no configuration on the routers must be consistent so there are no
holes in the IPv4 address filtering. holes in the IPv4 address filtering.
The details of security handling for this engineering practice are The details of security handling are beyond the scope of this
beyond the scope of this document. document.
12. IANA Considerations 13. IANA Considerations
No new IANA assignments are required for this document. No new IANA assignments are required for this document.
13. Acknowledgements 14. Acknowledgements
Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and Many thanks to Acee Lindem, Dan Wing, Joel Halpern, Mike Shand and
Brian Carpenter for their comments. Brian Carpenter for their comments.
14. References 15. References
14.1. Normative References 15.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Link State Advertisement (LSA) Options Bit to Prevent Link State Advertisement (LSA) Options Bit to Prevent
Looping in BGP/MPLS IP Virtual Private Networks (VPNs)", Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
RFC 4576, June 2006. RFC 4576, June 2006.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009. Framework", RFC 5565, June 2009.
[RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R. [RFC5838] Lindem, A., Mirtorabi, S., Roy, A., Barnes, M., and R.
Aggarwal, "Support of Address Families in OSPFv3", Aggarwal, "Support of Address Families in OSPFv3", RFC
RFC 5838, April 2010. 5838, April 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011. Algorithm", RFC 6145, April 2011.
14.2. Informative References 15.2. Informative References
[I-D.ietf-ospf-mt-ospfv3] [I-D.ietf-ospf-mt-ospfv3]
Mirtorabi, S. and A. Roy, "Multi-topology routing in Mirtorabi, S. and A. Roy, "Multi-topology routing in
OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in OSPFv3 (MT-OSPFv3)", draft-ietf-ospf-mt-ospfv3-03 (work in
progress), July 2007. progress), July 2007.
[RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality [RFC4552] Gupta, M. and N. Melam, "Authentication/Confidentiality
for OSPFv3", RFC 4552, June 2006. for OSPFv3", RFC 4552, June 2006.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF [RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
skipping to change at page 15, line 18 skipping to change at page 15, line 21
Dean Cheng Dean Cheng
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
Santa Clara, California 95050 Santa Clara, California 95050
USA USA
Email: dean.cheng@huawei.com Email: dean.cheng@huawei.com
Mohamed Boucadair Mohamed Boucadair
France Telecom France Telecom
Rennes, 35000 Rennes 35000
France France
Email: mohamed.boucadair@orange.com Email: mohamed.boucadair@orange.com
Alvaro Retana Alvaro Retana
Cisco Systems Cisco Systems
7025 Kit Creek Rd. 7025 Kit Creek Rd.
Research Triangle Park, North Carolina 27709 Research Triangle Park, North Carolina 27709
USA USA
 End of changes. 40 change blocks. 
125 lines changed or deleted 136 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/