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]