Network Working Group Y. Cui
Internet-Draft S. Wang
Intended status: Standards Track M. Xu
Expires: November 23, 2009 J. Wu
X. Li
Tsinghua University
May 22, 2009
VA-Based IPv6 Transition
draft-cui-softwire-va-based-transition-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.
This Internet-Draft will expire on November 23, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
Cui, et al. Expires November 23, 2009 [Page 1]
Internet-Draft VA-Based IPv6 Transition May 2009
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 November 23, 2009 [Page 2]
Internet-Draft VA-Based IPv6 Transition May 2009
Abstract
With the increasing deployment of IPv6 networks, IPv6 transition has
become one of the key problems in developing IPv6 networks. Among
various transition scenarios, one is common where connectivity
between IPv4 networks is desired across IPv6-only backbone network.
In such case, ISP operating the IPv6 backbone will accommodate
connectivity and offer transit services for attached IPv4 networks.
Softwire WG defined softwire mesh mechanism for both of the IPv4-
over-IPv6 scenario and the opposite scenario of IPv6-over-IPv4.
Softwire mesh uses automatic softwire tunnels employing multi-
protocol BGP extensions for distributing IPv4 routes, where BGP and
tunnuls should be configured or setup as a full-mesh architecture.
This draft, however, proposed an aggregated, centralized mechanism
similar to Virtual Aggregation (VA) mechanism, which can
significantly shrink the forwarding information base (FIB) size of
Address Family Border Routers (AFBRs), reduce the total amount of
routing activity, and provide the IPv6 ISP with an easy way to
manage the transit service.
Cui, et al. Expires November 23, 2009 [Page 3]
Internet-Draft VA-Based IPv6 Transition May 2009
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7
3. VA-Based Transition framework . . . . . . . . . . . . . . . . 8
3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.2. Downlink routing . . . . . . . . . . . . . . . . . . . . . 9
3.3. Uplink routing . . . . . . . . . . . . . . . . . . . . . . 9
3.4. Tunneled forwarding . . . . . . . . . . . . . . . . . . . 9
4. Design detail discussion . . . . . . . . . . . . . . . . . . . 11
4.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 11
4.1.1. BGP-based routing scheme . . . . . . . . . . . . . . . 11
4.1.2. OSPF & registration-based routing scheme . . . . . . . 11
4.2. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.3. Cooperate with softwire mesh . . . . . . . . . . . . . . . 12
4.4. Inter-domain situation . . . . . . . . . . . . . . . . . . 13
5. Benefits of VA-Based IPv6 Transition . . . . . . . . . . . . . 15
6. IPv6-over-IPv4 scenario . . . . . . . . . . . . . . . . . . . 16
7. Security considerations . . . . . . . . . . . . . . . . . . . 17
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
9.1. Normative References . . . . . . . . . . . . . . . . . . . 19
9.2. Informative References . . . . . . . . . . . . . . . . . . 19
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
Cui, et al. Expires November 23, 2009 [Page 4]
Internet-Draft VA-Based IPv6 Transition May 2009
1. Introduction
Recently more and more IPv6 networks have be deployed, especially
IPv6 backbone networks, while the existing IPv4 networks still carry
the major network traffic and hold the major network services and
applications, though facing serious address space problem and other
problems. It has been agreed that IPv4 and IPv6 networks will co-
exist for a long term. There's been basically two aspect 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 the traversing transition of IPv4-over-IPv6, softwire mesh
framework gives a way that IPv4 client networks can be connected
through IPv6 backbone. It's done by extending MP-BGP to exchange
IPv4 routes between dual-stack Provider Edge routers (PE), and using
softwire tunnel to forward IPv4 packets through encapsulation and
decapsulation. In both data plane and control plane, all PEs form a
full mesh.
Virtual Aggregation (VA) mechanism shrinks the FIBs of any and all
routers easily by an order of magnitude with negligible increase in
path length and load [I-D. draft-francis-intra-va]. 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. Since APRs may not be on the shortest path between the
ingress and egress routers, the packets may take a few more hops and
experience additional latency. VA can avoid traversing the APR for
selected routes by installing these routes in non-APR routers. In
other words, even if a router is not an APR for a given sub-prefix,
it may still install that sub prefix into its FIB. Packets in this
case are tunneled directly to the BGP NEXT_HOP.
This draft proposes an approach that learns the basic idea from VA to
solve the IPv4-over-IPv6 traversing problem, called VA-based IPv6
transition. In control plane, it organizes the IPv4 address space
into VPs and aggregates the IPv4 routes from the client network;
regular IPv4 prefixes are collected by APRs in IPv6 backbone, while
PEs only have to maintain VPs in the FIB. In data plane, VA-based
IPv6 transition uses APRs in IPv6 backbone to be intermediate
tunneling forwarders between PEs; IPv4 packets are tunneled to APRs
from IPv4 client network, and then tunneled to the destination IPv4
network.
Cui, et al. Expires November 23, 2009 [Page 5]
Internet-Draft VA-Based IPv6 Transition May 2009
VA-based IPv6 transition can significantly shrink the transition FIB
size of PEs, reduce the total amount of transition routing activity
(routing protocol process in transition-related routers and
transition-related routing packets delivered), and provide the IPv6
ISP with a better way to manage the IPv4-over-IPv6 transit service.
This mechanism has good scalability and works well when the number of
IPv4 client networks increases.
Cui, et al. Expires November 23, 2009 [Page 6]
Internet-Draft VA-Based IPv6 Transition May 2009
2. Terminology
Aggregation Point Router (APR): This draft adopts the name of APR
from 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. APRs advertise the VP to
other routers. In this draft, all VPs are IPv4 prefixes and APR is
deployed in IPv6 backbone; for each sub-prefix within the VP, APRs
have a tunnel to the IPv4 client network where IPv4 packets reach
their destinations.
Provider Edge router (PE): The dual-stack edge routers of the IPv6
backbone, where IPv4 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 IPv6 transition, a popular
prefix is an IPv4-prefix installed in a PE router in addition to VPs.
IPv4 packets whose destination falls within popular prefix can
traverse IPv6 backbone in softwire tunnels.
Virtual Prefix (VP): This draft adopts the name of VP from VA. A
Virtual Prefix (VP) is a prefix used to aggregate its contained
regular prefixes (sub-prefixes). A VP is not physically
aggregatable, and so it is aggregated at APRs through the use of
tunnels.
Cui, et al. Expires November 23, 2009 [Page 7]
Internet-Draft VA-Based IPv6 Transition May 2009
3. VA-Based Transition framework
3.1. Scenario
The scenario of VA-Based IPv6 Transition is illustrated in figure1.
A number of P routers compose an IPv6 only backbone, in which a few
APRs are deployed. The PE routers are dual-stack and connect IPv4
client networks. Every PE builds tunnels with every APR. The IPv6
backbone acts as a transit core to transport IPv4 packets across the
IPv6 backbone. This enables each of IPv4 client network to
communicate with each other via tunnels.
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
| |
| |
+--------+ +--------+
| PE | | PE |
+---| IPv4/6 |---| IPv4/6 |---+
| +--------+ +--------+ |
| : : : : |
| : : : |
| : : : : | IPv6
| [APR] [APR] | backbone
| : : : : |
| : : : |
| : : : : |
| +--------+ +--------+ |
+---| PE |---| PE |---+
| IPv4/6 | | IPv4/6 |
+--------+ +--------+
| |
| |
+--------+ +--------+
| IPv4 | | IPv4 |
| Client | | Client |
| Network| | Network|
+--------+ +--------+
Figure 1 VA-Based IPv6 Transition Scenario
In this scenario, VA-Based IPv6 Transition provides IPv4 connectivity
in three steps: downlink routing, uplink routing and tunneled
forwarding.
Cui, et al. Expires November 23, 2009 [Page 8]
Internet-Draft VA-Based IPv6 Transition May 2009
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 removing it from
the APRs. This draft, instead, 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 IPv4 routes
need to be advertised in or through IPv6 network. We'll discuss this
in section 4.1.
After this step, every PE has all the VPs in its FIB table so it
knows which APR to forward an IPv4 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 IPv4 client network behind it to
corresponding APRs. For example, if the IPv4 network behind PE1
contains two subsets, 192.168.1.0/24 and 10.0.0.0/16, and APR1 in
IPv6 backbone is responsible for VP 0.0.0.0/2 while APR2 is
responsible for VP 192.0.0.0/2, then PE1 must advertise
192.168.1.0/24 to APR2 and 10.0.0.0/16 to APR1, since sub-prefix
10.0.0.0/16 falls within VP 0.0.0.0/2 and 192.168.1.0/24 falls within
192.0.0.0/2.
After this step, every APR has all the sub-prefix that is from the
IPv4 client networks and falls within one of the VPs the APR is
responsible for. Therefore, every APR knows which PE to forward an
IPv4 packet received from another PE earlier to.
3.4. Tunneled forwarding
In VA-based transition, forwarding an IPv4 packet through the IPv6
backbone includes the following steps: the ingress PE encapsulates
the incoming IPv4 packet with the IPv6 tunnel header; transmits the
encapsulated packet through the IPv6 backbone to an APR; the APR
decapsulates the packet and encapsulates the packet with another IPv6
Cui, et al. Expires November 23, 2009 [Page 9]
Internet-Draft VA-Based IPv6 Transition May 2009
tunnel header; transmits the encapsulated packet through IPv6
backbone to the egress PE; the egress PE decapsulates the IPv6 header
and forwards the original IPv4 packet. All the encapsulations and
decapsulations are performed on PEs and APRs, other routers in IPv6
backbone take encapsulated packets just as native IPv6 packets. The
forwarding procedure is illustrated in figure2.
Tunnel1 Tunnel2
-----------> ----------->
IPv6 Transit Core
+-+ IPv4 +--+ +---+ +--+ IPv4 +-+
|S|--->---|PE|======>=====|APR|======>=====|PE|--->---|D|
+-+ +--+ +---+ +--+ +-+
Original Ingress PE APR Egress PE Original
Source Decapsulation& Destination
Node Encapsulation Encapsulation Decapsulation Node
Figure 2 VA-based transition: tunneled forwarding
When an ingress PE receives an IPv4 packet from IPv4 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 IPv6-
encapsulated header with the destination address of the APR, and then
forwarding the packet to IPv6 network.
When the APR receives the encapsulated IPv6 packet, it extracts the
payload, i.e., the original IPv4 packet, and looks up the packet's
destination address. In this case, the best match for that address
will be a regular IPv4 route whose next hop is a PE (the egress PE).
The APR will encapsulate the packet again, this time with the
destination IPv6 address of the egress PE, and then forward the
packet to IPv6 network again.
When the egress PE receives the encapsulated IPv6 packet, it extracts
the payload, gets the original IPv4 packet and forwards it further by
looking up its IP destination address.
Cui, et al. Expires November 23, 2009 [Page 10]
Internet-Draft VA-Based IPv6 Transition May 2009
4. Design detail discussion
4.1. Routing
4.1.1. BGP-based routing scheme
One way to achieve downlink and uplink routing is using BGP. For
routing exchange, Every APR must build an IPv6 IBGP peer with every
PE.
In downlink direction, VPs will be advertised through BGP process,
from every APR to every PE. Note here the prefix is IPv4 format and
next hop is IPv6 format. RFC5549 (Advertising IPv4 Network Layer
Reachability Information with an IPv6 Next Hop) has made an extension
of MP-BGP, modifying MP_REACH_NLRI format to convey IPv4 NLRI prefix
information with an IPv6 next hop address. So we can just use this
v4nlri-v6nh extension here. BGP process in APRs and PEs need to be
modified to fit the extension.
In uplink direction, BGP routing is similar to downlink routing,
except this time every PE advertise the prefixes of the IPv4 client
network behind it to corresponding APRs. In this part, because only
the APRs whose VPs the IPv4 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 so that it only accept what it actually needs, that is, the
IPv4 prefixes fall within its VPs.
Since BGP is run on end to end TCP connection, we won't introduce
IPv4 routes into IPv6 networks, but we do need a static configuration
for APRs and PEs.
4.1.2. OSPF & registration-based routing scheme
It's mentioned in section3.2 that VA can add a VP for every router by
originating route for it and advertising the route. Obviously it's
done through intra-domain routing. We can also achieve routing
exploiting intra-domain protocol.
For downlink routing, we can extend IPv6 OSPF to distribute IPv4 VPs.
What we need to do is to add a particular prefix for every VP to form
a 'fake' IPv6 prefix and modify the OSPF process in APRs and PEs, so
that APRs can generate routes with such 'fake' IPv6 prefixes while
PEs can recognize these routes and extract the IPv4 VPs to update
their FIBs. No change is required for other OSPF routers. Using
OSPF we'll introduce the IPv4 routes into IPv6 network, but since the
total number of VPs is small, it won't become a serious problem.
Cui, et al. Expires November 23, 2009 [Page 11]
Internet-Draft VA-Based IPv6 Transition May 2009
Meanwhile, since OSPF will flood these routes, all PE can learn VPs
atomically without configuration. Also, if the other routers can
cooperate by recognizing the fake prefixes as regular prefixes and
forward packets for those destinations, then they can participate in
the forwarding process from PEs to APRs and tunnel won't be actually
needed in this step.
Apparently uplink routing can't be executed by OSPF, or we'll pour a
lot of client IPv4 routes into the IPv6 backbone. However, since the
uplink routing activity is really simple, we can consider defining a
new, registration routing protocol to achieve it. The protocol is a
simple point to point, one hop routing protocol, and deployed in APRs
and PEs. On a PE, for every prefix change in its IPv4 FIB (all the
prefixes in initial case), send a routing message containing the
prefix to corresponding APR (PE can figure out which APR to send
message to by checking its FIB: the next hop for corresponding VP is
the right APR); On an APR, for every routing message received,
normally the prefix will fall into the APR's VP, so the APR updates
its IPv4 FIB. This procedure is similar to DNS registration, except
that DNS servers are hierarchical while APRs' architecture is flat.
Note here this protocol should be triggered when the downlink routes
or we say the VPs reaches PEs, since in this scheme we don't
configure the APRs for PEs in advance and let PEs learn the APR and
VP information through OSPF.
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 transition doesn't restrict tunnel
types, either. Actually since remote ASBR information for VA isn't
needed in VA-based transition, standard softwire tunnel can be used
in the scenario. Note that signaling is needed for some types of
tunnels using BGP. Refer to [I-D. draft-wu-softwire-mesh-framework]
and RFC5512(The BGP Encapsulation SAFI and the BGP Tunnel
Encapsulation Attribute) for details.
4.3. Cooperate with softwire mesh
VA-base transition can cooperate well with softwire mesh, just
similar to popular prefix can be used in VA. Since the two
mechanisms both influent data forwarding by inject entries to PE's
FIB, there will be no confliction in them. Actually, if both
mechanisms are used, because VPs' masks are usually shorter than
regular prefixes, softwire entries will have higher priority. Here
we also call the prefixes of softwire entries popular prefixes.
For some common, high-traffic IPv4 connections, PEs can choose to
follow popular prefixes, so only one time encapsulation and
Cui, et al. Expires November 23, 2009 [Page 12]
Internet-Draft VA-Based IPv6 Transition May 2009
decapsulation is needed and encapsulated packets can follow the
shortest path in IPv6 backbone; for other IPv4 connections, PEs can
refer to VA-based transition so the FIB size won't be large and PEs
don't have to build a lot of BGP peers and tunnels with other PEs.
4.4. Inter-domain situation
The situation will be different if two IPv4 network from two IPv6
domains which run VA-based IPv6 transition want to get connected. In
this inter-domain scenario, APRs in one ISP don't have the regular
prefixes of the IPv4 network behind the other ISP, though it may fall
within its VPs. So if a PE receives an IPv4 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 IPv4 FIB
table for the destination. Apparently APRs need to learn IPv4 routes
of the other ISP.
The scenario is illustrated in figure3. Our basic thought is to get
APRs from different domains to exchange IPv4 sub-prefixes if their
VPs have overlaps, through EBGP process. We can either build EBGP
peers directly between APRs, or use an extra BGP router to run EBGP
process and collect and distribute inter-domain IPv4 sub-prefixes.
The former way provides less number of tunnels in forwarding
procedure while the latter one provider simpler routing scheme.
However, both the two methods described here are incipient and
require further consideration.
Cui, et al. Expires November 23, 2009 [Page 13]
Internet-Draft VA-Based IPv6 Transition May 2009
IPv6 domain1 IPv6 domain2
+-------------------------+ +-------------------------+
| [ EBGP ROUTER]=====|=====|===== [ EBGP ROUTER] |
| : : | | : : |
| : : | | : : |
| [APR] [APR] | | [APR] [APR] |
| : : : : | | : : : : |
| : : : | | : : : |
| : : : : | | : : : : |
| +--------+ +--------+ | | +--------+ +--------+ |
+-| PE |---| PE |-+ +-| PE |---| PE |-+
| IPv4/6 | | IPv4/6 | | IPv4/6 | | IPv4/6 |
+--------+ +--------+ +--------+ +--------+
| | | |
| | | |
+--------+ +--------+ +--------+ +--------+
| IPv4 | | IPv4 | | IPv4 | | IPv4 |
| Client | | Client | | Client | | Client |
| Network| | Network| | Network| | Network|
+--------+ +--------+ +--------+ +--------+
Figure 3 inter-domain scenario
Cui, et al. Expires November 23, 2009 [Page 14]
Internet-Draft VA-Based IPv6 Transition May 2009
5. Benefits of VA-Based IPv6 Transition
There are mainly three benefits using VA-Based IPv6 Transition in
IPv4-over-IPv6 traversing. The first one is that it can
significantly shrink the FIB size of the PEs. Every PE needs to
store only the IPv4 VPs of all APRs, while the whole IPv4 regular
sub-prefixes are distributed in the APRs' FIBs. PE can also keep a
few regular prefixes in its FIB for softwire use to reach better
performance. So we achieve better scalability than pure softwire
mesh.
Secondly, it can reduce the total amount of routing activity for
transition. 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. 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 IPv6 Transition can provide the IPv6 ISP with a
better way to manage the IPv4-over-IPv6 traversing service. In this
mechanism, IPv4 routes are collected in APRs maintained by the ISP.
PEs don't know the detailed routes: they just learn a few VPs for
IPv4 forwarding. If a new client IPv4 network wants to jump in and
get connected with other IPv4 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 November 23, 2009 [Page 15]
Internet-Draft VA-Based IPv6 Transition May 2009
6. IPv6-over-IPv4 scenario
So far we've only discussed the IPv4-over-IPv6 scenario, but we
believe the opposite scenario is similar: IPv6-over-IPv4 doesn't
bring extra difficulty. For tunneled forwarding, standard softwire
tunnels don't restrict the IP protocol type; in fact, the transit
network protocol and the network protocol inside the tunnel are
referred as E-IP and I-IP for general purpose in [I-D.
draft-wu-softwire-mesh-framework]. As for routing, when BGP is used,
RFC4798 (Connecting IPv6 Islands over IPv4 MPLS using IPv6 Provider
Edge Routers (6PE)) defines the extension of MP-BGP to support
V6NLRI-V4NH; If we choose to use OSPF and the new registration
protocol, then we need to do extension and definition in either
scenario. VA-based IPv6 transition fits both IPv6-over-IPv4 scenario
and IPv4-over-IPv6 scenario naturally.
Cui, et al. Expires November 23, 2009 [Page 16]
Internet-Draft VA-Based IPv6 Transition May 2009
7. Security considerations
Since our mechanism is based on VA, we refer to 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 November 23, 2009 [Page 17]
Internet-Draft VA-Based IPv6 Transition May 2009
8. 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 everyone else
contributed to VA.
Cui, et al. Expires November 23, 2009 [Page 18]
Internet-Draft VA-Based IPv6 Transition May 2009
9. References
9.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.
9.2. Informative References
[I-D.francis-intra-va]
Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and
L. Zhang, "FIB Suppression with Virtual Aggregation",
draft-francis-intra-va-01 (work in progress), April 2009.
[I-D.ietf-softwire-mesh-framework]
Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh
Framework", draft-ietf-softwire-mesh-framework-06 (work in
progress), February 2009.
Cui, et al. Expires November 23, 2009 [Page 19]
Internet-Draft VA-Based IPv6 Transition May 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
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
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
Cui, et al. Expires November 23, 2009 [Page 20]
Internet-Draft VA-Based IPv6 Transition May 2009
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
Cui, et al. Expires November 23, 2009 [Page 21]