One document matched: draft-ietf-ospf-ipv4-embedded-ipv6-routing-13.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-13"
ipr="trust200902" obsoletes="" updates="" submissionType="IETF" xml:lang="en">
<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>Santa Clara</city>
<region>California</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.com</email>
</address>
</author>
<author fullname="Alvaro Retana" initials="A." surname="Retana">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>7025 Kit Creek Rd.</street>
<!-- Reorder these if your country does things differently -->
<city>Research Triangle Park</city>
<region>North Carolina</region>
<code>27709</code>
<country>USA</country>
</postal>
<email>aretana@cisco.com</email>
<!-- uri and facsimile elements may also be added -->
</address>
</author>
<date month="May" year="2013" />
<abstract>
<t>This document describes a routing scenario where IPv4 packets are
transported over an IPv6 network, based on RFCs 6145 and 6052,
along with a separate OSPFv3 routing table for IPv4-embedded IPv6
routes in the IPv6 network.</t>
</abstract>
</front>
<middle>
<section title="Introduction" toc="default">
<t>This document describes a routing scenario where IPv4 packets are
transported over an IPv6 network, based on
<xref target="RFC6145" pageno="false" format="default"> </xref> and
<xref target="RFC6052" pageno="false" format="default"></xref>,
along with a separate OSPFv3 routing table for
IPv4-embedded IPv6 routes in the IPv6 network. This document does not
introduce any new IPv6 transition mechanism.</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" pageno="false" format="default"></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" pageno="false" format="default"></xref>) refers to an
edge router, which supports both IPv4 and IPv6 address families, but the backbone
network it connects to only supports either the 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 an IPv4-only network and an IPv6-only network, and is
capable of performing IP header translation between IPv4 and IPv6 according to
<xref target="RFC6145" pageno="false" format="default"></xref>.</t></list></t>
<t></t>
<section anchor="scenario" title="The Scenario" toc="default">
<t>Due to exhaustion of public IPv4 addresses, there has been
a continuing effort within the IETF on IPv6 transitional techniques. In the
course of the transition, it is certain that networks based on IPv4 and
IPv6 technologies respectively, will co-exist at least for
some time. One scenario of this co-existence is the inter-connection
of IPv4-only and IPv6-only networks, and in particular, when an IPv6-only
network serves as inter-connection between several segregated
IPv4-only networks. In this scenario, IPv4 packets
are transported over the IPv6 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 between the IPv4 networks by some mechanism.</t>
<t>In general, running an IPv6-only network would
reduce operational expenditure and optimize the operation compared to
IPv4-IPv6 dual-stack environment. Some
solutions have been proposed to allow delivery of IPv4 services over
an IPv6-only network. This document specifies an engineering
technique that separates the routing table dedicated to
IPv4-embedded IPv6 destinations from the routing table used
for native IPv6 destinations. </t>
<t>OSPFv3 is designed to support multiple instances
or multiple topologies. Maintaining a separate
routing table for IPv4-embedded IPv6 routes would
simplify the implementation, trouble shooting and
operation; it also prevents overload of the
native IPv6 routing tables. A separate routing table can be generated
from a separate routing instance or a separate routing topology.</t>
</section>
<section title="Routing Solution per RFC5565" toc="default">
<t>The aforementioned scenario is described in <xref target="RFC5565"
pageno="false" format="default"></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(rovider) Routers in the core only support
IPv6 but the AFBRs (Address Family Border Routers) support IPv4 on
interfaces facing IPv4 client networks, and IPv6 on interfaces facing
the core. The routing solution defined in <xref target="RFC5565" pageno="false"
format="default"></xref> for this scenario is to run i-BGP among AFBRs
to exchange IPv4 routing information in the core, 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" toc="default">
<t>In this document, we propose an alternative routing solution for
the scenario described in <xref target="scenario" pageno="false" format="default">
</xref>, where several segregated IPv4 networks, called IPv4 client networks, are
inter-connected by an IPv6 network. The IPv6 network
and the inter-connected IPv4 networks may or may not
belong to the same
Autonomous System. We refer to
the border node on the boundary of an IPv4 client network and the IPv6
network as an Address Family Translation Border Router (AFXLBR),
which supports both the IPv4 and IPv6 address families, and is
capable of translating an IPv4 packet to an IPv6 packet, and vice
versa, according to <xref target="RFC6145" pageno="false"
format="default"></xref>. The described scenario is illustrated in Figure 1.</t>
<t><figure anchor="fig1" height=""
title="Segregated IPv4 Networks Inter-connected by an IPv6 Network">
<artwork><![CDATA[
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| AFXLBR | | AFXLBR |
+--| IPv4/6 |---| IPv4/6 |--+
| +--------+ +--------+ |
+--------+ | | +--------+
| IPv6 | | | | IPv6 |
| Client |----| |----| Client |
| Network| | IPv6 | | Network|
+--------+ | only | +--------+
| |
| +--------+ +--------+ |
+--| AFXLBR |---| AFXLBR |--+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| \ / |
| \ / |
| \ / |
| X |
| / \ |
| / \ |
| / \ |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
]]></artwork>
</figure></t>
<t>Since the scenario occurs most commonly within an
organization, an IPv6
prefix can be locally allocated and used by AFXLBRs to construct IPv4-embedded
IPv6 addresses according to <xref target="RFC6052" pageno="false" format="default">
</xref>. The embedded IPv4 address or prefix belongs to an IPv4 client network
that is connected to the AFXLBR. An AFXLBR injects IPv4-embedded IPv6 addresses
and prefixes into the IPv6 network using OSPFv3, and it also installs
IPv4-embedded IPv6 routes advertised by other AFXLBRs. </t>
<t> When an AFXLBR receives an IPv4 packet from a locally connected
IPv4 client network and destined to a remote IPv4 client network, it
translates the IPv4 header to the relevant IPv6 header according to
<xref target="RFC6145" pageno="false" format="default"></xref>, and in that
process, source and destination IPv4 address are translated into IPv4-embedded
IPv6 addresses, respectively, according to <xref target="RFC6052" pageno="false"
format="default"></xref>. The resulting IPv6 packet is
then forwarded to the AFXLBR that connects to the destination IPv4 client
network. The remote AFXLBR derives the IPv4 source and destination addresses
from the IPv4-embedded IPv6 addresses, respectively, according to
<xref target="RFC6052" pageno="false" format="default"></xref>, and translates the
header of the received IPv6 packet to the relevant IPv4 header according
to <xref target="RFC6145" pageno="false" format="default"></xref>. The resulting
IPv4 packet is then forwarded
according to the IPv4 routing table maintained on the AFXLBR.</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, or i-BGP is
not used at all. Another case is when tunnels are not deployed in
the IPv6 network, or native IPv6 forwarding is preferred. Note
that with this routing solution, the IPv4 and IPv6 header translation
performed in both directions by the AFXLBR is stateless.</t>
</section>
<section title="OSPFv3 Routing with a Specific Topology" toc="default">
<t>In general, IPv4-embedded IPv6 packets can be forwarded just like
native IPv6 packets with OSPFv3 running in the IPv6 network.
However, this would require IPv4-embedded IPv6 routes to be flooded
throughout the entire IPv6 network and stored on every router. This
is not desirable from the scaling perspective. Moreover, since all IPv6
routes are stored in the same routing table, it would be inconvenient to manage
the resource required for routing and forwarding based on traffic category,
if so desired. </t>
<t>To improve the situation, a separate OSPFv3 routing table can be
constructed that is dedicated to the IPv4-embedded IPv6 topology, and
that table is solely used for routing IPv4-embedded IPv6 packets
in the IPv6 network. The IPv4-embedded IPv6 topology includes
all the participating AFXLBR routers and a set of
P Routers providing
redundant connectivity with alternate routing paths.</t>
<t>There are two methods to build a separate OSPFv3 routing table for
IPv4-embedded IPv6 routes: <list style="symbols"><t>The first one is to run a
separate OSPFv3 instance for IPv4-embedded IPv6 topology in the IPv6 network according
to <xref target="RFC5838" pageno="false" format="default"></xref>.</t>
<t>The second one is to stay with the existing OSPFv3 instance
that already operates in the IPv6 network, but maintain a separate
IPv4-embedded IPv6 topology, according to <xref target="I-D.ietf-ospf-mt-ospfv3"
pageno="false" format="default"></xref>.</t></list></t>
<t>With either method, there would be a dedicated IPv4-embedded IPv6
topology that is maintained on all participating AFXLBR and P Routers,
along with a dedicated IPv4-embedded IPv6 routing table. This routing
table is then used solely in the IPv6 network for IPv4-embedded
IPv6 packets.</t>
<t>It would be an operator's preference as which method
is to be used. This document elaborates on how configuration is
done for each method and related routing issues that are common to
both.</t>
<t>This document only focuses on unicast routing for IPv4-embedded
IPv6 packets using OSPFv3.</t>
</section>
</section>
<section title="Requirements Language" toc="default">
<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" pageno="false"
format="default"></xref>.</t>
</section>
<section title="Provisioning" toc="default">
<t></t>
<section anchor="TheTopo"
title="Deciding the IPv4-embedded IPv6 Topology" toc="default">
<t>Before deploying configurations that use a
separate OSPFv3 routing table for IPv4-embedded IPv6
addresses and prefixes, a decision must be made on the set of routers and
their interfaces in the IPv6 network that should be part of the
IPv4-embedded IPv6 topology.</t>
<t>For the purpose of this IPv4-embedded IPv6 topology, all AFXLBRs
that connect to IPv4 client networks MUST be members of this topology.
An AFXLBR MUST have at least one connection with a P Router in the
IPv6 network or another AFXLBR.</t>
<t>The IPv4-embedded IPv6 topology is a sub-topology of the entire
IPv6 network, and if all routers (including AFXLBRs and
P routers) and all their interfaces are included, the two topologies
converge. Generally speaking, when this sub-topology contains more
inter-connected P Routers, there would be more routing paths across the
IPv6 network from one IPv4 client network to the other; however, this
requires more routers in the IPv6 network to participate in
IPv4-embedded IPv6 routing. In any case, the IPv4-embedded IPv6 topology
MUST be continuous with no partitions.</t>
</section>
<section title="Maintaining a Dedicated IPv4-embedded IPv6 Routing Table" toc="default">
<t>In an IPv6 network, in order to maintain a separate IPv6
routing table that contains routes for IPv4-embedded IPv6 destinations
only, OSPFv3 needs to use the mechanism defined either in <xref target="RFC5838"
pageno="false" format="default"></xref> or in <xref target="I-D.ietf-ospf-mt-ospfv3"
pageno="false" format="default"></xref> with the required configuration,
as described in
<xref target="Instance" pageno="false" format="default"></xref> and
<xref target="MTopology" pageno="false" format="default"></xref>,
respectively.</t>
</section>
<section anchor="Instance"
title="OSPFv3 Topology with a Separate Instance ID" toc="default">
<t>It is assumed that the IPv6 network that is inter-connected
with IPv4 networks in this document is under one administration and as such, an OSPFv3 instance ID (IID) is
allocated locally and used for OSPFv3 operation dedicated to
unicast IPv4-embedded IPv6 routing in an IPv6 network. This
IID is configured on OSPFv3 router interfaces that
participate in the IPv4-embedded IPv6 topology.</t>
<t>The range for a locally configured OSPFv3 IID is
allocated from 192 to 255, inclusive, as "Private Use" per <xref target="I-D.ietf-ospf-ospfv3-iid-registry-update"
pageno="false" format="default"></xref>. This IID must be used to encode the
"Instance ID" field in the packet header of OSPFv3 packets associated
with the OSPFv3 instance.</t>
<t>In addition, the "AF" bit in the OSPFv3 Option field
MUST be set.</t>
<t>During Hello packet processing, an adjacency may only be
established when the received Hello packet contains the same Instance ID
as configured on the receiving OSPFv3 interface. This insures that
only interfaces configured as part of the OSPFv3 unicast IPv4-embedded
IPv6 topology are used for IPv4-embedded IPv6 unicast routing.</t>
<t>For more details, the reader is referred to <xref target="RFC5838" pageno="false"
format="default"></xref>.</t>
</section>
<section anchor="MTopology"
title="OSPFv3 Topology with the Default Instance" toc="default">
<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
network. This MT-ID is configured on each OSPFv3 router
interface that participates in this routing topology.</t>
<t>The range for a locally configured OSPFv3 MT-ID is from 32 to 255,
inclusive, and this MT-ID must be used to encode the
"MT-ID" field included in extended Link State Advertisements (LSAs)
for the IPv4-embedded IPv6 unicast topology as documented in
<xref target="I-D.ietf-ospf-mt-ospfv3" pageno="false" format="default"></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"
pageno="false" format="default"></xref>.</t>
</section>
</section>
<section anchor="translation" title="IP Packets Translation" toc="default">
<t>When transporting IPv4 packets across an IPv6 network with
the mechanism described above
(<xref target="Instance" pageno="false" format="default"></xref> and <xref target="MTopology" pageno="false" format="default"></xref>), an IPv4 packet is translated to an IPv6
packet at the ingress AFXLBR, and the IPv6 packet is translated back to an
IPv4 packet at the egress AFXLBR. The IP packet header translation is
accomplished in stateless manner according to rules specified in
<xref target="RFC6145" pageno="false" format="default"></xref>, with the
address translation details explained in the next sub-section.</t>
<section title="Address Translation" toc="default" anchor="AddrTran">
<t>Prior to address translation, an IPv6 prefix is allocated by the operator
and it is used to form IPv4-embedded IPv6 addresses.</t>
<t>The IPv6 prefix can either be the well-known IPv6 prefix (WKP)
64:ff9b::/96, or a network-specific prefix that is unique to the organzation;
and for the latter case, the IPv6 prefix length may be 32, 40, 48, 56
or 64. In either case, this IPv6 prefix is used during the address
translation between an IPv4 address and an IPv4-embedded IPv6 address,
as described in <xref target="RFC6052" pageno="false" format="default"></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>
<t>When a well-known IPv6 prefix (WKP) is used, [RFC6052] allows only
global IPv4 addresses to be embedded in the IPv6 address. An IPv6
address composed with a WKP and a non-global IPv4 address is hence
invalid, and packets that contain such address received by an AFXLBR
are dropped.</t>
<t>In the case where both the IPv4 client networks and the IPv6 transit
network belong to the same organization, non-global IPv4 addresses may be
used with a network-specific prefix [RFC6052].</t>
</section>
</section>
<section title="Advertising IPv4-embedded IPv6 Routes" toc="default">
<t>In order to forward IPv4 packets to the proper destination across
an IPv6 network, IPv4 reachability needs to be disseminated
throughout the IPv6 network and this is performed by
AFXLBRs that connect to IPv4 client networks using OSPFv3.</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
network, the IPv4 networks and IPv6 networks belong to the same or separate Autonomous Systems, and as such, these AFXLBRs behave as
AS Boundary Routers (ASBRs).</t>
<section title="Advertising IPv4-embedded IPv6 Routes through an IPv6 Transit Network"
toc="default" anchor="transit">
<t>IPv4 addresses and prefixes in an IPv4 client network are
translated into IPv4-embedded IPv6 addresses and prefixes,
respectively, using the IPv6 prefix allocated by the operator and the
method specified in <xref target="RFC6052" pageno="false" format="default"></xref>.
These routes are then advertised by one or more attached ASBRs into the IPv6
transit network using AS-External-LSAs <xref target="RFC5340" pageno="false"
format="default"></xref>,
i.e., with advertising scope comprising the entire Autonomous System.</t>
<section title="Routing Metrics" toc="default">
<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 comparable to the link state metric and we assume that in most
cases, OSPFv2 is used in client IPv4 networks. This metric is added to
the metric of the intra-AS path to the ASBR during
the OSPFv3 route calculation. Through ASBR configuration, the metric
can be set to a Type 2 external metric, which is considered much
larger than the metric for any intra-AS path. Refer to the
OSPFv3 specification <xref target="RFC5340" pageno="false" format="default">
</xref> for more detail. In either case,
an external metric may take the same value as in an IPv4 network
(using OSPFv2 or another routing protocol), but may also be specified
based on some routing policy; the details of which are outside of the
scope of this document.</t>
</section>
<section title="Forwarding Address" toc="default">
<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
destination address in an IPv4 client network. However, since an AFXLBR
sits on the border of an IPv4 network and an IPv6 network, it is
RECOMMENDED that the "Forwarding Address" field is not used, so that
the AFXLBR can make the forwarding decision based on its own IPv4
routing table.</t>
</section>
</section>
<section title="Advertising IPv4 Addresses into Client Networks" toc="default">
<t>IPv4-embedded IPv6 routes injected into the IPv6 network from one IPv4 client
network MAY be advertised into another IPv4 client network, after the associated
destination addresses and prefixes are translated back to IPv4 addresses and prefixes,
respectively. This operation is similar to normal OSPFv3
operation, wherein an AS-External-LSA can be advertised in a non-backbone area by
default.</t>
<t>An IPv4 client network can limit which advertisements it receives through
configuration.</t>
<t>For the purpose of this document, IPv4-embedded IPv6 routes MUST NOT be
advertised into any IPv6 client networks that also connected to the IPv6
transit network.</t>
</section>
</section>
<section anchor="Aggregation" title="Aggregation on IPv4 Addresses and Prefixes" toc="default">
<t>In order to reduce the amount of LSAs that are injected to the IPv6
network, an implementation should provide mechanisms to aggregate
IPv4 addresses and prefixes at AFXLBR prior to advertisement as
IPv4-embedded IPv6 addresses and prefixes. In general, the aggregation
practice should be based on routing policy, which is outside of the
scope of this document.</t>
</section>
<section title="Forwarding" toc="default">
<t>There are three cases in forwarding IP packets in the scenario
described in this document:<list style="numbers"><t>On an AFXLBR,
if an IPv4 packet that is received on an interface
connecting to an IPv4 segregated client network with a destination IPv4
address belonging to another IPv4 client network, the header of the
packet is translated to the corresponding IPv6 header as described in
<xref target="translation" pageno="false" format="default"></xref>,
and the packet is then forwarded to the destination AFXLBR that
advertised the IPv4-embedded IPv6
address into the IPv6 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
the corresponding IPv4 header as described in
<xref target="translation" pageno="false" format="default"></xref>,
and the packet is then forwarded accordingly.</t><t> On any router that
is within the IPv4-embedded IPv6 topology subset of the IPv6 network,
if an IPv4-embedded IPv6 packet is received and a route is found in the
IPv4-embedded IPv6 routing table, the packet is forwarded to the IPv6
next-hop just like the handling for a normal IPv6 packet, without any
translation.</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" pageno="false" format="default"></xref>.</t>
</section>
<section title="Backdoor Connections" toc="default">
<t>In some deployments, IPv4 client networks are inter-connected across
the IPv6 network, but also directly connected to each other. The
direct connections between IPv4 client networks, as sometimes called
"backdoor" connections, can certainly be used to transport IPv4
packets between IPv4 client networks. In general, backdoor connections
are preferred over the IPv6 network since there requires no address
family translation.</t>
</section>
<section title="Prevention of Loops" toc="default">
<t>If an LSA sent from an AFXLBR into a client network could then be received
by another AFXLBR, it would be possible for routing loops to occur. To prevent
loops, an AFXLBR MUST set the DN-bit <xref target="RFC4576" pageno="false"
format="default"></xref> 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.</t>
</section>
<section title="MTU Issues" toc="default">
<t>In the IPv6 network, there are no new MTU issues introduced by
this document. If a separate OSPFv3 instance (per <xref target="RFC5838"
pageno="false" format="default"></xref>) 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 <xref target=
"I-D.ietf-ospf-mt-ospfv3" pageno="false" format="default"></xref>)
is used for IPv4-embedded IPv6 routing, the MTU handling in the IPv6 network is
the same as that of the default OSPFv3 topology.</t>
<t>However, the MTU in the IPv6 network may be different than
that of IPv4 client networks. Since an IPv6 router will never fragment a
packet, the packet size of any IPv4-embedded IPv6 packet entering the
IPv6 network must be equal to or less than the MTU of the
IPv6 network. In order to achieve this requirement, it is
recommended that AFXLBRs perform IPv6 path discovery among themselves
and the resulting MTU, after taking into account of the difference
between the IPv4 header length and the IPv6 header length, must be
"propagated" into IPv4 client networks, e.g., included in
the OSPFv2 Database Description packet.</t>
<t>The details of passing the proper MTU into IPv4 client networks are
beyond the scope of this document.</t>
</section>
<section anchor="Security" title="Security Considerations" toc="default">
<t>There are several security aspects that require attention in the
deployment practice described in this document.</t>
<t>In the OSPFv3 transit network, the security considerations for OSPFv3
are handled as usual, and in particular, authentication
mechanisms described in <xref target="RFC6506" pageno="false" format="default"></xref> can be deployed.</t>
<t>When a separate OSPFv3 instance is used to support IPv4-embedded IPv6
routing, the same Security Association (SA) (refer to
<xref target="RFC4552" pageno="false" format="default"></xref> ) MUST be
used by the embedded IPv4 address instance as other instances utilizing
the same link as specified in
<xref target="RFC5838" pageno="false" format="default"></xref>.</t>
<t>Security considerations as documented in
<xref target="RFC6052" pageno="false" format="default"></xref> must also
be thought through with proper implementation
including the following:<list style="symbols">
<t>The IPv6 prefix that is used to carry an embedded IPv4 address
(refer to <xref target="AddrTran" pageno="false" format="default"></xref>)
must be configured by the authorized operator on
all participating AFXLBRs in a secure manner. This is to help prevent an
malicious attack resulting in network disruption, denial of service, and
possible information disclosure.</t>
<t>Effective mechanisms (such as reverse path checking) must be implemented
in the IPv6 transit network (including AFXLIBR nodes) to prevent spoofing
on embedded IPv4 addresses, which, otherwise, might be used as source
addresses of malicious packets.</t>
<t>If firewalls are used in IPv4 and/or IPv6 networks, the configuration
on the routers must be consistent so there are no holes in the IPv4 address
filtering.</t></list></t>
<t>The details of security handling are beyond the scope of this document.</t>
</section>
<section title="Operational Considerations" toc="default">
<t>This document put together some mechanisms based on existing technologies developed by IETF as an integrated solution to transport IPv4 packets over an IPv6 network using a separate OSPFv3 routing table. There are several aspects that require attention for the deployment and operation.</t>
<t>The tunnel-based solution documented in
<xref target="RFC5565" pageno="false" format="default"></xref>
and the solution proposed in this document are both used for transporting IPv4 packets over an IPv6 network, with different mechanisms. The two methods are not related to each other, and they can co-exist in the same network if so deployed, without any conflict. </t>
<t> If one approach is to be deployed, it is the operator's
decision for the choice. Note that each approach has its own
characteristics and requirements. E.g., the tunnel-based
solution requries a mesh of inter-AFBR softwires (tunnels)
spanning the IPv6 network, as well as iBGP to exchange routes
between AFBRs
(<xref target="RFC5565" pageno="false" format="default"></xref>); the approach in this document requires
AFXLBR capable of perfoming IPv4-IPv6 packet header translation
per <xref target="RFC6145" pageno="false" format="default"></xref>.</t>
<t>To deploy the solution as documented here, there requires some configurations. An IPv6 prefix must first be chosen that is used to form all the IPv4-embedded IPv6 addresses and prefixes advertised by AFXLBR in the IPv6 network; the detail is referred to <xref target="AddrTran" pageno="false" format="default"></xref>.
If the IPv4-embedded IPv6 routing table is created by using a separate OSPFv3 instance in the IPv6 network, configuration is accomplished according to
<xref target="RFC5838" pageno="false" format="default"></xref>,
as described in
<xref target="Instance" pageno="false" format="default"></xref>,
and if the default OSPFv3 instance is used instead, configuration is accomplished according to
<xref target="I-D.ietf-ospf-mt-ospfv3"
pageno="false" format="default"></xref>,
as described in <xref target="MTopology" pageno="false" format="default"></xref>.</t>
<t>
Note this document does not change any behavior of OSPFv3, and the existing or common practice should apply, in the context of
scalability. For example, the amount of routes that are
advertised by OSPFv3 is one key concern.
With the solution as described in this document, IPv4-embedded IPv6 addresses and prefixes will be injected by AFXLBR into some part of the IPv6 network (see
<xref target="TheTopo" pageno="false" format="default"></xref>
for details), and a separate routing table will be used for IPv4-embedded IPv6 routing. Care must be taken during the network design, such that 1) aggregation are performed on IPv4 addresses and prefixes before being advertised in the IPv6 network as described in
<xref target="Aggregation" pageno="false" format="default"></xref>,
and 2) estimates are made as the amount of IPv4-embedded IPv6 routes that would be disseminated in the IPv6 network, and the size of the separate OSPFv3 routing table.</t>
</section>
<section anchor="IANA" title="IANA Considerations" toc="default">
<t>No new IANA assignments are required for this document.</t>
</section>
<section title="Acknowledgements" toc="default">
<t>Many thanks to Acee Lindem, Dan Wing, Joel Halpern,
Mike Shand and Brian Carpenter for their comments.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include='reference.RFC.2119'?>
<?rfc include='reference.RFC.4576'?>
<?rfc include='reference.RFC.5565'?>
<?rfc include='reference.RFC.5838'?>
<?rfc include='reference.RFC.6145'?>
<?rfc include='reference.I-D.ietf-ospf-ospfv3-iid-registry-update'?>
</references>
<references title="Informative References">
<?rfc include='reference.RFC.6052'?>
<?rfc include='reference.RFC.5340'?>
<?rfc include='reference.RFC.6506'?>
<?rfc include='reference.RFC.4552'?>
<?rfc include='reference.I-D.ietf-ospf-mt-ospfv3'?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-24 03:15:01 |