[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/