One document matched: draft-wu-softwire-4over6-03.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!-- edited by Yong Cui, Tsinghua University -->
<!-- modified by Chris Metz, Yuntao Zhou, Yong Cui, ... -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="no"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<rfc category="exp" docName="draft-wu-softwire-4over6-03" ipr="trust200902">
<front>
<title abbrev="4over6">4over6 Transit Solution using IP
Encapsulation and MP-BGP Extensions</title>
<author fullname="Jianping Wu" initials="J.P" surname="Wu">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5983</phone>
<email>jianping@cernet.edu.cn</email>
</address>
</author>
<author fullname="Yong Cui" initials="Y" surname="Cui">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>cy@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Xing Li" initials="X" surname="Li">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Electronic Engineering, Tsinghua
University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5983</phone>
<email>xing@cernet.edu.cn</email>
</address>
</author>
<author fullname="Mingwei Xu" initials="M.W" surname="Xu">
<organization>Tsinghua University</organization>
<address>
<postal>
<street>Department of Computer Science, Tsinghua University</street>
<city>Beijing</city>
<code>100084</code>
<country>P.R.China</country>
</postal>
<phone>+86-10-6278-5822</phone>
<email>xmw@csnet1.cs.tsinghua.edu.cn</email>
</address>
</author>
<author fullname="Chris Metz" initials="C" surname="Metz">
<organization>Cisco Systems, Inc.</organization>
<address>
<postal>
<street>3700 Cisco Way</street>
<city>San Jose, Ca.</city>
<code>95134</code>
<country>USA</country>
</postal>
<email>chmetz@cisco.com</email>
</address>
</author>
<date year="2009" />
<abstract> <t>The emerging and growing deployment of IPv6 networks will
introduce cases where connectivity with IPv4 networks crossing IPv6 transit
backbones is desired. This document describes a mechanism for automatic
discovery and creation of IPv4 over IPv6 tunnels via extensions to multi-
protocol BGP. It is targeted at connecting islands of IPv4 networks across
an IPv6-only backbone without the need for a manually configured overlay of
tunnels. The mechanisms described in this document have been implemented,
tested and deployed on the large research IPv6 network in China. </t>
</abstract> </front>
<middle>
<section title="Introduction">
<t>Due to the lack of IPv4 address space, more and more IPv6 networks
have been deployed not only on edge networks, but also on backbone networks.
However, there are still a large number of legacy IPv4 hosts and applications.
As a result, IPv6 networks and IPv4 applications/hosts will have to coexist
for a long period of time.</t>
<t>The emerging and growing deployment of IPv6 networks will introduce
cases where connectivity with IPv4 networks is desired. Some IPv6
backbones will need to offer transit services to attached IPv4 access
networks. The method to achieve this would be to encapsulate and then
transport the IPv4 payloads inside IPv6 tunnels spanning the backbone.
There are some IPv6/IPv4-related tunneling protocols and mechanisms
defined in the literature. But at the time that the mechanism described in
this document was introduced, most of these existing techniques focus on
the problem of IPv6 over IPv4, rather than the case of IPv4 over IPv6.
Encapsulation methods alone, such as that defined in <xref
target="RFC2473"></xref>, require manual configuration in order to
operate. When a large number of tunnels are necessary, manual
configuration can become burdensome. To the above problem, this document
describes an approach, referred to as "4over6".</t>
<t>The 4over6 mechanism concerns two aspects: the control plane and the
data plane. The control plane needs to address the problem of how to
setup an IPv4 over IPv6 tunnel in an automatic and scalable fashion
between a large number of edge routers. This document defines extensions
to MP-BGP employed to communicate tunnel end-point information and
establish 4over6 tunnels between dual-stack Provider Edge (PE) routers
positioned at the edge of the IPv6 backbone network. Once the 4over6
tunnel is in place, the data plane focuses on the packet forwarding
processes of encapsulation and decapsulation.</t>
</section>
<section title="4over6 Framework Overview">
<t>In the topology shown in figure 1, a number of IPv6-only P routers
compose a native IPv6 backbone. The PE routers are dual-stack and
referred to as 4over6 PE routers. The IPv6 backbone acts as a transit
core to transport IPv4 packets across the IPv6 backbone. This enables
each of IPv4 access islands to communicate with each other via 4over6
tunnels spanning the IPv6 transit core.</t>
<figure>
<artwork><![CDATA[
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| |
| |
__+____________________+__
4over6 / : : : : \ IPv6 only
Tunnels | : : : : | transit core
between | : [P] : | with multiple
PEs | : : : : | [P routers]
| : : : : |
\_._._._._._._._._._._._._./
| / \ |
| |
Dual-Stack Dual-Stack
"4over6 PE" "4over6 PE"
| | |
_._._._._ _._._._._
| IPv4 | | IPv4 |
| access | | access |
| island | | island |
_._._._._ _._._._._
]]></artwork>
<postamble>Figure 1: IPv4 over IPv6 network topology</postamble>
</figure>
<t></t>
<t>As shown in figure 1, there are multiple dual-stack PE routers
connected to the IPv6 transit core. In order for the ingress 4over6 PE
router to forward an IPv4 packet across the IPv6 backbone to the correct
egress 4over6 PE router, the ingress 4over6 PE router must learn which
IPv4 destination prefixes are reachable through each egress 4over6 PE
router. MP-BGP will be extended to distribute the destination IPv4 prefix
information between peering dual-stack PE routers. Section 4 of this
document presents the definition of the 4over6 protocol field in MP-BGP
and section 5 describes MP-BGP's extended behavior in support of this
capability.</t>
<t>After the ingress 4over6 PE router learns the correct egress 4over6 PE
router via MP-BGP, it will forward the packet across the IPv6 backbone
using IP encapsulation. The egress 4over6 PE router will receive the
encapsulated packet, remove the IPv6 header and then forward the original
IPv4 packet to its final IPv4 destination. Section 6 describes the
procedure of packet forwarding.</t> </section>
<section title="Prototype Implementation">
<t>An implementatoin of the 4over6 mechanisms described in this document
was developed, tested and deployed on Linux with kernel version 2.4. The
prototype system is composed of three components: packet forwarding, the
encapsulation table and MP-BGP extensions. The packet forwarding and
encapsulation table are Linux kernel modules and the MP-BGP extension
was developed by extending Zebra routing software.</t>
<t>The following sections will discuss these parts in detail.</t>
<section title="4over6 Packet Forwarding">
<t>Forwarding an IPv4 packet through the IPv6 transit core includes 3
parts: encapsulation of the incoming IPv4 packet with the IPv6 tunnel
header; transmission of the encapsulated packet over the IPv6 transit
backbone; and decapsulation of the IPv6 header and forwarding of the
original IPv4 packet. Native IPv6 routing and forwarding are employed in
the backbone network since the P routers take the 4over6 tunneled
packets as just native IPv6 packets. Therefore, 4over6 packet forwarding
involves only the encapsulation process and the decapsulation process,
both of which are peformed on the 4over6 PE routers.</t>
<figure>
<artwork><![CDATA[
Tunnel from Ingress PE to Egress PE
---------------------------->
Tunnel Tunnel
Entry-Point Exit-Point
Node Node
+-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+
|S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D|
+-+ +--+ +--+ +-+
Original Ingress PE Egress PE Original
Packet (Encapsulation) (Decapsulation) Packet
Source Destination
Node Node
]]></artwork>
<postamble>Figure 2: Packet forwarding along 4over6 Tunnel</postamble>
</figure>
<t>As shown in Figure 2, packet encapsulation and decapsulaion are both
on the dual-stack 4over6 PE routers. Figure 3 shows the format of packet
encapsulation and decapsulation.</t>
<figure>
<artwork><![CDATA[
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
|
|(Encapsulation on ingress PE)
|
v
< Tunnel IPv6 Headers > < Original IPv4 Packet >
+-----------+ - - - - - +-------------+-----------//--------------+
| IPv6 | IPv6 | IPv4 | |
| | Extension | | Packet Payload |
| Header | Headers | Header | |
+-----------+ - - - - - +-------------+-----------//--------------+
< Tunnel IPv6 Packet >
|
|(Decapsulation on egress PE)
|
v
+----------------------------------//-----+
| IPv4 Header | Packet Payload |
+----------------------------------//-----+
< Original IPv4 Packet >
]]></artwork>
<postamble>Figure 3: Packet encapsulation and decapsulation on
dual-stack 4over6 PE router</postamble>
</figure>
</section>
<t>The encapsulation format to apply is IPv4 encapsulated in IPv6 as
outlined in <xref target="RFC2473"></xref>.</t>
<t></t>
<section title="Encapsulation table">
<t>Each 4over6 PE router maintains an encapsulation table as depicted
in Figure 4. Each entry in the encapsulation table consists of an IPv4
prefix and its corresponding IPv6 address. The IPv4 prefix is a particular network
located in an IPv4 access island network. The IPv6 address is the
4over6 virtual interface (VIF) address of the 4over6 PE router that
the IPv4 prefix is reachable through. The encapsulation table is built
and maintained using local configuration information and MP-BGP
advertisements received from remote 4over6 PE routers.</t>
<t>The 4over6 VIF is an IPv6 /128 address that is locally configured
on each 4over6 router. This address, as an ordinary global IPv6 address,
must also be injected into the
IPv6 IGP so that it is reachable across the IPv6 backbone.</t>
<figure>
<artwork><![CDATA[
+-------------+------------------------+
| IPv4 Prefix | IPv6 Advertising AFBR |
+-------------+------------------------+
]]></artwork>
<postamble>Figure 4: Encapsulation Table</postamble>
</figure>
<t></t>
<t>When an IPv4 packet arrives at the ingress 4over6 PE router, a
lookup in the local IPv4 routing table will result in a pointer to the
local encapsulation table entry with the matching destination IPv4
prefix. There is a corresponding IPv6 address in the encapsulation table.
The IPv4 packet is encapsulated in an IPv6 header. The source
address in the IPv6 header is the IPv6 VIF address of the local 4over6 PE
router and the destination address is the IPv6 VIF address of the remote
4over6 PE router contained in the local encapsulation table. The
packet is then subjected to normal IPv6 forwarding for transport
across the IPv6 backbone.</t>
<t>When the encapsulated packet arrives at the egress 4over6 PE
router, the IPv6 header is removed and the original IPv4 packet is forwarded to
the destination IPv4 network based on the outcome of the lookup in the
IPv4 routing table contained in the egress 4over6 PE router.</t>
</section>
<section title="MP-BGP 4over6 Protocol Extensions">
<t>Each 4over6 PE router possesses an IPv4 interface connected to an
IPv4 access network(s). It can peer with other IPv4 routers using IGP
or BGP routing protocols to exchange local IPv4 routing information.
Routing information can also be installed on the 4over6 PE router
using static configuration methods.</t>
<t>Each 4over6 PE also possesses at least one IPv6 interface to
connect it into the IPv6 transit backbone. The 4over6 PE typically
uses IGP routing protocols to exchange IPv6 backbone routing
information with other IPv6 P routers. The 4over6 PE router will also
form an MP-iBGP peering relationship with other 4over6 PE routers
connected to the IPv6 backbone network.</t>
<t>The use of MP-iBGP suggests that the participating 4over6 PE
routers that share a route reflector or form a full mesh of TCP
connections are contained in the same autonomous system (AS). This
implementation is in fact only deployed over a single AS. This was not
an intentional design constraint but rather reflected the single AS
topology of the CNGI-CERNET2 national IPv6 backbone used in the
testing and deployment of this solution.</t>
<section title="Receiving Routing Information from Local CE">
<t>When a 4over6 PE router learns routing information from the
locally attached IPv4 access networks, the 4over6 MP-iBGP entity
should process the information as follows:</t>
<list style="numbers">
<t>Install and maintain local IPv4 routing information in the
IPv4 routing database.</t>
<t>Install and maintain new entries in encapsulation table. Each
entry should consist of the IPv4 prefix and the local IPv6 VIF
address.</t>
<t>Advertise the new contents of the local encapsulation table in the form of
MP_REACH_NLRI update information to remote 4over6 PE routers. The
format of these updates is as follows:</t>
<list style="symbols">
<t>AFI = 1 (IPv4)</t>
<t>SAFI = 67 (4OVER6)</t>
<t>NLRI = IPv4 network prefix</t>
<t>Network Address of Next Hop = IPv6 address of its 4over6 VIF</t>
</list>
<t>A new SAFI for this solution was obtained as SAFI_4OVER6 (67) from IANA.
We call BGP update with SAFI being 67 as 4over6 routing information.</t>
</list>
</section>
<section title="Receiving 4over6 Routing Information from a remote 4over6 PE">
<t>A local 4over6 PE router will receive MP_REACH_NLRI updates from
remote 4over6 routers and use that information to populate the local
encapsulation table and the BGP routing database. After validating
correctness of the received attribute, the following procedures are
used to update the local encapsulation table and redistribute to local
IPv4 routing table:</t>
<list style="numbers">
<t>Validate the received BGP update packet as 4over6 routing information
by AFI = 1 (IPv4) and SAFI = 67 (4OVER6)</t>
<t>Extract the IPv4 network address from the NLRI field and
install as the IPv4 network prefix</t>
<t>Extract the IPv6 address from the Network Address of the Next
Hop field and place that as an associated entry next to the IPv4
network index. (Note this describes the update of local encap
table.)</t>
<t>Install and maintain a new entry in encapsulation table with the
extracted IPv4 prefix and its corresponding IPv6 address.</t>
<t>Redistribute the new 4over6 routing information to local IPv4
routing table. Set the destination network prefix as the extracted
IPv4 prefix, set the Next Hop as Null, and Set the OUTPUT Interface
as the 4over6 VIF on the local 4over6 PE router.</t>
</list>
<t>Therefore, when an ingress 4over6 PE router receives an IPv4 packet,
the lookup in its IPv4 routing table will have a result of the output
interface as the local 4over6 VIF, where the incoming IPv4 packet will
be encapsulated with a new IPv6 header as indicated in the
encapsulation table.</t>
</section>
</section>
<!-- of BGP protocol extension -->
</section>
<!-- of prototype implementation -->
<section title="4over6 Deployment Experience ">
<section title="CNGI-CERNET2">
<t>A prototype of the 4over6 solution is implemented and deployed on
CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation
Internet (CNGI) backbones, operated by the China Education and
Research Network (CERNET). CNGI-CERNET2 connects approximately 25 core
nodes distributed in 20 cities in China at speeds of 2.5-10 Gb/s. The
CNGI-CERNET2 backbone is IPv6-only with some attached customer premise
networks (CPN) being dual-stack. The CNGI-CERNET2 backbone, attached
CNGI-CERNET2 CPNs, and CNGI-6IX Exchange all have globally unique AS
numbers. This IPv6 backbone is used to provide transit IPv4 services
for customer IPv4 networks connected via 4over6 PE routers to the
backbone.</t>
</section>
<section title="4over6 Testbed on the CNGI-CERNET2 IPv6 Network">
<t>Figure 5 shows 4over6 deployment network topology.</t>
<figure>
<artwork><![CDATA[
+-----------------------------------------------------+
| IPv6 (CERNET2) |
| |
+-----------------------------------------------------+
| | | |
Tsinghua|Univ. Peking|Univ. SJTU| Southeast|Univ.
+------+ +------+ +------+ +------+
|4over6| ... |4over6| |4over6| ... |4over6|
|router| |router| |router| |router|
+------+ +------+ +------+ +------+
| | | |
| | | |
| | | |
+-----------+ +-----------+ +-----------+ +-----------+
|IPv4 access| ... |IPv4 access| |IPv4 access| ... |IPv4 access|
| network | | network | | network | | network |
+-----------+ +-----------+ +-----------+ +-----------+
|
+----------------------+
| IPv4 (Internet) |
| |
+----------------------+
]]></artwork>
<postamble>Figure 5: 4over6 deployment network topology</postamble>
</figure>
<t>The IPv4-only access networks are equipped with servers and clients
running different applications. The 4over6 PE routers are deployed at
8 x IPv6 nodes of CNGI-CERNET2, located in 7 universities and 5 cities
across China. As suggested in figure 5 some of the IPv4 access
networks are connected to both IPv6 and IPv4 networks and others are
only connected to the IPv6 backbone. In the deployment, users in
different IPv4 networks can communicate with each other through 4over6
tunnels.</t>
</section>
<section title="Deployment Experiences">
<t>A number of 4over6 PE routers were deployed and configured to
support the 4over6 transit solution. MP-BGP peerings were established,
and successful distribution of 4over6 SAFI information occured.
Inspection of the BGP routing and encapsulation tables confirmed that
the correct entries were sent and received. ICMP ping traffic
indicated that IPv4 packets were successfully transiting the IPv6
backbone.</t>
<t>In addition other application protocols were successfully tested
per the following: </t>
<t><list style="symbols">
<t>HTTP. A client running Internet Explorer in one IPv4
client network was able to access and download multiple objects
from an HTTP server located in another IPv4 client network. </t>
<t>P2P. BitComet software running on several PCs placed in
different IPv4 client networks were able to find each other and
share files. </t>
</list>Other protocols, including FTP, SSH, IM(MSN, GTalk) and
Multimedia Streaming, all functioned correctly. </t>
<t> </t>
</section>
</section>
<section title="Relationship to Softwires Mesh Effort">
<t>The 4over6 solution was presented at the IETF Softwires Working Group
Interim meeting in Hong Kong in January 2006. The existence of this large-
scale implementation and deployment clearly showed that MP-BGP could be
employed to support tunnel setup in a scalable fashion across an IPv6
backbone. Perhaps most important was the use-case presented, that being an
IPv6 backbone offering transit to attached client IPv4 networks.</t>
<t>The 4over6 solution can be viewed as a precursor to softwires mesh
framework. However there are several differences with this solution and
the effort that emerged from the softwires working group called softwires
mesh framework <xref target="RFC5565"></xref>.</t>
<t><list style="symbols">
<t>MP-BGP Extensions. 4over6 employs a new SAFI (4OVER6) to convey
client IPv4 prefixes between 4over6 PE routers. Softwires Mesh retains
original AFI-SAFI designations but uses a modified MP_REACH_NLRI
format to convey IPv4 NLRI prefix information with an IPv6 next_hop
address <xref target="RFC5549"></xref>. </t>
<t>Encapsulation. 4over6 assumes IP-in-IP or it is possible to
configure GRE. Softwires uses those two scenarios configured locally
or for IP headers that require dynamic updating. As a result, the BGP
encap safi is introduced in Softwires
<xref target="RFC5512"></xref>.</t>
<t>Multicast. The basic 4over6 solution only implemented unicast
communications. The multicast communications is specified in the
Softwire Mesh Framework, and also supported by the multicast
extension of 4over6.</t>
<t>Use-Cases. The 4over6 solution in this document specifies the
4over6 use-case, which is also pretty easy to extend for the use-case
of 6over4. The softwires mesh framework supports both 4over6 and
6over4. </t>
</list></t>
</section>
<section title="IANA Considerations">
<t>A new SAFI value (67) was assigned by IANA for 4over6 BGP extension:
SAFI_4OVER6.</t>
</section>
<section title="Security Considerations">
<t>Tunneling mechanisms, especially automatic ones, often have potential
problems of DDoS attacks on the tunnel-entry point or tunnel-end point. As
the advantage, 4over6 BGP extension don't allocate resources to a single
flow or maintain the state for a flow. However, since the IPv6 tunnel
endpoints are globally reachable IPv6 addresses, it would be trivial to
spoof IPv4 packets by encapsulating and sending them over IPv6 to the
tunnel interface. This could bypass IPv4 RPF or other antispoofing
techniques. Also, any IPv4 filters may be bypassed.</t>
<t>I-BGP peering relationship may be maintained over IPSec or other secure
communications.</t>
<t></t>
</section>
<section title="Conclusion">
<t>The emerging and growing deployment of IPv6 networks, in particular
IPv6 backbone networks, will introduce cases where connectivity with
IPv4 networks is desired. Some IPv6 backbones will need to offer transit
services to attached IPv4 access networks. The 4over6 solution outlined
in this document supports such a capability through an extension to
MP-BGP to convey IPv4 routing information along with an associated IPv6
address. Basic IP encapsulation is used in the dataplane as IPv4 packets
are tunneled through the IPv6 backbone. </t>
<t>An actual implemention has been developed and deployed on the
CNGI-CERNET2 IPv6 backbone. </t>
</section>
<section title="Acknowledgements">
<t>During the design procedure of the 4over6 framework and definition of
BGP-MP 4over6 extension, Professor Ke Xu gave the authors many valuable
comments. The support of IETF softwire WG is also gratefully acknowledged
with special thanks to David Ward, Alain Durand and Mark Townsley for
their rich experience and knowledge in this field. Yakov Rekhter provided
helpful comments and advice. Mark Townsley reviewed this document
carefully and gave the authors a lot of valuable comments, which are very
important for improving this document.</t>
<t>The deployment and test for the prototype system was conducted among 7
universities -- namely, Tsinghua University, Peking University, Beijing
University of Post and Telecommunications, Shanghai Jiaotong University,
Huazhong University of Science and Technology, Southeast University, South
China University of Technology. The authors would like to thank everyone
involved in this effort in these universities.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2473" ?>
<?rfc include="reference.RFC.2784" ?>
<?rfc include="reference.RFC.2842" ?>
<?rfc include="reference.RFC.2858" ?>
<?rfc include="reference.RFC.4271" ?>
<?rfc include="reference.RFC.4364" ?>
<?rfc include="reference.RFC.4760" ?>
<?rfc include="reference.RFC.4925" ?>
<?rfc include="reference.RFC.5512" ?>
<?rfc include="reference.RFC.5549" ?>
<?rfc include="reference.RFC.5565" ?>
</references>
</back>
</rfc>| PAFTECH AB 2003-2026 | 2026-04-23 19:35:26 |