One document matched: draft-ietf-ospf-ipv4-embedded-ipv6-routing-00.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-ospf-ipv4-embedded-ipv6-routing-00"
ipr="trust200902">
<front>
<title abbrev="Routing for IPv4-embedded IPv6 Packets">Routing for
IPv4-embedded IPv6 Packets</title>
<author fullname="Dean Cheng" initials="D." surname="Cheng">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>2330 Central Expressway</street>
<city></city>
<region></region>
<code>95050</code>
<country>USA</country>
</postal>
<email>dean.cheng@huawei.com</email>
</address>
</author>
<author fullname="Mohamed Boucadair" initials="M." surname="Boucadair">
<organization>France Telecom</organization>
<address>
<postal>
<street></street>
<city>Rennes</city>
<region></region>
<code>35000</code>
<country>France</country>
</postal>
<email>mohamed.boucadair@orange-ftgroup.com</email>
</address>
</author>
<date day="13" month="April" year="2011" />
<abstract>
<t>This document describes routing packets destined to IPv4-embedded
IPv6 addresses across IPv6 transit core using OSPFv3 with a separate
routing table.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>This document describes a routing scenario where IPv4 packets are
transported over IPv6 network.</t>
<t>In this document the following terminology is used: <list
style="symbols">
<t>An IPv4-embedded IPv6 address denotes an IPv6 address which
contains an embedded 32-bit IPv4 address constructed according to
the rules defined in <xref target="RFC6052"></xref>. </t>
<t>IPv4-embedded IPv6 packets are packets of which destination
addresses are IPv4-embedded IPv6 addresses. </t>
<t>AFBR (Address Family Border Router, <xref
target="RFC5565"></xref>) refers to an edge router, which supports
both IPv4 and IPv6 address families, of a backbone that supports
only IPv4 or IPv6 address family. </t>
<t>AFXLBR (Address Family Translation Border Router) is defined in
this document. It refers to a border router that supports both IPv4
and IPv6 address families, located on the boundary of IPv4-only
network and IPv6-only network, and is capable of performing IP
header translation between IPv4 and IPv6 according to <xref
target="I-D.ietf-behave-v6v4-xlate"></xref>. </t>
</list></t>
<t></t>
<section anchor="scenario" title="The Scenario">
<t>Due to exhaustion of public IPv4 addresses, there has been
continuing effort within IETF on IPv6 transitional techniques. In the
course of transition, it is certain that networks based on IPv4 and
IPv6 transfer capabilities, respectively, will co-exist at least for
some time. One scenario of the co-existence is that IPv4-only networks
inter-connecting with IPv6-only networks, and in particular, when an
IPv6-only network serves as a transit network that inter-connects
several segregated IPv4-only networks. In this scenario, IPv4 packets
are transported over the IPv6 transit network between IPv4 networks.
In order to forward an IPv4 packet from a source IPv4 network to the
destination IPv4 network, IPv4 reachability information must be
exchanged among involved networks by dedicated means.</t>
<t>Unlike dual-stack networks, operating an IPv6-only network would
allow optimize OPEX and maintenance operations in particular. Some
solutions have been proposed to allow delivery of IPv4 services over
an IPv6-only network. This document focuses on an engineering
techniques which aims to separate the routing instance dedicated to
IPv4-embedded IPv6 destination from native IPv6 ones. </t>
<t>The purpose of running separate instances or topologies for
IPv4-embedded IPv6 traffic is to distinguish from the native IPv6
routing topology, and the topology that is used for routing
IPv4-embedded IPv6 datagram only. Separate instances/topologies are
also meant to prevent any overload of the native IPv6 routing tables
by IPv4-embedded IPv6 routes.</t>
</section>
<section title="Routing Solution per RFC5565">
<t>The aforementioned scenario is described in <xref
target="RFC5565"></xref>, i.e.- IPv4-over-IPv6 scenario, where the
network core is IPv6-only, and the inter-connected IPv4 networks are
called IPv4 client networks. The P routers in the core only support
IPv6 but the AFBRs (Address Family Border Routers) support IPv4 on
interface facing IPv4 client networks, and IPv6 on interface facing
the core. The routing solution defined in <xref
target="RFC5565"></xref> for this scenario is to run i-BGP among AFBRs
to exchange IPv4 routing information with each other, and the IPv4
packets are forwarded from one IPv4 client network to the other
through a softwire using tunneling technology such as MPLS LSP, GRE,
L2TPv3, etc.</t>
</section>
<section title="An Alternative Routing Solution with OSPFv3">
<t>In this document, we propose an alternative routing solution for
the scenario described in <xref target="scenario"></xref>, where
several segregated IPv4 networks, called IPv4 client networks, are
interconnected by an IPv6 transit network, and in particular, we name
the border node on the boundary of an IPv4 client network and the IPv6
transit network as Address Family Translation Border Router, or
AFXLBR, which supports both IPv4 and IPv6 address families, and is
capable of translating an IPv4 packet to an IPv6 packet, and vice
versa, according to <xref
target="I-D.ietf-behave-v6v4-xlate"></xref>.</t>
<t>Since the scenario occurs most in a single ISP operating
environment, an IPv6 prefix can be locally allocated and used to
construct IPv4-embedded IPv6 addresses according to <xref
target="RFC6052"></xref> by each AFXLBR, where the embedded IPv4
addresses are associated with an IPv4 client network that is connected
to the AFXLBR, and each IPv4 address is an individual IPv4 address or
prefix. An AFXLBR injects IPv4-embedded IPv6 addresses/prefixes into
the IPv6 transit network using OSPFv3 and also installs those
advertised by other AFXLBRs. When an IPv4 packet is sent from one IPv4
client network to the other, it is first encapsulated with an IPv6
header, where the source and destination IPv6 address are constructed,
in a stateless manner, as IPv4-embedded IPv6 address, respectively,
and then forwarded to the destination AFXLBR that is the advertising
router of the destination IPv4-embedded IPv6 address. The destination
AFXLBR replaces the IPv6 header by the corresponding IPv4 header,
where the source and destination IPv4 addresses are derived from the
IPv4-embedded IPv6 source and destination addresses, respectively, and
then forwards the IPv4 packet using its IPv4 routing table in the
attached IPv4 client network.</t>
<t>There are use cases where the proposed routing solution is useful.
One case is that some border nodes do not participate in i-BGP for
routes exchange (one example is documented in <xref
target="I-D.boucadair-softwire-dslite-v6only"></xref>), or i-BGP is
not used at all. Another case is that tunnel mechanism is not used in
the IPv6 transit network, or native IPv6 forwarding is preferred. Note
also that with this routing solution, the IPv4-IPv6 inter-connection
and associated header translation that occurs at an AFXLBR is
stateless.</t>
</section>
<section title="OSPFv3 Routing with a Specific Topology">
<t>Routing IPv4-embedded IPv6 packets in the IPv6 transit network
using OSPFv3, in general, may be performed by the OSPFv3 operation
that is already running in the IPv6 network. One concern however, is
that IPv4-embedded IPv6 routes would flood throughout the entire
transit network and stored on every router, which may not be
desirable. Also, since all IPv6 routes are stored in the same routing
table, it might be more difficult to manage the resource required for
routing and forwarding based on traffic category, if so desired. To
solve this problem and to ease the separation between native IPv6 and
IPv4-inferred routing policies, a separate OSPFv3 routing table can be
constructed that is dedicated to IPv4-embedded IPv6 topology, and that
table is solely used for routing IPv4-embedded IPv6 packets (i.e.,
IPv4 part of the Internet) in the transit network. Further, only a set
of routers in the transit network are required to be involved in such
routing scheme, including AFXLBRs that connect to IPv4 client networks
along with a set of P routers in the core for routing path.</t>
<t>There are two methods to build a separate OSPFv3 routing table for
IPv4-embedded IPv6 routing. <list style="symbols">
<t>The first one is to run a separate OSPFv3 instance for
IPv4-embedded IPv6 topology in the IPv6 transit network according
to <xref target="RFC5838"></xref>, </t>
<t>The second one is to stay with the existing OSPFv3 instance
that already operates in the transit network, but maintain a
separate IPv4-embedded topology, according to <xref
target="I-D.ietf-ospf-mt-ospfv3"></xref>. </t>
</list></t>
<t>With both methods, there would be a dedicated IPv4-embedded IPv6
topology that is maintained by OSPFv3 speakers and thus a dedicated
IPv4-embedded IPv6 routing table, which is then used for routing
IPv4-embedded IPv6 packets (i.e., packets destined to an IPv4
destination). It would be operators’ preference as which method
is going to be used. This document elaborates on how configuration is
done for each method and related routing issues that is common to
both.</t>
<t>This document only focuses on unicast routing for IPv4-embedded
IPv6 packets using OSPFv3.</t>
</section>
</section>
<section title="Provisioning">
<t></t>
<section title="Deciding the IPv4-embedded IPv6 Topology">
<t>Before making appropriate configuration in order to generate a
separate OSPFv3 routing table for IPv4-embedded IPv6
addresses/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. </t>
<t>For the purpose of this topology, all AFXLBRs that connect to IPv4
client networks should be members of this topology, and also at least
some of their network core facing interfaces, which depends on which P
routers in the IPv6 transit network would be on this topology.</t>
<t>The IPv4-embedded IPv6 topology is a sub-topology of the entire
IPv6 transit network, and if all routers (including AFXLBRs and
P-routers) and their interfaces are included, the two topologies
converge. In general, as more P routers and their interfaces are
configured on this sub-topology, it would increase the
inter-connectivity and potentially, there would be more routing paths
cross the transit network from one IPv4 client network to the other,
at the cost that more routers need to participate the IPv4-embedded
IPv6 routing. In any case, the IPv4-embedded IPv6 topology must be
continuous with no partitions.</t>
</section>
<section title="Maintaining a Dedicated IPv4-embedded IPv6 Routing Table">
<t>In an IPv6 transit network, in order to maintain a separate IPv6
routing table that contains routes for IPv4-embedded IPv6 destinations
only, OSPFv3 needs to use the mechanism defined either in <xref
target="RFC5838"></xref> or <xref
target="I-D.ietf-ospf-mt-ospfv3"></xref> with required configuration
tasks, as described in the following sub-sections.</t>
</section>
<section title="OSPFv3 Topology with a Separate Instance ID">
<t>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
allocated locally and used for an OSPFv3 operation dedicated to
unicast IPv4-embedded IPv6 routing in an IPv6 transit network. This
IID is configured on each OSPFv3 interface of routers that
participates in this routing instance. </t>
<t>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” field in the OSPFv3 packet header on every
router that executes this instance in the IPv6 transit network.</t>
<t>In addition, the “AF” bit in the OSPFv3 Option field
must be set.</t>
<t>During the Hello packets processing, adjacency may only be
established when received Hello packets contain the same Instance ID
as configured on the receiving interface for OSPFv3 instance dedicated
to the IPv4-embedded IPv6 routing.</t>
<t>For more details, the reader is referred to <xref
target="RFC5838"></xref>.</t>
</section>
<section title="OSPFv3 Topology with the Default Instance">
<t>Similar to that as described in the previous section, an OSPFv3
multi-topology ID (MT-ID) is locally allocated and used for an OSPFv3
operation including unicast IPv4-embedded IPv6 routing in an IPv6
transit network. This MTID is configured on each OSPFv3 interface of
routers that participates in this routing topology.</t>
<t>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 that is included in some of the extended
LSAs as documented in <xref
target="I-D.ietf-ospf-mt-ospfv3"></xref>.</t>
<t>In addition, the MT bit in the OSPFv3 Option field must be set.</t>
<t>For more details, the reader is referred to <xref
target="I-D.ietf-ospf-mt-ospfv3"></xref>.</t>
</section>
</section>
<section anchor="translation" title="IP Packets Translation">
<t>When transporting IPv4 packets across an IPv6 transit network with
the mechanism described above, an IPv4 packet is translated to an IPv6
packet at ingress AFXLBR, and the IPv6 packet is translated back to the
original IPv4 packet at egress AFXLBR. The IP packet translation is
accomplished in stateless manner according to rules specified in <xref
target="I-D.ietf-behave-v6v4-xlate"></xref>, with the address
translation detail explained in the next sub-section.</t>
<section title="Address Translation">
<t>Prior to the operation, an IPv6 prefix is allocated by the ISP and
it is used to form an IPv4-embedded IPv6 address.</t>
<t>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,
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
translation between an IPv4 address and an IPv4-embedded IPv6 address,
which is performed according to <xref target="RFC6052"></xref>.</t>
<t>During translation from an IPv4 header to an IPv6 header at an
ingress AFXLBR, the source IPv4 address and destination IPv4 address
are translated into the corresponding IPv6 source address and
destination IPv6 address, respectively, and during translation from an
IPv6 header to an IPv4 header at an egress AFXLBR, the source IPv6
address and destination IPv6 address are translated into the
corresponding IPv4 source address and destination IPv4 address,
respectively. Note that the address translation is accomplished in a
stateless manner.</t>
</section>
</section>
<section title="Advertising IPv4-embedded IPv6 Routes">
<t>In order to forward IPv4 packets to the proper destination across
IPv6 transit network, IPv4 reachability needs to be disseminated
throughout the IPv6 transit network and this work is performed by
AFXLBRs that connect to IPv4 client networks using OSPFv3.</t>
<t>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 transit
network, we view that IPv4 networks and IPv6 networks belong to separate
Autonomous Systems, and as such, these AFXLBRs are OSPFv3 ASBRs.</t>
<section title="Advertising IPv4-embedded IPv6 Routes into IPv6 Transit Network">
<t>IPv4 addresses and prefixes in an IPv4 client network are
translated into IPv4-embedded IPv6 addresses and prefixes,
respectively, using the same IPv6 prefix allocated by the ISP and the
method specified in <xref target="RFC6052"></xref>, and then
advertised by one or more attached ASBRs into the IPv6 transit network
using AS External LSA <xref target="RFC5340"></xref>, i.e. - with the
advertising scope throughout the entire Autonomous System.</t>
<section title="Routing Metrics">
<t>By default, the metric in an AS External LSA that carries an
IPv4-embedded IPv6 address or prefixes is a Type 1 external metric,
which is 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 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 specification <xref target="RFC5340"></xref>. In either case,
an external metric may be exact the same unit as in an IPv4 network
(running OSPFv2 or others), but may also be specified by a routing
policy, the detail is outside of the scope of this document.</t>
</section>
<section title="Forwarding Address">
<t>If the “Forwarding Address” field of an OSPFv3 AS
External LSA is used to carry an IPv6 address, that must also be an
IPv4-embedded IPv6 address where the embedded IPv4 address is the
actual address in an IPv4 client network to which, data traffic is
forwarded to. However, since an AFXLBR sits on 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 bit in the associated OSPFv3 AS-external-LSA to zero, so that the
AFXLBR can make the forwarding decision based on its own IPv4
routing table.</t>
</section>
</section>
<section title="Advertising IPv4 Addresses into Client Networks">
<t>IPv4-embedded IPv6 routes injected into the IPv6 transit network
from one IPv4 client network may be advertised into another IPv4
client network, after the associated destination addresses/prefixes
are translated back to IPv4 addresses/prefixes format. This operation
is similar to the regular OSPFv3 operation, wherein an AS External LSA
can be advertised in a non-backbone area by default.</t>
<t>An IPv4 client network that does not want to receive such
advertisement can be configured as a stub area or with other routing
policy. </t>
<t>For the purpose of this document, IPv4-embedded IPv6 routes must
not advertised into any IPv6 client networks that also connected to
the IPv6 transit network.</t>
</section>
</section>
<section title="Aggregation on IPv4 Addresses and Prefixes">
<t>In order to reduce the amount of AS External LSAs that are injected
to the IPv6 transit network, effort must be made to aggregate IPv4
addresses and prefixes at each AFXLBR before advertising.</t>
</section>
<section title="Forwarding">
<t>There are three cases in forwarding IP packets in the scenario as
described in this document, as follows:<list style="numbers">
<t>On an AFXLBR, if an IPv4 packet that is received on an interface
connecting to an IPv4 client network with the destination IPv4
address belong to another IPv4 client network, the header of the
packet is translated to a corresponding IPv6 header as described in
<xref target="translation"></xref>, and the packet is then forwarded
to the destination AFXLBR that advertises the IPv4-embedded IPv6
address through the IPv6 transit network.</t>
<t>On an AFXLBR, if an IPv4-embedded IPv6 packet is received and the
embedded destination IPv4 address is in its IPv4 routing table, the
header of the packet is translated to a corresponding IPv4 header as
described in Section 3, and the packet is then forwarded
accordingly.</t>
<t>On any router that is within the IPv4-embedded IPv6 topology
located in the IPv6 transit network, if an IPv4-embedded IPv6 packet
is received and a route is found in the IPv4-embedded IPv6 routing
table, the packet is forwarded accordingly.</t>
</list></t>
<t>The classification of IPv4-embedded IPv6 packet is according to the
IPv6 prefix of the destination address, which is either the Well Known
Prefix (i.e., 64:ff9b::/96) or locally allocated as defined in <xref
target="RFC6052"></xref>.</t>
</section>
<section title="MTU Issues">
<t>In the IPv6 transit network, there is no new MTU issue introduced by
this document. If a separate OSPFv3 instance (per <xref
target="RFC5838"></xref>) is used for IPv4-embedded IPv6 routing, the
MTU handling in the transit network is the same as that of the default
OSPFv3 instance. If a separate OSPFv3 topology (per <xref
target="I-D.ietf-ospf-mt-ospfv3"></xref>) is used for IPv4-embedded IPv6
routing, the MTU handling in the transit network is the same as that of
the default OSPFv3 topology.</t>
<t>However, the MTU in the IPv6 transit network may be different than
that of IPv4 client networks. Since an IPv6 router will never fragment a
packet, the packet size of any IPv4-embedded IPv6 packet entering the
IPv6 transit network must be equal to or smaller 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 OSPFv3 Database Description packet.</t>
<t>The detail of passing the proper MTU into IPv4 client networks is
beyond the scope of this document.</t>
</section>
<section title="Backdoor Connections">
<t>In some deployments, there may exist direct connections among IPv4
client networks themselves in addition to the IPv6 transit network, as
“backdoor” connections referring to, where IPv4 packets can
either be transported between those IPv4 client networks via backdoor
connections, or through the IPv6 transit network. In general, routing
policies should be as such that the “backdoor” path is
preferred since the packet forwarding is within a single address family
without the need for IP header translation, among other things.</t>
</section>
<section anchor="Security" title="Security Considerations">
<t>This document does not introduce any security issue than what has
been identified in <xref target="RFC5838"></xref>, <xref
target="I-D.ietf-ospf-mt-ospfv3"></xref> and <xref
target="RFC6052"></xref>.</t>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>No new IANA assignments are required for this document.</t>
</section>
<section title="Acknowledgements">
<t>Many thanks to Acee Lindem, Dan Wing and Joel Halpern for their
comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119"?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.5838'?>
<?rfc include='reference.I-D.ietf-ospf-mt-ospfv3'?>
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.I-D.ietf-behave-v6v4-xlate'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.5565'?>
<?rfc include='reference.I-D.boucadair-softwire-dslite-v6only'?>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 03:19:00 |