Network Working Group Y. Cui
Internet-Draft P. Wu
Intended status: Standards Track S. Wang
Expires: January 7, 2010 M. Xu
J. Wu
X. Li
Tsinghua University
L. Zhang
UCLA
C. Metz
Cisco Systems, Inc.
July 6, 2009
VA-Based Softwire
draft-cui-softwire-va-based-softwire-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. This document may contain material
from IETF Documents or IETF Contributions published or made publicly
available before November 10, 2008. The person(s) controlling the
copyright in some of this material may not have granted the IETF
Trust the right to allow modifications of such material outside the
IETF Standards Process. Without obtaining an adequate license from
the person(s) controlling the copyright in such materials, this
document may not be modified outside the IETF Standards Process, and
derivative works of it may not be created outside the IETF Standards
Process, except to format it for publication as an RFC or to
translate it into languages other than English.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
Cui, et al. Expires January 7, 2010 [Page 1]
Internet-Draft VA-Based Softwire July 2009
This Internet-Draft will expire on January 7, 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Cui, et al. Expires January 7, 2010 [Page 2]
Internet-Draft VA-Based Softwire July 2009
Abstract
The increasing deployment of IPv6 networks in both customer networks
and ISP networks leads to two common traversing transition scenarios:
in the first scenario, an IPv6-only backbone network needs to provide
IP connectivity between IPv4 networks, we call it IPv4-over-IPv6
scenario; In the second scenario, IPv6 networks need to be
interconnected over an IPv4 transit network, we call it IPv6-over-
IPv4 scenario. In both scenarios, the ISP operating the transit
network of one address family must offer transit services for
attached client networks of the other address family. The Softwire
WG has defined softwire mesh mechanism [RFC5565] for the two
traversing scenarios. Softwire mesh uses automatic softwire tunnels
employing multi-protocol BGP extensions for distributing E-IP routes,
where both BGP peers and tunnels between PEs forms a full-mesh
architecture.
Inspired by the Virtual Aggregation approach [I-D.ietf-grow-va] to
IPv4 routing scalability, in this draft we proposed a scalable
mechanism for distributing E-IP routes over the transit network. Our
solution can significantly reduce the forwarding information base
(FIB) size at Address Family Border Routers (AFBRs) as well as the
total amount of routing updates, and offers the ISP an easy way to
manage the transit service.
Cui, et al. Expires January 7, 2010 [Page 3]
Internet-Draft VA-Based Softwire July 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. VA-based softwire framework . . . . . . . . . . . . . . . . . 8
3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Downlink routing . . . . . . . . . . . . . . . . . . . . . 9
3.3. Uplink routing . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Tunneled forwarding . . . . . . . . . . . . . . . . . . . 10
4. Discussion on Design Details . . . . . . . . . . . . . . . . . 12
4.1. BGP-based routing scheme . . . . . . . . . . . . . . . . . 12
4.2. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Cooperate with softwire mesh . . . . . . . . . . . . . . . 13
5. Benefits of VA-based softwire . . . . . . . . . . . . . . . . 14
6. Relation with VA . . . . . . . . . . . . . . . . . . . . . . . 15
7. Inter-domain consideration . . . . . . . . . . . . . . . . . . 16
8. Security considerations . . . . . . . . . . . . . . . . . . . 17
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
10.1. Normative References . . . . . . . . . . . . . . . . . . . 19
10.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Cui, et al. Expires January 7, 2010 [Page 4]
Internet-Draft VA-Based Softwire July 2009
1. Introduction
Recently more and more IPv6 networks have be deployed in both
customer networks and transit networks, while the existing IPv4
networks still carry the major network traffic and host most network
services and applications. It is commonly believed that IPv4 and
IPv6 networks will co-exist for the foreseeable future. There has
been basically two aspects of IPv6 transition research: connection
between IPv4 and IPv6 nodes and connection between networks of one
address family traversing network of the other address family. Basic
solution for the former one is address translation and for the latter
one is tunneling.
For traversing transition, softwire mesh provides a way that networks
of one address family can be connected through transit network of the
other address family. It's done by extending MP-BGP to exchange
external routing information between dual-stack Provider Edge routers
(PE), and using softwire tunnel to forward External-IP(E-IP) packets
through encapsulation and decapsulation. In both data plane and
control plane, all PEs form a full mesh.
Virtual Aggregation (VA) mechanism can reduce the FIB size of routers
by an order of magnitude. It can be deployed autonomously by an ISP,
and co-exist with legacy routers in the ISP. VA divides the IP
address space into Virtual Prefixes (VPs), and uses tunnels to
aggregate the regular sub-prefixes within each VP. For each sub-
prefix within a VP, Aggregation Point Routers (APRs) have a tunnel
from themselves to the remote ASBR (Autonomous System Border Router)
where packets for that prefix should be delivered. Because APRs may
not be on the shortest path between the ingress and egress routers,
the packets may take a longer path and experience additional latency.
However as shown in [I-D.ietf-grow-va], a proper placement of ARPs
can make the path length and network load increase negligible.
Furthermore, VA can make majority of data packet avoid traversing the
APR by installing the routes for popular prefixes in all routers. In
other words, popular prefixes will not be aggregated. Packets to
those prefixes are tunneled directly to the BGP NEXT_HOP.
This draft proposes an approach that adopts the basic idea from VA to
solve the traversing transition problem, called VA-based softwire.
In control plane, it organizes the E-IP address space into VPs and
aggregates the E-IP routes from the client network; regular E-IP
prefixes are collected by APRs in Internal-IP(I-IP) backbone, while
PEs only have to maintain VPs in the FIB. In data plane, VA-based
softwire uses APRs in backbone network to be intermediate tunneling
forwarders between PEs; E-IP packets are tunneled to APRs from client
network, and then tunneled to the destination client network.
Cui, et al. Expires January 7, 2010 [Page 5]
Internet-Draft VA-Based Softwire July 2009
VA-based softwire can significantly reduce the transition FIB size of
PEs, and the total amount of transition routing activity (routing
protocol process in transition-related routers and transition-related
routing packets delivered), and provide the ISP of backbone networks
with a better way to manage the transit service. This mechanism has
good scalability and works well when the number of client networks
increases.
Cui, et al. Expires January 7, 2010 [Page 6]
Internet-Draft VA-Based Softwire July 2009
2. Terminology
I-IP: according to [RFC5565], the term "I-IP"("Internal IP") refers
to the form of IP (i.e., either IPv4 or IPv6) that is supported by
the transit backbone network. The P routers support only I-IP.
E-IP: the term "E-IP" ("External IP") refers to the form of IP that
is supported by the client networks. In the scenarios of interest,
E-IP is IPv4 if and only if I-IP is IPv6, and E-IP is IPv6 if and
only if I-IP is IPv4.
Aggregation Point Router (APR): This draft adopts the name of APR
from VA in [I-D.ietf-grow-va]. An Aggregation Point Router (APR) is
a router that aggregates a Virtual Prefix (VP) by installing routes
(into the FIB) for all of the sub-prefixes within the VP. Every APR
can hold several VPs and the corresponding sub-prefixes for every VP.
In this draft, all VPs and sub-prefixes are E-IP prefixes and APR can
be deployed in arbitrarily position in I-IP backbone; for each sub-
prefix within the VP, APRs have a tunnel to the client network where
E-IP packets can reach their destinations.
Provider Edge router (PE): The dual-stack edge routers of the
backbone network, where E-IP packets enter and leave the backbone.
PE is often referred to as AFBR (Address Family Border Router).
Interior nodes of the backbone are often known as "P routers".
Popular Prefix: This draft adopts the name of popular prefix from VA.
In VA, a popular prefix is a sub-prefix that is installed in a router
in addition to the sub-prefixes it holds by virtue of being an
Aggregation Point Router. The popular prefix allows packets to
follow the shortest path. In VA-based softwire, a popular prefix is
an E-IP prefix installed in a PE router in addition to VPs. E-IP
packets whose destination falls within popular prefix can traverse
I-IP backbone in softwire mesh tunnels.
Virtual Prefix (VP): This draft adopts the name of VP from VA. A
Virtual Prefix is a prefix used to aggregate its contained regular
prefixes (sub-prefixes). A VP is not physically aggregatable, and it
is aggregated at APRs through the use of tunnels.
Cui, et al. Expires January 7, 2010 [Page 7]
Internet-Draft VA-Based Softwire July 2009
3. VA-based softwire framework
3.1. Scenario
The scenario of VA-based softwire is illustrated in figure1. A
number of P routers compose an I-IP-only backbone, in which a few
APRs are deployed. The PE routers are dual-stack and connected to
E-IP client networks. Every PE builds tunnels with every APR. The
I-IP backbone acts as a transit core to transport E-IP packets across
the I-IP backbone. This enables each of E-IP client network to
communicate with each other via two hop tunnels.
If E-IP is IPv6 and I-IP is IPv4, the scenario is IPv6-over-IPv4;
else E-IP is IPv4 and I-IP is IPv6, then the scenario is IPv4-over-
IPv6.
+--------+ +--------+
| E-IP | | E-IP |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| |
| |
+----------+ +----------+
|Dual-Stack| |Dual-Stack|
+--| PE |-| PE |--+
| +----------+ +----------+ |
| : : : : |
| : : : |
| : : : : | I-IP
| [APR] [APR] | backbone
| : : : : |
| : : : |
| : : : : |
| +----------+ +----------+ |
+--|Dual-Stack|-|Dual-Stack|--+
| PE | | PE |
+----------+ +----------+
| |
+--------+ +--------+
| E-IP | | E-IP |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1 VA-based Softwire Scenario
In the described scenario, VA-based softwire provides connectivity
Cui, et al. Expires January 7, 2010 [Page 8]
Internet-Draft VA-Based Softwire July 2009
for E-IP client network in three steps: downlink routing, uplink
routing and tunneled forwarding.
3.2. Downlink routing
In downlink routing, every selected APR must distribute its VP
information to every PE. VP can be configured in advance in every
APR, that is, Every APR is configured with which VPs it is
responsible for. Then ARP must advertise its VPs to all PEs, using
some intra-domain routing protocol.
In VA it is said that initial VPs can be statically configured in
every VA router as VP-list, and a VP can be added by some APR
originating routes for it and advertising these routes, also a VP can
be deleted by first removing it from the VP-Lists of non-APRs,
waiting for them to install sub-prefixes and then remove it from the
APRs. This draft, however, uses the uniform routing method that
initial VPs and all VP changes are first configured in APRs and then
advertised to all PEs for automaticity and simplicity. How to
process this routing behavior is still a concern, since E-IP routes
need to be advertised in or through I-IP network. We'll discuss this
in section 4.1.
Here we give an example of downlink routing. Suppose the backbone is
IPv6 and contains 2 APRs, APR1 is responsible for VP 0.0.0.0/1 and VP
128.0.0.0/2 while APR2 is responsible for VP 192.0.0.0/2. IPv4
client networks attached to the backbone through 2 PEs, PE1 is
attached with network 10.0.0.0/16 and 192.2.0.0/16 while PE2 is
attached with network 144.0.0.0/8. Then in this step, APR1
advertises the VPs of 0.0.0.0/1 and 128.0.0.0/2 to both PE1 and PE2,
APR2 advertises the VP 192.0.0.0/2 to PE1 and PE2.
After this step, every PE has all the VPs in its FIB table so it
knows which APR to forward an E-IP packet to, even there is no
regular prefix match for the destination.
3.3. Uplink routing
This step is opposite to downlink routing. In this step, every PE
must advertise the prefixes of the E-IP client network behind it to
corresponding APRs.
We use the example in section3.2 again to illustrate uplink routing.
In this example, PE1 must advertise 10.0.0.0/16 to APR1 and
192.2.0.0/16 to APR2, since sub-prefix 10.0.0.0/16 falls within VP
0.0.0.0/1 and 192.2.0.0/16 falls within 192.0.0.0/2; PE2 must
advertise 144.0.0.0/8 to APR1,since 144.0.0.0/8 falls within VP
128.0.0.0/2.
Cui, et al. Expires January 7, 2010 [Page 9]
Internet-Draft VA-Based Softwire July 2009
After this step, every APR has all the sub-prefix that is from the
E-IP client networks and falls within one of the VPs the APR is
responsible for. Therefore, every APR knows which PE to forward an
E-IP packet that is received from another PE earlier to.
3.4. Tunneled forwarding
In VA-based softwire, forwarding an E-IP packet through the I-IP
backbone includes the following steps: the ingress PE encapsulates
the incoming E-IP packet with the I-IP tunnel header; transmits the
encapsulated packet through the I-IP backbone to an APR; the APR
decapsulates the packet and encapsulates the packet with another I-IP
tunnel header; transmits the encapsulated packet through the backbone
to the egress PE; the egress PE decapsulates the I-IP header and
forwards the original E-IP packet. All the encapsulations and
decapsulations are performed on PEs and APRs, other routers in I-IP
backbone take encapsulated packets just as native I-IP packets. The
forwarding procedure is illustrated in figure2.
Tunnel1 Tunnel2
-----------> ----------->
I-IP Transit Core
+-+ E-IP +--+ +---+ +--+ E-IP +-+
|S|--->---|PE|======>=====|APR|======>=====|PE|--->---|D|
+-+ +--+ +---+ +--+ +-+
Original Ingress PE APR Egress PE Original
Source Decapsulation& Destination
Node Encapsulation Encapsulation Decapsulation Node
Figure 2 VA-based softwire: tunneled forwarding
When an ingress PE receives an E-IP packet from client network, it
looks up the destination IP address of the packet. In this case, the
best match for that address will be a VP route whose next hop is an
APR. The ingress PE must forward the packet through a tunnel to the
APR. This is done by encapsulating the packet, using an I-IP-
encapsulating header with the destination address of the APR, and
then forwarding the packet to I-IP network.
When the APR receives the encapsulated I-IP packet, it extracts the
payload, i.e., the original E-IP packet, and looks up the packet's
destination address. In this case, the best match for that address
will be a regular E-IP route whose next hop is a PE (the egress PE).
The APR will encapsulate the packet again, this time with the
destination I-IP address of the egress PE, and then forward the
packet to I-IP network again.
When the egress PE receives the encapsulated I-IP packet, it extracts
Cui, et al. Expires January 7, 2010 [Page 10]
Internet-Draft VA-Based Softwire July 2009
the payload, gets the original E-IP packet and forwards it further by
looking up its IP destination address in E-IP FIB.
Cui, et al. Expires January 7, 2010 [Page 11]
Internet-Draft VA-Based Softwire July 2009
4. Discussion on Design Details
4.1. BGP-based routing scheme
One approach is to use BGP to propagate E-IP routing informaiton
downlink and uplink. Every APR sets up and maintains an iBGP session
with every PE. We assume that these iBGP sessions are statically
configured at APRs and PEs.
In downlink direction, VPs will be advertised through BGP process,
from every APR to every PE. Note here the prefix is of E-IP format
and next hop is of I-IP format. For IPv4-over-IPv6 scenario,
[RFC5549] has made an extension of MP-BGP, modifying MP_REACH_NLRI
format to convey IPv4 NLRI prefix information with an IPv6 next hop
address, we can just use this v4nlri-v6nh extension here. As for
IPv6-over-IPv4 scenario, [RFC4798] provides a way that IPv6 routing
information can be distributed in IPv4 BGP by egress PE associating
MPLS labels with IPv6 prefixes; besides, we believe that the
extension of MP-BGP by [RFC5549] can also be used in IPv6-over-IPv4
scenario to advertised IPv6 NLRI with IPv4 next hop through IPv4 BGP.
BGP process in APRs and PEs need to be modified to fit the possible
extensions.
In uplink direction, BGP routing is similar to downlink routing,
except this time every PE advertise the prefixes of the E-IP client
network behind it to corresponding APRs. In this part, because only
the APRs whose VPs the E-IP prefixes fall within need to receive the
routes, ideally we can build BGP peers only between such APRs and
PEs. However, we've already built BGP peers between every APR and
every PE in downlink routing, so we can just add some filters in
every APR in order to only accept what it actually needs, that is,
the E-IP prefixes fall within its VPs.
4.2. Tunnel
In VA, a variety of tunnel types can be used: MPLS LSPs, IP-in-IP,
GRE, L2TP, and so on. VA-based softwire doesn't restrict tunnel
types, either. Actually since remote ASBR information for VA isn't
needed in VA-based softwire, standard softwire tunnel can be used in
the scenario. Note that signaling is needed for some types of
tunnels using BGP. Refer to [RFC5565] and [RFC5512] for details.
Note that encapsulation and decapsulation can be implemented by
hardware, so it won't become a heavy burden for APRs and PEs'
forwarding process.
Cui, et al. Expires January 7, 2010 [Page 12]
Internet-Draft VA-Based Softwire July 2009
4.3. Cooperate with softwire mesh
VA-base softwire can cooperate well with softwire mesh, just similar
to popular prefix can be used in VA besides VPs. Since the two
mechanisms both influent data forwarding by inject entries to PE's
FIB, there will be no confliction between them. Actually, if both
mechanisms are used, entries of softwire mesh will have higher
priority because VPs' masks are usually shorter than regular
prefixes. Here we also call the prefixes of softwire mesh entries
popular prefixes.
For some common, heavy-traffic softwire connections, PEs can choose
to follow popular prefixes, so only one time encapsulation and
decapsulation is needed and encapsulated packets can follow the
shortest path in I-IP backbone; for other softwire connections, PEs
can refer to VA-based softwire so the FIB size won't be large and PEs
won't have to build a lot of BGP peers and tunnels with other PEs.
Cui, et al. Expires January 7, 2010 [Page 13]
Internet-Draft VA-Based Softwire July 2009
5. Benefits of VA-based softwire
There are mainly three benefits using VA-based softwire in traversing
transition. The first one is that it can significantly reduce the
FIB size of the PEs. Every PE only needs to store the E-IP VPs of
all APRs, while the whole E-IP regular sub-prefixes are distributed
in the APRs' FIBs. PE can also keep a few regular prefixes for
softwire mesh use, to reach better performance. So VA-based softwire
achieves better scalability than pure softwire mesh.
Secondly, it can reduce the total amount of transition-related
routing activity. In this mechanism routing is executed between
every APR and every PE. Since there are only a few APRs in the
domain, the total amount of routing activity is in proportion to the
number of PEs. However, in softwire mesh, every two PEs form a BGP
peer, so the amount of routing activity is in proportion to the
square of the number of PEs. It's obvious that we can carry out less
routing activity than softwire simply implementing uplink and
downlink routing in BGP.
Moreover, VA-based softwire can provide the ISP of E-IP networks with
a better way to manage the IPv4-over-IPv6 or IPv6-over-IPv4
traversing service. In this mechanism, E-IP routes are collected in
APRs, maintained by the ISP. PEs don't know the detailed routes:
they just learn a few VPs for forwarding E-IP packets. If a new
client network wants to jump in and get connected with other E-IP
networks, the ISP just needs to tell the access PE the addresses of
the APRs. It's more transparent than softwire mesh where PE needs to
know the addresses of all other PEs, and fewer configurations are
needed.
Cui, et al. Expires January 7, 2010 [Page 14]
Internet-Draft VA-Based Softwire July 2009
6. Relation with VA
This draft adopts the aggregated, centralized architecture, and the
basic idea of VP aggregating sub-prefixes from VA. Both the two
mechanisms achieve their goals using virtual aggregation, with a
slight path length and router load increase. Both the two mechanisms
require minor changes to most routers.
However, our proposal is actually quite different from VA. First of
all, the problem we are trying to solve is different. VA solves the
intra-domain FIB size problem using VP and tunnels; every VA router
in the domain will benefit from VA with a FIB suppression. Our draft
is mainly aimed to propose an IPv6 transition mechanism with a new
architecture instead of solving the FIB problem of the routers in the
backbone. Second, the sphere of influence of the two mechanisms is
different. VA can be deployed for every router in the domain, and
all the intra-domain flows in that domain will be redirected by VA.
VA-based softwire won't influent the I-IP domain except for the
changes in APRs and PEs, and the traffic injected from client
network. The native routing and forwarding process in the I-IP
domain will work just the same as the situation without VA-based
softwire. In fact, all related routing and tunneled forwarding
process are implemented in APRs and PEs; other routers in the domain
won't even notice the change. Third, the FIB size problems solved by
the two mechanisms are different. VA reduces the size of global FIB
for every router in the domain. VA-based softwire reduces only the
E-IP FIBs of PEs, which is in proportion to the number of client
networks.
Cui, et al. Expires January 7, 2010 [Page 15]
Internet-Draft VA-Based Softwire July 2009
7. Inter-domain consideration
The situation will be different if two E-IP networks from two I-IP
domains which run VA-based softwire want to get connected. In this
inter-domain scenario, APRs in one ISP don't have the regular
prefixes of the E-IP network behind the other ISP, though it may fall
within its VPs. So if a PE receives an E-IP packet whose destination
is in the other ISP, it will still encapsulate and send the packet to
the APR whose VP matches the destination in its own ISP; After the
corresponding APR receive and decapsulate the packet, it has to drop
the packet since there is no regular prefix match in its E-IP FIB
table for the destination. So apparently APRs need to learn E-IP
routes of the other ISP.
The scenario is illustrated in figure3. Detailed design will be our
further work.
I-IP domain1 I-IP domain2
+---------------------------+ +---------------------------+
| [ EBGP ROUTER ]=======|=====|=======[ EBGP ROUTER ] |
| : : | | : : |
| : : | | : : |
| [APR] [APR] | | [APR] [APR] |
| : : : : | | : : : : |
| : : : | | : : : |
| : : : : | | : : : : |
| +----------+ +----------+ | | +----------+ +----------+ |
+-|Dual-Stack|-|Dual-Stack|-+ +-|Dual-Stack|-|Dual-Stack|-+
| PE | | PE | | PE | | PE |
+----------+ +----------+ +----------+ +----------+
| | | |
| | | |
+--------+ +--------+ +--------+ +--------+
| E-IP | | E-IP | | E-IP | | E-IP |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
Figure 3 inter-domain scenario
Cui, et al. Expires January 7, 2010 [Page 16]
Internet-Draft VA-Based Softwire July 2009
8. Security considerations
Since our mechanism is based on VA, we refer to [I-D.ietf-grow-va]
for security concerns. Our mechanism doesn't introduce security
problems other than the ones of VA's.
If VA is configured properly, or we say if all APRs and PEs are
configured properly, then any new concerns for intra-domain security
appear to be relatively minor. In particular, DoS attack to APR
won't significantly worsen the DoS problem, and VA won't limit the
deployment of DoS defense systems.
As to the situation of Mis-configured VA, VA introduces the
possibility that a VP is advertised outside of an AS. Usually a VP
is large(i.e. larger than any real prefixes), and the impact is
minimal. Smaller prefixes will be preferred because of best-match
semantics, and so the only impact is that packets that otherwise have
no matching routes will be sent to the misbehaving AS and dropped
there. If the VP is small, then it may cause a traffic hijack which
can happen with or without VA, so VA doesn't introduce a new security
problem.
Cui, et al. Expires January 7, 2010 [Page 17]
Internet-Draft VA-Based Softwire July 2009
9. Acknowledgements
This draft gets the very original idea from VA, and extends the idea
to solve a different problem: IPv4-over-IPv6 transiton. The authors
would like to thank P.Francis, X.Xu, H.Ballani, D. Jen, R. Raszuk, L.
Zhang and everyone else who contributed to VA.
Cui, et al. Expires January 7, 2010 [Page 18]
Internet-Draft VA-Based Softwire July 2009
10. References
10.1. Normative References
[RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur,
"Connecting IPv6 Islands over IPv4 MPLS Using IPv6
Provider Edge Routers (6PE)", RFC 4798, February 2007.
[RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation
Subsequent Address Family Identifier (SAFI) and the BGP
Tunnel Encapsulation Attribute", RFC 5512, April 2009.
[RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network
Layer Reachability Information with an IPv6 Next Hop",
RFC 5549, May 2009.
[RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", RFC 5565, June 2009.
10.2. Informative References
[I-D.ietf-grow-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-ietf-grow-va-00 (work in progress), May 2009.
Cui, et al. Expires January 7, 2010 [Page 19]
Internet-Draft VA-Based Softwire July 2009
Authors' Addresses
Yong Cui
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: cy@csnet1.cs.tsinghua.edu.cn
Peng Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: weapon@csnet1.cs.tsinghua.edu.cn
Shengling Wang
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: slwang@csnet1.cs.tsinghua.edu.cn
Mingwei Xu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5822
Email: xmw@csnet1.cs.tsinghua.edu.cn
Cui, et al. Expires January 7, 2010 [Page 20]
Internet-Draft VA-Based Softwire July 2009
Jianping Wu
Tsinghua University
Department of Computer Science, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: jianping@cernet.edu.cn
Xing Li
Tsinghua University
Department of Electronic Engineering, Tsinghua University
Beijing 100084
P.R.China
Phone: +86-10-6278-5983
Email: xing@cernet.edu.cn
Lixia Zhang
UCLA
Email: lixia@cs.ucla.edu
Chris Metz
Cisco Systems, Inc.
3700 Cisco Way
San Jose, Ca. 95134
USA
Email: chmetz@cisco.com
Cui, et al. Expires January 7, 2010 [Page 21]