draft-ietf-ospf-ipv4-embedded-ipv6-routing-03.txt   draft-ietf-ospf-ipv4-embedded-ipv6-routing-04.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: January 4, 2013 France Telecom Expires: January 14, 2013 France Telecom
July 3, 2012 A. Retana
Hewlett-Packard Co.
July 13, 2012
Routing for IPv4-embedded IPv6 Packets Routing for IPv4-embedded IPv6 Packets
draft-ietf-ospf-ipv4-embedded-ipv6-routing-03 draft-ietf-ospf-ipv4-embedded-ipv6-routing-04
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 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 January 4, 2013. This Internet-Draft will expire on January 14, 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 12 skipping to change at page 2, line 13
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 . . . . . . . . . . . . . . . . . . . . . . . . . 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. Requirements Language . . . . . . . . . . . . . . . . . . . . 6
2.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 6 3. Provisioning . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing 3.1. Deciding the IPv4-embedded IPv6 Topology . . . . . . . . . 6
3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing
Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6 Table . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7 3.3. OSPFv3 Topology with a Separate Instance ID . . . . . . . 7
2.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7 3.4. OSPFv3 Topology with the Default Instance . . . . . . . . 7
3. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7 4. IP Packets Translation . . . . . . . . . . . . . . . . . . . . 7
3.1. Address Translation . . . . . . . . . . . . . . . . . . . 8 4.1. Address Translation . . . . . . . . . . . . . . . . . . . 8
4. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8 5. Advertising IPv4-embedded IPv6 Routes . . . . . . . . . . . . 8
4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6
Transit Network . . . . . . . . . . . . . . . . . . . . . 8 Transit Network . . . . . . . . . . . . . . . . . . . . . 8
4.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9 5.1.1. Routing Metrics . . . . . . . . . . . . . . . . . . . 9
4.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9 5.1.2. Forwarding Address . . . . . . . . . . . . . . . . . . 9
4.2. Advertising IPv4 Addresses into Client Networks . . . . . 9 5.2. Advertising IPv4-embedded IPv6 Routes into an IPv6
5. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 9 Backbone . . . . . . . . . . . . . . . . . . . . . . . . . 9
6. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.2.1. Using Inter-Area-Prefix-LSAs . . . . . . . . . . . . . 10
7. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 10 5.3. Advertising IPv4 Addresses into Client Networks . . . . . 10
6. Aggregation on IPv4 Addresses and Prefixes . . . . . . . . . . 10
7. Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . 10
8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 11 8. Backdoor Connections . . . . . . . . . . . . . . . . . . . . . 11
9. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Prevention of Loops . . . . . . . . . . . . . . . . . . . . . 11
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 10. MTU Issues . . . . . . . . . . . . . . . . . . . . . . . . . . 12
11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
12.1. Normative References . . . . . . . . . . . . . . . . . . . 11 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
12.2. Informative References . . . . . . . . . . . . . . . . . . 12 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 14.1. Normative References . . . . . . . . . . . . . . . . . . . 12
14.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
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 IPv6 network. transported over an IPv6 network.
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 (PE), which supports both IPv4 and IPv6 address families, router, which supports both IPv4 and IPv6 address families, but
but the backbone network the PE connects to only supports IPv4 or the backbone network it connects to only supports either the IPv4
IPv6 address family. 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 an
only network and IPv6-only network, and is capable of performing IPv4-only network and an IPv6-only network, and is capable of
IP header translation between IPv4 and IPv6 according to performing IP header translation between IPv4 and IPv6 according
[RFC6145]. to [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 a
effort within IETF on IPv6 transitional techniques. In the course of continuing effort within the IETF on IPv6 transitional techniques.
transition, it is certain that networks based on IPv4 and IPv6 In the course of the transition, it is certain that networks based on
technologies respectively, will co-exist at least for some time. One IPv4 and IPv6 technologies respectively, will co-exist at least for
scenario of the co-existence is that IPv4-only networks inter- some time. One scenario of this co-existence is the inter-connection
connecting with IPv6-only networks, and in particular, when an IPv6- of IPv4-only and IPv6-only networks, and in particular, when an IPv6-
only network serves as a transit network that inter-connects several only network serves as inter-connection between several segregated
segregated IPv4-only networks. In this scenario, IPv4 packets are IPv4-only networks. In this scenario, IPv4 packets are transported
transported over the IPv6 transit network between IPv4 networks. In over the IPv6 network between IPv4 networks. In order to forward an
order to forward an IPv4 packet from a source IPv4 network to the IPv4 packet from a source IPv4 network to the destination IPv4
destination IPv4 network, IPv4 reachability information must be network, IPv4 reachability information must be exchanged between the
exchanged between the IPv4 networks by some mechanisms. 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 comparing 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
techniques which aims to separate the routing table dedicated to technique which aims to separate the routing table dedicated to IPv4-
IPv4-embedded IPv6 destination from native IPv6 ones. embedded IPv6 destinations from native IPv6 ones.
Maintaining a separate routing table for IPv4-embedded IPv4 routes Maintaining a separate routing table for IPv4-embedded IPv6 routes
optimizes IPv4 packets forwarding process. It also prevents any optimizes IPv4 packets forwarding. It also prevents overload of the
overload of the native IPv6 routing tables. A separate routing table native IPv6 routing tables. A separate routing table can be
can be generated from a separate routing instance or a separate generated from a separate routing instance or a separate routing
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 interface facing IPv4 client Border Routers) support IPv4 on interfaces facing IPv4 client
networks, and IPv6 on interface 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 with each other, and the AFBRs to exchange IPv4 routing information in the core, and the IPv4
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 interconnected by an IPv6
transit network. We name the border node on the boundary of an IPv4 network. We refer to the border node on the boundary of an IPv4
client network and the IPv6 transit network as Address Family client network and the IPv6 network as an Address Family Translation
Translation Border Router (AFXLBR), which supports both IPv4 and IPv6 Border Router (AFXLBR), which supports both the IPv4 and IPv6 address
address families, and is capable of translating an IPv4 packet to an families, and is capable of translating an IPv4 packet to an IPv6
IPv6 packet, and vice versa, according to [RFC6145]. packet, and vice versa, according to [RFC6145].
Since the scenario occurs most in a single ISP operating environment, Since the scenario occurs most commonly in a single Autonomous
an IPv6 prefix can be locally allocated and used to construct IPv4- System, an IPv6 prefix can be locally allocated and used by AFXLBRs
embedded IPv6 addresses according to [RFC6052] by each AFXLBR. The to construct IPv4-embedded IPv6 addresses according to [RFC6052].
embedded IPv4 address or prefix belongs to an IPv4 client network The embedded IPv4 address or prefix belongs to an IPv4 client network
that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded
IPv6 addresses and prefixes into the IPv6 transit network using IPv6 addresses and prefixes into the IPv6 network using OSPFv3, and
OSPFv3, and it also installs IPv4-embedded IPv6 routes advertised by it also installs IPv4-embedded IPv6 routes advertised by other
other AFXLBRs. AFXLBRs.
When an AFXLBR receives an IPv4 packet from a locally connected IPv4 When an AFXLBR receives an IPv4 packet from a locally connected IPv4
client network and destined to a remote IPv4 client network, it client network and destined to a remote IPv4 client network, it
translates the IPv4 header to the relevant IPv6 header according to translates the IPv4 header to the relevant IPv6 header according to
[RFC6145], and in that process, source and destination IPv4 address [RFC6145], and in that process, source and destination IPv4 address
are translated into IPv4-embedded IPv6 addresses, respectively, are translated into IPv4-embedded IPv6 addresses, respectively,
according to [RFC6052]. The resulting IPv6 packet is then forwarded according to [RFC6052]. The resulting IPv6 packet is then forwarded
to the AFXLBR that connects to the destination IPv4 client network. to the AFXLBR that connects to the destination IPv4 client network.
The remote AFXLBR derives the IPv4 source and destination addresses The remote AFXLBR derives the IPv4 source and destination addresses
from the IPv4-embedded IPv6 addresses, respectively, according to from the IPv4-embedded IPv6 addresses, respectively, according to
[RFC6052], and translates the header of the received IPv6 packet to [RFC6052], and translates the header of the received IPv6 packet to
the relevant IPv4 header according to [RFC6145]. The resulting IPv4 the relevant IPv4 header according to [RFC6145]. The resulting IPv4
packet is then forwarded according to the IPv4 routing table packet is then forwarded according to the IPv4 routing table
maintained on the AFXLBR. 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, or i-BGP is not used at all. Another case is when
[I-D.boucadair-softwire-dslite-v6only]), or i-BGP is not used at all. tunnels are not deployed in the IPv6 network, or native IPv6
Another case is that tunnel mechanism is not used in the IPv6 transit forwarding is preferred. Note that with this routing solution, the
network, or native IPv6 forwarding is preferred. Note that with this IPv4 and IPv6 header translation performed in both directions by the
routing solution, the IPv4 and IPv6 header translation that occurs at 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
In general, IPv4-embedded IPv6 packets can be forwarded just like In general, IPv4-embedded IPv6 packets can be forwarded just like
native IPv6 packets with OSPFv3 running in the IPv6 transit network. native IPv6 packets with OSPFv3 running in the IPv6 network.
However, this would require IPv4-embedded IPv6 routes to be flooded However, this would require IPv4-embedded IPv6 routes to be flooded
throughout the entire transit network and stored on every router. throughout the entire IPv6 network and stored on every router. This
This is not desirable in the scaling perspective. Moreover, since is not desirable from the scaling perspective. Moreover, since all
all IPv6 routes are stored in the same routing table, it is 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 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 transit network. The IPv4-embedded IPv6 topology include the IPv6 network. The IPv4-embedded IPv6 topology includes all the
all the participating AFXLBR routers and a set of P routers for participating AFXLBR routers and a set of P routers providing
connectivity and 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 as follows: 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 IPv4-
embedded IPv6 topology in the IPv6 transit network according to embedded IPv6 topology in the IPv6 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 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-
The routing table is then used solely in the IPv6 transit 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 is 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. Provisioning 2. Requirements Language
2.1. Deciding the IPv4-embedded IPv6 Topology 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].
Before making appropriate configuration in order to generate a 3. Provisioning
separate OSPFv3 routing table for IPv4-embedded IPv6 addresses and
prefixes, decision must be made on the set of routers and their
interfaces in the IPv6 transit network that should be on the IPv4-
embedded IPv6 topology.
For the purpose of this topology, all AFXLBRs that connect to IPv4 3.1. Deciding the IPv4-embedded IPv6 Topology
client networks must be members of this topology, and also at least
some of their network core facing interfaces along with some P Before deploying configurations that use a separate OSPFv3 routing
routers in the IPv6 transit network would be on this topology. 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, and
also at least some of their network core facing interfaces along with
some P routers in the IPv6 network.
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) network, and if all routers (including AFXLBRs and P-routers) and all
and all their interfaces are included, the two topologies converge. their interfaces are included, the two topologies converge. In
In general, as more P routers and their interfaces are configured on 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 across the transit potentially, there would be more routing paths across the network
network from one IPv4 client network to the other, at the cost that from one IPv4 client network to the other, at the cost of more
more routers need to participate the IPv4-embedded IPv6 routing. In routers needing to participate in IPv4-embedded IPv6 routing. In any
any case, the IPv4-embedded IPv6 topology must be continuous with no case, the IPv4-embedded IPv6 topology MUST be continuous with no
partitions. partitions.
2.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table 3.2. Maintaining a Dedicated IPv4-embedded IPv6 Routing Table
In an IPv6 transit network, in order to maintain a separate IPv6 In an IPv6 network, in order to maintain a separate IPv6 routing
routing table that contains routes for IPv4-embedded IPv6 table that contains routes for IPv4-embedded IPv6 destinations only,
destinations only, OSPFv3 needs to use the mechanism defined either OSPFv3 needs to use the mechanism defined either in [RFC5838] or in
in [RFC5838] or in [I-D.ietf-ospf-mt-ospfv3] with required [I-D.ietf-ospf-mt-ospfv3] with the required configuration, as
configuration, as described in the following sub-sections. described in the following sub-sections.
2.3. OSPFv3 Topology with a Separate Instance ID 3.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 described in this document is under a
under a single ISP and as such, an OSPFv3 instance ID (IID) is single Autonomous System and, as such, an OSPFv3 instance ID (IID) is
allocated locally and used for an OSPFv3 operation dedicated to allocated locally and used for OSPFv3 operation dedicated to unicast
unicast IPv4-embedded IPv6 routing in an IPv6 transit network. This IPv4-embedded IPv6 routing in an IPv6 network. This IID is
IID is configured on each OSPFv3 interface of routers that configured on OSPFv3 router interfaces that participate in the IPv4-
participates in this routing instance. embedded IPv6 topology.
The range for a locally configured OSPFv3 IID is from 128 to 255, The range for a locally configured OSPFv3 IID is from 128 to 255,
inclusively, and this number must be used to encode the "Instance ID" inclusive, and this IID must be used to encode the "Instance ID"
field in the OSPFv3 packet header on every router that executes this field in the packet header of OSPFv3 packets associated with the
instance in the IPv6 transit network. 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 the Hello packets processing, adjacency may only be During Hello packet processing, an adjacency may only be established
established when received Hello packets contain the same Instance ID when the received Hello packet contains the same Instance ID as
as configured on the receiving interface for OSPFv3 instance configured on the receiving OSPFv3 interface. This insures that only
dedicated to the IPv4-embedded IPv6 routing. 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]. For more details, the reader is referred to [RFC5838].
2.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
transit network. This MTID is configured on each OSPFv3 interface of network. This MTID is configured on each OSPFv3 router interface
routers 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,
inclusively, and this number must be used to encode the "MT-ID" field inclusive, and this MT-ID must be used to encode the "MT-ID" field
that is included in some of the extended LSAs as documented in included in extended Link State Advertisements (LSAs) for the 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].
3. IP Packets Translation 4. IP Packets Translation
When transporting IPv4 packets across an IPv6 transit network with When transporting IPv4 packets across an IPv6 network with the
the mechanism described above, an IPv4 packet is translated to an mechanism described above, an IPv4 packet is translated to an IPv6
IPv6 packet at ingress AFXLBR, and the IPv6 packet is translated back packet at the ingress AFXLBR, and the IPv6 packet is translated back
to the original IPv4 packet at egress AFXLBR. The IP packet to an IPv4 packet at the egress AFXLBR. The IP packet translation is
translation is accomplished in stateless manner according to rules accomplished in stateless manner according to rules specified in
specified in [RFC6145], with the address translation detail explained [RFC6145], with the address translation detail explained in the next
in the next sub-section. sub-section.
3.1. Address Translation 4.1. Address Translation
Prior to the operation, an IPv6 prefix is allocated by the ISP and it Prior to address translation, an IPv6 prefix is allocated by the
is used to form IPv4-embedded IPv6 addresses. Autonomous System and it 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 the 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
and for the later case, the IPv6 prefix length may be 32, 40, 48, 56 Autonomous System; and for the later case, the IPv6 prefix length may
or 64. In either case, this IPv6 prefix is used during the address be 32, 40, 48, 56 or 64. In either case, this IPv6 prefix is used
translation between an IPv4 address and an IPv4-embedded IPv6 during the address translation between an IPv4 address and an IPv4-
address, which is performed according to [RFC6052]. 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.
4. Advertising IPv4-embedded IPv6 Routes 5. Advertising IPv4-embedded IPv6 Routes
In order to forward IPv4 packets to the proper destination across In order to forward IPv4 packets to the proper destination across an
IPv6 transit network, IPv4 reachability needs to be disseminated IPv6 network, IPv4 reachability needs to be disseminated throughout
throughout the IPv6 transit network and this work is performed by the IPv6 network and this is performed by AFXLBRs that connect to
AFXLBRs that connect to IPv4 client networks using OSPFv3. IPv4 client networks using OSPFv3.
With the scenario described in this document, i.e. - a set of AFXLBRs 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 that inter-connect a bunch of IPv4 client networks with an IPv6
transit network, we view that IPv4 networks and IPv6 networks belong network, the IPv4 networks and IPv6 networks can belong to the same
to separate Autonomous Systems, and as such, these AFXLBRs are OSPFv3 or independent Autonomous Systems, and as such, these AFXLBRs should
ASBRs. behave as either Area Border Routers (ABRs) or AS Boundary Routers
(ASBRs), respectively.
4.1. Advertising IPv4-embedded IPv6 Routes into IPv6 Transit Network 5.1. Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit
Network
In this case, the IPv4 networks and IPv6 networks belong to separate
Autonomous Systems, and as such, the AFXLBRs are OSPF AS Boundary
Routers (ASBRs).
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 IPv6 prefix allocated by the Autonomous System and the method
[RFC6052]. These routes are then advertised by one or more attached specified in [RFC6052]. These routes are then advertised by one or
ASBRs into the IPv6 transit network using AS External LSA [RFC5340], more attached ASBRs into the IPv6 transit network using AS-External-
i.e. - with the advertising scope throughout the entire Autonomous LSAs [RFC5340], i.e., with advertising scope comprising the entire
System. Autonomous System.
4.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 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 added to the metric of the intra-AS path to the ASBR during the
routes calculation. By configuration on an ASBR, the metric can be OSPFv3 route calculation. Through ASBR configuration, the metric can
set to a Type 2 external metric, which is considered much larger than be set to a Type 2 external metric, which is considered much larger
that on any intra-AS path. The detail is referred to OSPFv3 than the metric for any intra-AS path. Refer to the OSPFv3
specification [RFC5340]. In either case, an external metric may take specification [RFC5340] for more detail. In either case, an external
the same value as in an IPv4 network (running OSPFv2 or others), but metric may take the same value as in an IPv4 network (using OSPFv2 or
may also be specified based on some routing policy; the detail is another routing protocol), but may also be specified based on some
outside of the scope of this document. routing policy; the details of which are outside of the scope of this
document.
4.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 not to be used by setting the F that the "Forwarding Address" field is not used, so that the AFXLBR
bit in the associated OSPFv3 AS-external-LSA to zero, so that the can make the forwarding decision based on its own IPv4 routing table.
AFXLBR can make the forwarding decision based on its own IPv4 routing
table.
4.2. Advertising IPv4 Addresses into Client Networks 5.2. Advertising IPv4-embedded IPv6 Routes into an IPv6 Backbone
IPv4-embedded IPv6 routes injected into the IPv6 transit network from An alternate scenario is where the IPv4 and IPv6 networks belong to
one IPv4 client network may be advertised into another IPv4 client the same Autonomous System. The routing information would then be
carried as internal (inter-area) through the backbone, which allows
us to keep the OSPFv2 client networks unchanged: for example, the
configuration of a stub area doesn't have to change if we want it to
receive internal information. In other words, the AFXLBRs will act
as ABRs between OSPFv2 and OSPFv3 areas.
In this case, the IPv6 area MUST be the OSPFv3 backbone and the IPv4
client networks MUST NOT be the backbone area in the OSPFv2 domain,
or be connected to it.
All AFXLBRs MUST identify themselves as Area Border Routers.
5.2.1. Using Inter-Area-Prefix-LSAs
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 Autonomous System and the method
specified in [RFC6052]. These routes are then advertised by one or
more attached AFXLBRs into the IPv6 backbone using Inter-Area-Prefix-
LSAs. The process in [RFC5340] is modified so that the Inter-Area-
Prefix-LSAs are originated for prefixes contained in Intra-Area LSAs
(Type 1 and 2 [RFC2328]); prefixes originally contained in External-
LSAs SHOULD follow the process described in Section 5.1.
5.3. 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 network, after the associated destination addresses and prefixes are
translated back to IPv4 addresses and prefixes, respectively. This translated back to IPv4 addresses and prefixes, respectively. For
operation is similar to the regular OSPFv3 operation, wherein an AS AS-External-LSAs, this operation is similar to normal OSPFv3
External LSA can be advertised in a non-backbone area by default. operation, wherein an AS-External-LSA can be advertised in a non-
backbone area by default. For Inter-Area-Prefix-LSAs, this operation
is similar to the described in Section 5.2, wherein a Summary LSA is
originated by the AFXLBR if the prefix was included in an Inter-Area-
Prefix-LSA.
An IPv4 client network that does not want to receive such An IPv4 client network can limit which advertisements it receives
advertisement can be configured as a stub area or with other routing through configuration.
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 backbone/transit network.
5. Aggregation on IPv4 Addresses and Prefixes 6. Aggregation on IPv4 Addresses and Prefixes
In order to reduce the amount of AS External LSAs that are injected In order to reduce the amount of LSAs that are injected to the IPv6
to the IPv6 transit network, effort must be made to aggregate IPv4 network, an effort must be made to aggregate IPv4 addresses and
addresses and prefixes at each AFXLBR before advertising. prefixes at each AFXLBR prior to advertisement as IPv4-embedded IPv6
addresses and prefixes.
6. Forwarding 7. Forwarding
There are three cases in forwarding IP packets in the scenario as There are three cases in forwarding IP packets in the scenario
described in this document, as follows: 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 the destination IPv4 connecting to an IPv4 client network with a destination IPv4
address belong to another IPv4 client network, the header of the address belonging to another IPv4 client network, the header of
packet is translated to a corresponding IPv6 header as described the packet is translated to the corresponding IPv6 header as
in Section 3, and the packet is then forwarded to the destination described in Section 4, and the packet is then forwarded to the
AFXLBR that advertises the IPv4-embedded IPv6 address through the destination AFXLBR that advertised the IPv4-embedded IPv6 address
IPv6 transit network. into the IPv6 network.
2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the 2. On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the
embedded destination IPv4 address is in its IPv4 routing table, embedded destination IPv4 address is in its IPv4 routing table,
the header of the packet is translated to a corresponding IPv4 the header of the packet is translated to the corresponding IPv4
header as described in Section 3, and the packet is then header as described in Section 4, and the packet is then
forwarded accordingly. forwarded accordingly.
3. On any router that is within the IPv4-embedded IPv6 topology 3. On any router that is within the IPv4-embedded IPv6 topology
located in the IPv6 transit network, if an IPv4-embedded IPv6 subset of the IPv6 network, if an IPv4-embedded IPv6 packet is
packet is received and a route is found in the IPv4-embedded IPv6 received and a route is found in the IPv4-embedded IPv6 routing
routing table, the packet is forwarded accordingly. table, the packet is forwarded accordingly.
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].
7. MTU Issues 8. Backdoor Connections
In the IPv6 transit network, there is no new MTU issue introduced by In some deployments, IPv4 client networks are inter-connected across
this document. If a separate OSPFv3 instance (per [RFC5838]) is used the IPv6 network, but also directly connected to each other. The
for IPv4-embedded IPv6 routing, the MTU handling in the transit "backdoor" connections between IPv4 client networks can certainly be
network is the same as that of the default OSPFv3 instance. If a used to transport IPv4 packets between IPv4 client networks. In
separate OSPFv3 topology (according to [I-D.ietf-ospf-mt-ospfv3]) is general, backdoor connections are preferred over the IPv6 network,
used for IPv4-embedded IPv6 routing, the MTU handling in the transit since there requires no address family translation.
network is the same as that of the default OSPFv3 topology.
However, the MTU in the IPv6 transit network may be different than In the case of using Inter-Area-Prefix-LSAs, the backdoor connection
that of IPv4 client networks. Since an IPv6 router will never MUST NOT be the backbone area in the OSPFv2 domain.
fragment a packet, the packet size of any IPv4-embedded IPv6 packet
entering the IPv6 transit network must be equal to or less than the
MTU of the IPv6 transit network. In order to achieve this
requirement, it is recommended that AFXLBRs to perform IPv6 path
discovery among themselves and the resulting MTU, after taking into
account of the difference between IPv4 header length and IPv6 header
length, must be "propagated" into IPv4 client networks, e.g.-
included in the OSPFv2 Database Description packet.
The detail of passing the proper MTU into IPv4 client networks is 9. Prevention of Loops
beyond the scope of this document.
8. Backdoor Connections If a 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.
In some deployments, IPv4 client networks are inter-connected across 10. MTU Issues
the IPv6 transit network, but also directly connected to each other.
The "backdoor" connections between IPv4 client networks can certainly
be used to transport IPv4 packets between IPv4 client networks. In
general, backdoor connections are prefered over the transportation
over the IPv6 transit network, since there requires no address family
translation.
9. Security Considerations 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.
This document does not introduce any security issue than what has However, the MTU in the IPv6 network may be different than that of
been identified in [RFC5838] and [RFC6052]. 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.
10. IANA Considerations The details of passing the proper MTU into IPv4 client networks are
beyond the scope of this document.
No new IANA assignments are required for this document. 11. Security Considerations
11. Acknowledgements This document does not introduce any security issues other than those
identified in [RFC5838] and [RFC6052].
Many thanks to Acee Lindem, Dan Wing and Joel Halpern for their 12. IANA Considerations
comments.
12. References No new IANA assignments are required for this document.
12.1. Normative References 13. Acknowledgements
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF Many thanks to Acee Lindem, Dan Wing, Joel Halpern and Mike Shand for
for IPv6", RFC 5340, July 2008. their comments.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 14. References
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 14.1. Normative References
Algorithm", RFC 6145, April 2011.
12.2. Informative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.boucadair-softwire-dslite-v6only] [RFC4576] Rosen, E., Psenak, P., and P. Pillay-Esnault, "Using a
Boucadair, M., Jacquenet, C., Grimault, J., Kassi-Lahlou, Link State Advertisement (LSA) Options Bit to Prevent
M., Levis, P., Cheng, D., and Y. Lee, "Deploying Dual- Looping in BGP/MPLS IP Virtual Private Networks (VPNs)",
Stack Lite in IPv6 Network", RFC 4576, June 2006.
draft-boucadair-softwire-dslite-v6only-01 (work in
progress), April 2011. 14.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.
[RFC2328] Moy, J., "OSPF Version 2", STD 54, RFC 2328, April 1998.
[RFC5340] Coltun, R., Ferguson, D., Moy, J., and A. Lindem, "OSPF
for IPv6", RFC 5340, July 2008.
[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 5838, April 2010. RFC 5838, April 2010.
[RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X.
Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052,
October 2010.
[RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation
Algorithm", RFC 6145, April 2011.
Authors' Addresses Authors' Addresses
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
Hewlett-Packard Co.
2610 Wycliff Road
Raleigh, NC 27607
USA
Email: alvaro.retana@hp.com
 End of changes. 100 change blocks. 
269 lines changed or deleted 331 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/