draft-ietf-ospf-ipv4-embedded-ipv6-routing-02.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-03.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: September 30, 2012 France Telecom Expires: January 4, 2013 France Telecom
March 29, 2012 July 3, 2012
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-02 draft-ietf-ospf-ipv4-embedded-ipv6-routing-03
Abstract Abstract
This document describes routing packets destined to IPv4-embedded This document describes routing packets destined to IPv4-embedded
IPv6 addresses across IPv6 transit core using OSPFv3 with a separate IPv6 addresses across IPv6 transit 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
skipping to change at page 1, line 33 skipping to change at page 1, line 33
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 September 30, 2012. This Internet-Draft will expire on January 4, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 IETF Trust and the persons identified as the Copyright (c) 2012 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
skipping to change at page 2, line 16 skipping to change at page 2, line 16
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . 5 1.4. OSPFv3 Routing with a Specific Topology . . . . . . . . . 5
2. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 6 2. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 6 2.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 6
2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing 2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing
Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 6 2.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7
2.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7 2.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7
3. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7 3. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7
3.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 3.1. Address Translation . . . . . . . . . . . . . . . . . . . 8
4. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 4. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8
4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 4.1. Advertising IPv4-embedded IPv6 Routes into IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 8 Transit Network . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 4.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9
4.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9 4.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9
4.2. Advertising IPv4 Addresses into Client Networks . . . . . 9 4.2. Advertising IPv4 Addresses into Client Networks . . . . . 9
5. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 9 5. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 9
skipping to change at page 3, line 20 skipping to change at page 3, line 20
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
the rules defined in [RFC6052]. the rules defined in [RFC6052].
o IPv4-embedded IPv6 packets are packets of which destination o IPv4-embedded IPv6 packets are packets of which destination
addresses are IPv4-embedded IPv6 addresses. addresses are IPv4-embedded IPv6 addresses.
o AFBR (Address Family Border Router, [RFC5565]) refers to an edge o AFBR (Address Family Border Router, [RFC5565]) refers to an edge
router, which supports both IPv4 and IPv6 address families, of a router (PE), which supports both IPv4 and IPv6 address families,
backbone that supports only IPv4 or IPv6 address family. but the backbone network the PE connects to only supports IPv4 or
IPv6 address family.
o AFXLBR (Address Family Translation Border Router) is defined in o AFXLBR (Address Family Translation Border Router) is defined in
this document. It refers to a border router that supports both this document. It refers to a border router that supports both
IPv4 and IPv6 address families, located on the boundary of IPv4- IPv4 and IPv6 address families, located on the boundary of IPv4-
only network and IPv6-only network, and is capable of performing only network and IPv6-only network, and is capable of performing
IP header translation between IPv4 and IPv6 according to IP header translation between IPv4 and IPv6 according to
[RFC6145]. [RFC6145].
1.1. The Scenario 1.1. The Scenario
Due to exhaustion of public IPv4 addresses, there has been continuing Due to exhaustion of public IPv4 addresses, there has been continuing
effort within IETF on IPv6 transitional techniques. In the course of effort within IETF on IPv6 transitional techniques. In the course of
transition, it is certain that networks based on IPv4 and IPv6 transition, it is certain that networks based on IPv4 and IPv6
transfer capabilities, respectively, will co-exist at least for some technologies respectively, will co-exist at least for some time. One
time. One scenario of the co-existence is that IPv4-only networks scenario of the co-existence is that IPv4-only networks inter-
inter-connecting with IPv6-only networks, and in particular, when an connecting with IPv6-only networks, and in particular, when an IPv6-
IPv6-only network serves as a transit network that inter-connects only network serves as a transit network that inter-connects several
several segregated IPv4-only networks. In this scenario, IPv4 segregated IPv4-only networks. In this scenario, IPv4 packets are
packets are transported over the IPv6 transit network between IPv4 transported over the IPv6 transit network between IPv4 networks. In
networks. In order to forward an IPv4 packet from a source IPv4 order to forward an IPv4 packet from a source IPv4 network to the
network to the destination IPv4 network, IPv4 reachability destination IPv4 network, IPv4 reachability information must be
information must be exchanged among involved networks by dedicated exchanged between the IPv4 networks by some mechanisms.
means.
Unlike dual-stack networks, operating an IPv6-only network would In general, running an IPv6-only network would reduce OPEX and
allow optimize OPEX and maintenance operations in particular. Some optimize the operation comparing to IPv4-IPv6 dual-stack environment.
solutions have been proposed to allow delivery of IPv4 services over Some solutions have been proposed to allow delivery of IPv4 services
an IPv6-only network. This document focuses on an engineering over an IPv6-only network. This document focuses on an engineering
techniques which aims to separate the routing instance dedicated to techniques which aims to separate the routing table dedicated to
IPv4-embedded IPv6 destination from native IPv6 ones. IPv4-embedded IPv6 destination from native IPv6 ones.
The purpose of running separate instances or topologies for IPv4- Maintaining a separate routing table for IPv4-embedded IPv4 routes
embedded IPv6 traffic is to distinguish from the native IPv6 routing optimizes IPv4 packets forwarding process. It also prevents any
topology, and the topology that is used for routing IPv4-embedded overload of the native IPv6 routing tables. A separate routing table
IPv6 datagram only. Separate instances/topologies are also meant to can be generated from a separate routing instance or a separate
prevent any overload of the native IPv6 routing tables by IPv4- routing topology.
embedded IPv6 routes.
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 interface facing IPv4 client Border Routers) support IPv4 on interface facing IPv4 client
networks, and IPv6 on interface facing the core. The routing networks, and IPv6 on interface 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 with each other, and the AFBRs to exchange IPv4 routing information with each other, and the
IPv4 packets are forwarded from one IPv4 client network to the other IPv4 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 interconnected by an IPv6
transit network, and in particular, we name the border node on the transit network. We name the border node on the boundary of an IPv4
boundary of an IPv4 client network and the IPv6 transit network as client network and the IPv6 transit network as Address Family
Address Family Translation Border Router, or AFXLBR, which supports Translation Border Router (AFXLBR), which supports both IPv4 and IPv6
both IPv4 and IPv6 address families, and is capable of translating an address families, and is capable of translating an IPv4 packet to an
IPv4 packet to an IPv6 packet, and vice versa, according to IPv6 packet, and vice versa, according to [RFC6145].
[RFC6145].
Since the scenario occurs most in a single ISP operating environment, Since the scenario occurs most in a single ISP operating environment,
an IPv6 prefix can be locally allocated and used to construct IPv4- an IPv6 prefix can be locally allocated and used to construct IPv4-
embedded IPv6 addresses according to [RFC6052] by each AFXLBR, where embedded IPv6 addresses according to [RFC6052] by each AFXLBR. The
the embedded IPv4 addresses are associated with an IPv4 client embedded IPv4 address or prefix belongs to an IPv4 client network
network that is connected to the AFXLBR, and each IPv4 address is an that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded
individual IPv4 address or prefix. An AFXLBR injects IPv4-embedded IPv6 addresses and prefixes into the IPv6 transit network using
IPv6 addresses/prefixes into the IPv6 transit network using OSPFv3 OSPFv3, and it also installs IPv4-embedded IPv6 routes advertised by
and also installs those advertised by other AFXLBRs. When an IPv4 other AFXLBRs.
packet is sent from one IPv4 client network to the other, it is first
encapsulated with an IPv6 header, where the source and destination When an AFXLBR receives an IPv4 packet from a locally connected IPv4
IPv6 address are constructed, in a stateless manner, as IPv4-embedded client network and destined to a remote IPv4 client network, it
IPv6 address, respectively, and then forwarded to the destination translates the IPv4 header to the relevant IPv6 header according to
AFXLBR that is the advertising router of the destination IPv4- [RFC6145], and in that process, source and destination IPv4 address
embedded IPv6 address. The destination AFXLBR replaces the IPv6 are translated into IPv4-embedded IPv6 addresses, respectively,
header by the corresponding IPv4 header, where the source and according to [RFC6052]. The resulting IPv6 packet is then forwarded
destination IPv4 addresses are derived from the IPv4-embedded IPv6 to the AFXLBR that connects to the destination IPv4 client network.
source and destination addresses, respectively, and then forwards the The remote AFXLBR derives the IPv4 source and destination addresses
IPv4 packet using its IPv4 routing table in the attached IPv4 client from the IPv4-embedded IPv6 addresses, respectively, according to
network. [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. 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 One case is that some border nodes do not participate in i-BGP for
routes exchange (one example is documented in routes exchange (one example is documented in
[I-D.boucadair-softwire-dslite-v6only]), or i-BGP is not used at all. [I-D.boucadair-softwire-dslite-v6only]), or i-BGP is not used at all.
Another case is that tunnel mechanism is not used in the IPv6 transit Another case is that tunnel mechanism is not used in the IPv6 transit
network, or native IPv6 forwarding is preferred. Note also that with network, or native IPv6 forwarding is preferred. Note that with this
this routing solution, the IPv4-IPv6 inter-connection and associated routing solution, the IPv4 and IPv6 header translation that occurs at
header translation that occurs at an AFXLBR is stateless. an AFXLBR in both diretions is stateless.
1.4. OSPFv3 Routing with a Specific Topology 1.4. OSPFv3 Routing with a Specific Topology
Routing IPv4-embedded IPv6 packets in the IPv6 transit network using In general, IPv4-embedded IPv6 packets can be forwarded just like
OSPFv3, in general, may be performed by the OSPFv3 operation that is native IPv6 packets with OSPFv3 running in the IPv6 transit network.
already running in the IPv6 network. One concern however, is that However, this would require IPv4-embedded IPv6 routes to be flooded
IPv4-embedded IPv6 routes would flood throughout the entire transit throughout the entire transit network and stored on every router.
network and stored on every router, which may not be desirable. This is not desirable in the scaling perspective. Moreover, since
Also, since all IPv6 routes are stored in the same routing table, it all IPv6 routes are stored in the same routing table, it is
might be more difficult to manage the resource required for routing inconvenient to manage the resource required for routing and
and forwarding based on traffic category, if so desired. To solve forwarding based on traffic category, if so desired.
this problem and to ease the separation between native IPv6 and IPv4-
inferred routing policies, a separate OSPFv3 routing table can be To improve the situation, a separate OSPFv3 routing table can be
constructed that is dedicated to IPv4-embedded IPv6 topology, and constructed that is dedicated to IPv4-embedded IPv6 topology, and
that table is solely used for routing IPv4-embedded IPv6 packets that table is solely used for routing IPv4-embedded IPv6 packets in
(i.e., IPv4 part of the Internet) in the transit network. Further, the IPv6 transit network. The IPv4-embedded IPv6 topology include
only a set of routers in the transit network are required to be all the participating AFXLBR routers and a set of P routers for
involved in such routing scheme, including AFXLBRs that connect to connectivity and routing paths.
IPv4 client networks along with a set of P routers in the core for
routing path.
Below are listed some examples to build a separate OSPFv3 routing There are two methods to build a separate OSPFv3 routing table for
table for IPv4-embedded IPv6 routing: IPv4-embedded IPv6 routes as follows:
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 IPv4-
embedded IPv6 topology in the IPv6 transit network according to embedded IPv6 topology in the IPv6 transit network according to
[RFC5838], [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 transit network, but maintain a separate already operates in the transit network, but maintain a separate
IPv4-embedded topology, according to [I-D.ietf-ospf-mt-ospfv3]. IPv4-embedded IPv6 topology, according to
[I-D.ietf-ospf-mt-ospfv3].
With both methods, there would be a dedicated IPv4-embedded IPv6 With either method, there would be a dedicated IPv4-embedded IPv6
topology that is maintained by OSPFv3 speakers and thus a dedicated topology that is maintained on all participating AFXLBR and P
IPv4-embedded IPv6 routing table, which is then used for routing routers, along with a dedicated IPv4-embedded IPv6 routing table.
IPv4-embedded IPv6 packets (i.e., packets destined to an IPv4
destination). It would be operators' preference as which method is The routing table is then used solely in the IPv6 transit network for
going to be used. This document elaborates on how configuration is IPv4-embedded IPv6 packets.
done for each method and related routing issues that is common to
both. 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 is 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. Provisioning 2. Provisioning
2.1. Deciding the IPv4-embedded IPv6 Topology 2.1. Deciding the IPv4-embedded IPv6 Topology
Before making appropriate configuration in order to generate a Before making appropriate configuration in order to generate a
separate OSPFv3 routing table for IPv4-embedded IPv6 addresses/ separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and
prefixes, decision must be made on the set of routers and their prefixes, decision must be made on the set of routers and their
interfaces in the IPv6 transit network that should be on the IPv4- interfaces in the IPv6 transit network that should be on the IPv4-
embedded IPv6 topology. embedded IPv6 topology.
For the purpose of this topology, all AFXLBRs that connect to IPv4 For the purpose of this topology, all AFXLBRs that connect to IPv4
client networks should be members of this topology, and also at least client networks must be members of this topology, and also at least
some of their network core facing interfaces, which depends on which some of their network core facing interfaces along with some P
P routers in the IPv6 transit network would be on this topology. routers in the IPv6 transit network would be on this topology.
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
transit network, and if all routers (including AFXLBRs and P-routers) transit network, and if all routers (including AFXLBRs and P-routers)
and their interfaces are included, the two topologies converge. In and all their interfaces are included, the two topologies converge.
general, as more P routers and their interfaces are configured on In general, as more P routers and their interfaces are configured on
this sub-topology, it would increase the inter-connectivity and this sub-topology, it would increase the inter-connectivity and
potentially, there would be more routing paths cross the transit potentially, there would be more routing paths across the transit
network from one IPv4 client network to the other, at the cost that network from one IPv4 client network to the other, at the cost that
more routers need to participate the IPv4-embedded IPv6 routing. In more routers need to participate the IPv4-embedded IPv6 routing. In
any case, the IPv4-embedded IPv6 topology must be continuous with no any case, the IPv4-embedded IPv6 topology must be continuous with no
partitions. partitions.
2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table
In an IPv6 transit network, in order to maintain a separate IPv6 In an IPv6 transit network, in order to maintain a separate IPv6
routing table that contains routes for IPv4-embedded IPv6 routing table that contains routes for IPv4-embedded IPv6
destinations only, OSPFv3 needs to use the mechanism defined either destinations only, OSPFv3 needs to use the mechanism defined either
in [RFC5838] or [I-D.ietf-ospf-mt-ospfv3] with required configuration in [RFC5838] or in [I-D.ietf-ospf-mt-ospfv3] with required
tasks, as described in the following sub-sections. configuration, as described in the following sub-sections.
2.3. OSPFv3 Topology with a Separate Instance ID 2.3. OSPFv3 Topology with a Separate Instance ID
It is assumed that the scenario as described in this document is It is assumed that the scenario as described in this document is
under a single ISP and as such, an OSPFv3 instance ID (IID) is under a single ISP and as such, an OSPFv3 instance ID (IID) is
allocated locally and used for an OSPFv3 operation dedicated to allocated locally and used for an OSPFv3 operation dedicated to
unicast IPv4-embedded IPv6 routing in an IPv6 transit network. This unicast IPv4-embedded IPv6 routing in an IPv6 transit network. This
IID is configured on each OSPFv3 interface of routers that IID is configured on each OSPFv3 interface of routers that
participates in this routing instance. participates in this routing instance.
skipping to change at page 8, line 8 skipping to change at page 8, line 11
the mechanism described above, an IPv4 packet is translated to an the mechanism described above, an IPv4 packet is translated to an
IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated back IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated back
to the original IPv4 packet at egress AFXLBR. The IP packet to the original IPv4 packet at egress AFXLBR. The IP packet
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 detail explained specified in [RFC6145], with the address translation detail explained
in the next sub-section. in the next sub-section.
3.1. Address Translation 3.1. Address Translation
Prior to the operation, an IPv6 prefix is allocated by the ISP and it Prior to the operation, an IPv6 prefix is allocated by the ISP and it
is used to form an IPv4-embedded IPv6 address. is used to form IPv4-embedded IPv6 addresses.
The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 64: The IPv6 prefix can either be a well-known IPv6 prefix (WKP) 64:
ff9b::/96, or a network-specific prefix that is unique to the ISP, ff9b::/96, or a network-specific prefix that is unique to the ISP;
and for the later case, the IPv6 prefix length may be 32, 40, 48, 56 and for the later case, the IPv6 prefix length may be 32, 40, 48, 56
or 64. In either case, this IPv6 prefix is used during the address or 64. In either case, this IPv6 prefix is used during the address
translation between an IPv4 address and an IPv4-embedded IPv6 translation between an IPv4 address and an IPv4-embedded IPv6
address, which is performed according to [RFC6052]. address, which is performed according to [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
skipping to change at page 8, line 45 skipping to change at page 8, line 48
that inter-connect a bunch of IPv4 client networks with an IPv6 that inter-connect a bunch of IPv4 client networks with an IPv6
transit network, we view that IPv4 networks and IPv6 networks belong transit network, we view that IPv4 networks and IPv6 networks belong
to separate Autonomous Systems, and as such, these AFXLBRs are OSPFv3 to separate Autonomous Systems, and as such, these AFXLBRs are OSPFv3
ASBRs. ASBRs.
4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 Transit Network 4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 Transit Network
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 same IPv6 prefix allocated by the ISP and the method specified in the same IPv6 prefix allocated by the ISP and the method specified in
[RFC6052], and then advertised by one or more attached ASBRs into the [RFC6052]. These routes are then advertised by one or more attached
IPv6 transit network using AS External LSA [RFC5340], i.e. - with the ASBRs into the IPv6 transit network using AS External LSA [RFC5340],
advertising scope throughout the entire Autonomous System. i.e. - with the advertising scope throughout the entire Autonomous
System.
4.1.1. Routing Metrics 4.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 IPv4-
embedded IPv6 address or prefixes is a Type 1 external metric, which embedded IPv6 address or prefixes is a Type 1 external metric, which
is then to be added to the metric of an intra-AS path during OSPFv3 is then to be added to the metric of an intra-AS path during OSPFv3
routes calculation. By configuration on an ASBR, the metric can be routes calculation. By configuration on an ASBR, the metric can be
set to a Type 2 external metric, which is considered much larger than set to a Type 2 external metric, which is considered much larger than
that on any intra-AS path. The detail is referred to OSPFv3 that on any intra-AS path. The detail is referred to OSPFv3
specification [RFC5340]. In either case, an external metric may be specification [RFC5340]. In either case, an external metric may take
exact the same unit as in an IPv4 network (running OSPFv2 or others), the same value as in an IPv4 network (running OSPFv2 or others), but
but may also be specified by a routing policy, the detail is outside may also be specified based on some routing policy; the detail is
of the scope of this document. outside of the scope of this document.
4.1.2. Forwarding Address 4.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 actual address in IPv6 address where the embedded IPv4 address is the destination
an IPv4 client network to which, data traffic is forwarded to. address in an IPv4 client network. However, since an AFXLBR sits on
However, since an AFXLBR sits on the border of an IPv4 network and an the border of an IPv4 network and an IPv6 network, it is recommended
IPv6 network, it is recommended that the "Forwarding Address" field that the "Forwarding Address" field not to be used by setting the F
not to be used by setting the F bit in the associated OSPFv3 AS- bit in the associated OSPFv3 AS-external-LSA to zero, so that the
external-LSA to zero, so that the AFXLBR can make the forwarding AFXLBR can make the forwarding decision based on its own IPv4 routing
decision based on its own IPv4 routing table. table.
4.2. Advertising IPv4 Addresses into Client Networks 4.2. Advertising IPv4 Addresses into Client Networks
IPv4-embedded IPv6 routes injected into the IPv6 transit network from IPv4-embedded IPv6 routes injected into the IPv6 transit network from
one IPv4 client network may be advertised into another IPv4 client one IPv4 client network may be advertised into another IPv4 client
network, after the associated destination addresses/prefixes are network, after the associated destination addresses and prefixes are
translated back to IPv4 addresses/prefixes format. This operation is translated back to IPv4 addresses and prefixes, respectively. This
similar to the regular OSPFv3 operation, wherein an AS External LSA operation is similar to the regular OSPFv3 operation, wherein an AS
can be advertised in a non-backbone area by default. External LSA can be advertised in a non-backbone area by default.
An IPv4 client network that does not want to receive such An IPv4 client network that does not want to receive such
advertisement can be configured as a stub area or with other routing advertisement can be configured as a stub area or with other routing
policy. policy.
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.
5. Aggregation on IPv4 Addresses and Prefixes 5. Aggregation on IPv4 Addresses and Prefixes
skipping to change at page 10, line 40 skipping to change at page 10, line 42
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].
7. MTU Issues 7. MTU Issues
In the IPv6 transit network, there is no new MTU issue introduced by In the IPv6 transit network, there is no new MTU issue introduced by
this document. If a separate OSPFv3 instance (per [RFC5838]) is used this document. If a separate OSPFv3 instance (per [RFC5838]) is used
for IPv4-embedded IPv6 routing, the MTU handling in the transit for IPv4-embedded IPv6 routing, the MTU handling in the transit
network is the same as that of the default OSPFv3 instance. If a network is the same as that of the default OSPFv3 instance. If a
separate OSPFv3 topology is used for IPv4-embedded IPv6 routing, the separate OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is
MTU handling in the transit network is the same as that of the used for IPv4-embedded IPv6 routing, the MTU handling in the transit
default OSPFv3 topology. network is the same as that of the default OSPFv3 topology.
However, the MTU in the IPv6 transit network may be different than However, the MTU in the IPv6 transit network may be different than
that of IPv4 client networks. Since an IPv6 router will never that of IPv4 client networks. Since an IPv6 router will never
fragment a packet, the packet size of any IPv4-embedded IPv6 packet fragment a packet, the packet size of any IPv4-embedded IPv6 packet
entering the IPv6 transit network must be equal to or smaller than entering the IPv6 transit network must be equal to or less than the
the MTU of the IPv6 transit network. In order to achieve this MTU of the IPv6 transit network. In order to achieve this
requirement, it is recommended that AFXLBRs to perform IPv6 path requirement, it is recommended that AFXLBRs to perform IPv6 path
discovery among themselves and the resulting MTU, after taking into discovery among themselves and the resulting MTU, after taking into
account of the difference between IPv4 header length and IPv6 header account of the difference between IPv4 header length and IPv6 header
length, must be "propagated" into IPv4 client networks, e.g.- length, must be "propagated" into IPv4 client networks, e.g.-
included in the OSPFv3 Database Description packet. included in the OSPFv2 Database Description packet.
The detail of passing the proper MTU into IPv4 client networks is The detail of passing the proper MTU into IPv4 client networks is
beyond the scope of this document. beyond the scope of this document.
8. Backdoor Connections 8. Backdoor Connections
In some deployments, there may exist direct connections among IPv4 In some deployments, IPv4 client networks are inter-connected across
client networks themselves in addition to the IPv6 transit network, the IPv6 transit network, but also directly connected to each other.
as "backdoor" connections referring to, where IPv4 packets can either The "backdoor" connections between IPv4 client networks can certainly
be transported between those IPv4 client networks via backdoor be used to transport IPv4 packets between IPv4 client networks. In
connections, or through the IPv6 transit network. In general, general, backdoor connections are prefered over the transportation
routing policies should be as such that the "backdoor" path is over the IPv6 transit network, since there requires no address family
preferred since the packet forwarding is within a single address translation.
family without the need for IP header translation, among other
things.
9. Security Considerations 9. Security Considerations
This document does not introduce any security issue than what has This document does not introduce any security issue than what has
been identified in [RFC5838] and [RFC6052]. been identified in [RFC5838] and [RFC6052].
10. IANA Considerations 10. IANA Considerations
No new IANA assignments are required for this document. No new IANA assignments are required for this document.
skipping to change at page 12, line 34 skipping to change at page 12, line 35
[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 5838, April 2010. RFC 5838, April 2010.
Authors' Addresses Authors' Addresses
Dean Cheng Dean Cheng
Huawei Technologies Huawei Technologies
2330 Central Expressway 2330 Central Expressway
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
 End of changes. 33 change blocks. 
127 lines changed or deleted 128 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/