idnits 2.17.1 draft-cui-softwire-va-based-softwire-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The abstract seems to contain references ([I-D.ietf-grow-va], [RFC5565]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 6 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (July 6, 2009) is 5406 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'APR' is mentioned on line 499, but not defined ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) == Outdated reference: A later version (-06) exists of draft-ietf-grow-va-00 Summary: 5 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft P. Wu 4 Intended status: Standards Track S. Wang 5 Expires: January 7, 2010 M. Xu 6 J. Wu 7 X. Li 8 Tsinghua University 9 L. Zhang 10 UCLA 11 C. Metz 12 Cisco Systems, Inc. 13 July 6, 2009 15 VA-Based Softwire 16 draft-cui-softwire-va-based-softwire-00 18 Status of this Memo 20 This Internet-Draft is submitted to IETF in full conformance with the 21 provisions of BCP 78 and BCP 79. This document may contain material 22 from IETF Documents or IETF Contributions published or made publicly 23 available before November 10, 2008. The person(s) controlling the 24 copyright in some of this material may not have granted the IETF 25 Trust the right to allow modifications of such material outside the 26 IETF Standards Process. Without obtaining an adequate license from 27 the person(s) controlling the copyright in such materials, this 28 document may not be modified outside the IETF Standards Process, and 29 derivative works of it may not be created outside the IETF Standards 30 Process, except to format it for publication as an RFC or to 31 translate it into languages other than English. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF), its areas, and its working groups. Note that 35 other groups may also distribute working documents as Internet- 36 Drafts. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 The list of current Internet-Drafts can be accessed at 44 http://www.ietf.org/ietf/1id-abstracts.txt. 46 The list of Internet-Draft Shadow Directories can be accessed at 47 http://www.ietf.org/shadow.html. 49 This Internet-Draft will expire on January 7, 2010. 51 Copyright Notice 53 Copyright (c) 2009 IETF Trust and the persons identified as the 54 document authors. All rights reserved. 56 This document is subject to BCP 78 and the IETF Trust's Legal 57 Provisions Relating to IETF Documents in effect on the date of 58 publication of this document (http://trustee.ietf.org/license-info). 59 Please review these documents carefully, as they describe your rights 60 and restrictions with respect to this document. 62 Abstract 64 The increasing deployment of IPv6 networks in both customer networks 65 and ISP networks leads to two common traversing transition scenarios: 66 in the first scenario, an IPv6-only backbone network needs to provide 67 IP connectivity between IPv4 networks, we call it IPv4-over-IPv6 68 scenario; In the second scenario, IPv6 networks need to be 69 interconnected over an IPv4 transit network, we call it IPv6-over- 70 IPv4 scenario. In both scenarios, the ISP operating the transit 71 network of one address family must offer transit services for 72 attached client networks of the other address family. The Softwire 73 WG has defined softwire mesh mechanism [RFC5565] for the two 74 traversing scenarios. Softwire mesh uses automatic softwire tunnels 75 employing multi-protocol BGP extensions for distributing E-IP routes, 76 where both BGP peers and tunnels between PEs forms a full-mesh 77 architecture. 79 Inspired by the Virtual Aggregation approach [I-D.ietf-grow-va] to 80 IPv4 routing scalability, in this draft we proposed a scalable 81 mechanism for distributing E-IP routes over the transit network. Our 82 solution can significantly reduce the forwarding information base 83 (FIB) size at Address Family Border Routers (AFBRs) as well as the 84 total amount of routing updates, and offers the ISP an easy way to 85 manage the transit service. 87 Table of Contents 89 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 90 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 7 91 3. VA-based softwire framework . . . . . . . . . . . . . . . . . 8 92 3.1. Scenario . . . . . . . . . . . . . . . . . . . . . . . . . 8 93 3.2. Downlink routing . . . . . . . . . . . . . . . . . . . . . 9 94 3.3. Uplink routing . . . . . . . . . . . . . . . . . . . . . . 9 95 3.4. Tunneled forwarding . . . . . . . . . . . . . . . . . . . 10 96 4. Discussion on Design Details . . . . . . . . . . . . . . . . . 12 97 4.1. BGP-based routing scheme . . . . . . . . . . . . . . . . . 12 98 4.2. Tunnel . . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 4.3. Cooperate with softwire mesh . . . . . . . . . . . . . . . 13 100 5. Benefits of VA-based softwire . . . . . . . . . . . . . . . . 14 101 6. Relation with VA . . . . . . . . . . . . . . . . . . . . . . . 15 102 7. Inter-domain consideration . . . . . . . . . . . . . . . . . . 16 103 8. Security considerations . . . . . . . . . . . . . . . . . . . 17 104 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 105 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 106 10.1. Normative References . . . . . . . . . . . . . . . . . . . 19 107 10.2. Informative References . . . . . . . . . . . . . . . . . . 19 108 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 110 1. Introduction 112 Recently more and more IPv6 networks have be deployed in both 113 customer networks and transit networks, while the existing IPv4 114 networks still carry the major network traffic and host most network 115 services and applications. It is commonly believed that IPv4 and 116 IPv6 networks will co-exist for the foreseeable future. There has 117 been basically two aspects of IPv6 transition research: connection 118 between IPv4 and IPv6 nodes and connection between networks of one 119 address family traversing network of the other address family. Basic 120 solution for the former one is address translation and for the latter 121 one is tunneling. 123 For traversing transition, softwire mesh provides a way that networks 124 of one address family can be connected through transit network of the 125 other address family. It's done by extending MP-BGP to exchange 126 external routing information between dual-stack Provider Edge routers 127 (PE), and using softwire tunnel to forward External-IP(E-IP) packets 128 through encapsulation and decapsulation. In both data plane and 129 control plane, all PEs form a full mesh. 131 Virtual Aggregation (VA) mechanism can reduce the FIB size of routers 132 by an order of magnitude. It can be deployed autonomously by an ISP, 133 and co-exist with legacy routers in the ISP. VA divides the IP 134 address space into Virtual Prefixes (VPs), and uses tunnels to 135 aggregate the regular sub-prefixes within each VP. For each sub- 136 prefix within a VP, Aggregation Point Routers (APRs) have a tunnel 137 from themselves to the remote ASBR (Autonomous System Border Router) 138 where packets for that prefix should be delivered. Because APRs may 139 not be on the shortest path between the ingress and egress routers, 140 the packets may take a longer path and experience additional latency. 141 However as shown in [I-D.ietf-grow-va], a proper placement of ARPs 142 can make the path length and network load increase negligible. 143 Furthermore, VA can make majority of data packet avoid traversing the 144 APR by installing the routes for popular prefixes in all routers. In 145 other words, popular prefixes will not be aggregated. Packets to 146 those prefixes are tunneled directly to the BGP NEXT_HOP. 148 This draft proposes an approach that adopts the basic idea from VA to 149 solve the traversing transition problem, called VA-based softwire. 150 In control plane, it organizes the E-IP address space into VPs and 151 aggregates the E-IP routes from the client network; regular E-IP 152 prefixes are collected by APRs in Internal-IP(I-IP) backbone, while 153 PEs only have to maintain VPs in the FIB. In data plane, VA-based 154 softwire uses APRs in backbone network to be intermediate tunneling 155 forwarders between PEs; E-IP packets are tunneled to APRs from client 156 network, and then tunneled to the destination client network. 158 VA-based softwire can significantly reduce the transition FIB size of 159 PEs, and the total amount of transition routing activity (routing 160 protocol process in transition-related routers and transition-related 161 routing packets delivered), and provide the ISP of backbone networks 162 with a better way to manage the transit service. This mechanism has 163 good scalability and works well when the number of client networks 164 increases. 166 2. Terminology 168 I-IP: according to [RFC5565], the term "I-IP"("Internal IP") refers 169 to the form of IP (i.e., either IPv4 or IPv6) that is supported by 170 the transit backbone network. The P routers support only I-IP. 172 E-IP: the term "E-IP" ("External IP") refers to the form of IP that 173 is supported by the client networks. In the scenarios of interest, 174 E-IP is IPv4 if and only if I-IP is IPv6, and E-IP is IPv6 if and 175 only if I-IP is IPv4. 177 Aggregation Point Router (APR): This draft adopts the name of APR 178 from VA in [I-D.ietf-grow-va]. An Aggregation Point Router (APR) is 179 a router that aggregates a Virtual Prefix (VP) by installing routes 180 (into the FIB) for all of the sub-prefixes within the VP. Every APR 181 can hold several VPs and the corresponding sub-prefixes for every VP. 182 In this draft, all VPs and sub-prefixes are E-IP prefixes and APR can 183 be deployed in arbitrarily position in I-IP backbone; for each sub- 184 prefix within the VP, APRs have a tunnel to the client network where 185 E-IP packets can reach their destinations. 187 Provider Edge router (PE): The dual-stack edge routers of the 188 backbone network, where E-IP packets enter and leave the backbone. 189 PE is often referred to as AFBR (Address Family Border Router). 190 Interior nodes of the backbone are often known as "P routers". 192 Popular Prefix: This draft adopts the name of popular prefix from VA. 193 In VA, a popular prefix is a sub-prefix that is installed in a router 194 in addition to the sub-prefixes it holds by virtue of being an 195 Aggregation Point Router. The popular prefix allows packets to 196 follow the shortest path. In VA-based softwire, a popular prefix is 197 an E-IP prefix installed in a PE router in addition to VPs. E-IP 198 packets whose destination falls within popular prefix can traverse 199 I-IP backbone in softwire mesh tunnels. 201 Virtual Prefix (VP): This draft adopts the name of VP from VA. A 202 Virtual Prefix is a prefix used to aggregate its contained regular 203 prefixes (sub-prefixes). A VP is not physically aggregatable, and it 204 is aggregated at APRs through the use of tunnels. 206 3. VA-based softwire framework 208 3.1. Scenario 210 The scenario of VA-based softwire is illustrated in figure1. A 211 number of P routers compose an I-IP-only backbone, in which a few 212 APRs are deployed. The PE routers are dual-stack and connected to 213 E-IP client networks. Every PE builds tunnels with every APR. The 214 I-IP backbone acts as a transit core to transport E-IP packets across 215 the I-IP backbone. This enables each of E-IP client network to 216 communicate with each other via two hop tunnels. 218 If E-IP is IPv6 and I-IP is IPv4, the scenario is IPv6-over-IPv4; 219 else E-IP is IPv4 and I-IP is IPv6, then the scenario is IPv4-over- 220 IPv6. 222 +--------+ +--------+ 223 | E-IP | | E-IP | 224 | Client | | Client | 225 | Network| | Network| 226 +--------+ +--------+ 227 | | 228 | | 229 +----------+ +----------+ 230 |Dual-Stack| |Dual-Stack| 231 +--| PE |-| PE |--+ 232 | +----------+ +----------+ | 233 | : : : : | 234 | : : : | 235 | : : : : | I-IP 236 | [APR] [APR] | backbone 237 | : : : : | 238 | : : : | 239 | : : : : | 240 | +----------+ +----------+ | 241 +--|Dual-Stack|-|Dual-Stack|--+ 242 | PE | | PE | 243 +----------+ +----------+ 244 | | 245 +--------+ +--------+ 246 | E-IP | | E-IP | 247 | Client | | Client | 248 | Network| | Network| 249 +--------+ +--------+ 251 Figure 1 VA-based Softwire Scenario 253 In the described scenario, VA-based softwire provides connectivity 254 for E-IP client network in three steps: downlink routing, uplink 255 routing and tunneled forwarding. 257 3.2. Downlink routing 259 In downlink routing, every selected APR must distribute its VP 260 information to every PE. VP can be configured in advance in every 261 APR, that is, Every APR is configured with which VPs it is 262 responsible for. Then ARP must advertise its VPs to all PEs, using 263 some intra-domain routing protocol. 265 In VA it is said that initial VPs can be statically configured in 266 every VA router as VP-list, and a VP can be added by some APR 267 originating routes for it and advertising these routes, also a VP can 268 be deleted by first removing it from the VP-Lists of non-APRs, 269 waiting for them to install sub-prefixes and then remove it from the 270 APRs. This draft, however, uses the uniform routing method that 271 initial VPs and all VP changes are first configured in APRs and then 272 advertised to all PEs for automaticity and simplicity. How to 273 process this routing behavior is still a concern, since E-IP routes 274 need to be advertised in or through I-IP network. We'll discuss this 275 in section 4.1. 277 Here we give an example of downlink routing. Suppose the backbone is 278 IPv6 and contains 2 APRs, APR1 is responsible for VP 0.0.0.0/1 and VP 279 128.0.0.0/2 while APR2 is responsible for VP 192.0.0.0/2. IPv4 280 client networks attached to the backbone through 2 PEs, PE1 is 281 attached with network 10.0.0.0/16 and 192.2.0.0/16 while PE2 is 282 attached with network 144.0.0.0/8. Then in this step, APR1 283 advertises the VPs of 0.0.0.0/1 and 128.0.0.0/2 to both PE1 and PE2, 284 APR2 advertises the VP 192.0.0.0/2 to PE1 and PE2. 286 After this step, every PE has all the VPs in its FIB table so it 287 knows which APR to forward an E-IP packet to, even there is no 288 regular prefix match for the destination. 290 3.3. Uplink routing 292 This step is opposite to downlink routing. In this step, every PE 293 must advertise the prefixes of the E-IP client network behind it to 294 corresponding APRs. 296 We use the example in section3.2 again to illustrate uplink routing. 297 In this example, PE1 must advertise 10.0.0.0/16 to APR1 and 298 192.2.0.0/16 to APR2, since sub-prefix 10.0.0.0/16 falls within VP 299 0.0.0.0/1 and 192.2.0.0/16 falls within 192.0.0.0/2; PE2 must 300 advertise 144.0.0.0/8 to APR1,since 144.0.0.0/8 falls within VP 301 128.0.0.0/2. 303 After this step, every APR has all the sub-prefix that is from the 304 E-IP client networks and falls within one of the VPs the APR is 305 responsible for. Therefore, every APR knows which PE to forward an 306 E-IP packet that is received from another PE earlier to. 308 3.4. Tunneled forwarding 310 In VA-based softwire, forwarding an E-IP packet through the I-IP 311 backbone includes the following steps: the ingress PE encapsulates 312 the incoming E-IP packet with the I-IP tunnel header; transmits the 313 encapsulated packet through the I-IP backbone to an APR; the APR 314 decapsulates the packet and encapsulates the packet with another I-IP 315 tunnel header; transmits the encapsulated packet through the backbone 316 to the egress PE; the egress PE decapsulates the I-IP header and 317 forwards the original E-IP packet. All the encapsulations and 318 decapsulations are performed on PEs and APRs, other routers in I-IP 319 backbone take encapsulated packets just as native I-IP packets. The 320 forwarding procedure is illustrated in figure2. 322 Tunnel1 Tunnel2 323 -----------> -----------> 324 I-IP Transit Core 325 +-+ E-IP +--+ +---+ +--+ E-IP +-+ 326 |S|--->---|PE|======>=====|APR|======>=====|PE|--->---|D| 327 +-+ +--+ +---+ +--+ +-+ 328 Original Ingress PE APR Egress PE Original 329 Source Decapsulation& Destination 330 Node Encapsulation Encapsulation Decapsulation Node 332 Figure 2 VA-based softwire: tunneled forwarding 334 When an ingress PE receives an E-IP packet from client network, it 335 looks up the destination IP address of the packet. In this case, the 336 best match for that address will be a VP route whose next hop is an 337 APR. The ingress PE must forward the packet through a tunnel to the 338 APR. This is done by encapsulating the packet, using an I-IP- 339 encapsulating header with the destination address of the APR, and 340 then forwarding the packet to I-IP network. 342 When the APR receives the encapsulated I-IP packet, it extracts the 343 payload, i.e., the original E-IP packet, and looks up the packet's 344 destination address. In this case, the best match for that address 345 will be a regular E-IP route whose next hop is a PE (the egress PE). 346 The APR will encapsulate the packet again, this time with the 347 destination I-IP address of the egress PE, and then forward the 348 packet to I-IP network again. 350 When the egress PE receives the encapsulated I-IP packet, it extracts 351 the payload, gets the original E-IP packet and forwards it further by 352 looking up its IP destination address in E-IP FIB. 354 4. Discussion on Design Details 356 4.1. BGP-based routing scheme 358 One approach is to use BGP to propagate E-IP routing informaiton 359 downlink and uplink. Every APR sets up and maintains an iBGP session 360 with every PE. We assume that these iBGP sessions are statically 361 configured at APRs and PEs. 363 In downlink direction, VPs will be advertised through BGP process, 364 from every APR to every PE. Note here the prefix is of E-IP format 365 and next hop is of I-IP format. For IPv4-over-IPv6 scenario, 366 [RFC5549] has made an extension of MP-BGP, modifying MP_REACH_NLRI 367 format to convey IPv4 NLRI prefix information with an IPv6 next hop 368 address, we can just use this v4nlri-v6nh extension here. As for 369 IPv6-over-IPv4 scenario, [RFC4798] provides a way that IPv6 routing 370 information can be distributed in IPv4 BGP by egress PE associating 371 MPLS labels with IPv6 prefixes; besides, we believe that the 372 extension of MP-BGP by [RFC5549] can also be used in IPv6-over-IPv4 373 scenario to advertised IPv6 NLRI with IPv4 next hop through IPv4 BGP. 374 BGP process in APRs and PEs need to be modified to fit the possible 375 extensions. 377 In uplink direction, BGP routing is similar to downlink routing, 378 except this time every PE advertise the prefixes of the E-IP client 379 network behind it to corresponding APRs. In this part, because only 380 the APRs whose VPs the E-IP prefixes fall within need to receive the 381 routes, ideally we can build BGP peers only between such APRs and 382 PEs. However, we've already built BGP peers between every APR and 383 every PE in downlink routing, so we can just add some filters in 384 every APR in order to only accept what it actually needs, that is, 385 the E-IP prefixes fall within its VPs. 387 4.2. Tunnel 389 In VA, a variety of tunnel types can be used: MPLS LSPs, IP-in-IP, 390 GRE, L2TP, and so on. VA-based softwire doesn't restrict tunnel 391 types, either. Actually since remote ASBR information for VA isn't 392 needed in VA-based softwire, standard softwire tunnel can be used in 393 the scenario. Note that signaling is needed for some types of 394 tunnels using BGP. Refer to [RFC5565] and [RFC5512] for details. 395 Note that encapsulation and decapsulation can be implemented by 396 hardware, so it won't become a heavy burden for APRs and PEs' 397 forwarding process. 399 4.3. Cooperate with softwire mesh 401 VA-base softwire can cooperate well with softwire mesh, just similar 402 to popular prefix can be used in VA besides VPs. Since the two 403 mechanisms both influent data forwarding by inject entries to PE's 404 FIB, there will be no confliction between them. Actually, if both 405 mechanisms are used, entries of softwire mesh will have higher 406 priority because VPs' masks are usually shorter than regular 407 prefixes. Here we also call the prefixes of softwire mesh entries 408 popular prefixes. 410 For some common, heavy-traffic softwire connections, PEs can choose 411 to follow popular prefixes, so only one time encapsulation and 412 decapsulation is needed and encapsulated packets can follow the 413 shortest path in I-IP backbone; for other softwire connections, PEs 414 can refer to VA-based softwire so the FIB size won't be large and PEs 415 won't have to build a lot of BGP peers and tunnels with other PEs. 417 5. Benefits of VA-based softwire 419 There are mainly three benefits using VA-based softwire in traversing 420 transition. The first one is that it can significantly reduce the 421 FIB size of the PEs. Every PE only needs to store the E-IP VPs of 422 all APRs, while the whole E-IP regular sub-prefixes are distributed 423 in the APRs' FIBs. PE can also keep a few regular prefixes for 424 softwire mesh use, to reach better performance. So VA-based softwire 425 achieves better scalability than pure softwire mesh. 427 Secondly, it can reduce the total amount of transition-related 428 routing activity. In this mechanism routing is executed between 429 every APR and every PE. Since there are only a few APRs in the 430 domain, the total amount of routing activity is in proportion to the 431 number of PEs. However, in softwire mesh, every two PEs form a BGP 432 peer, so the amount of routing activity is in proportion to the 433 square of the number of PEs. It's obvious that we can carry out less 434 routing activity than softwire simply implementing uplink and 435 downlink routing in BGP. 437 Moreover, VA-based softwire can provide the ISP of E-IP networks with 438 a better way to manage the IPv4-over-IPv6 or IPv6-over-IPv4 439 traversing service. In this mechanism, E-IP routes are collected in 440 APRs, maintained by the ISP. PEs don't know the detailed routes: 441 they just learn a few VPs for forwarding E-IP packets. If a new 442 client network wants to jump in and get connected with other E-IP 443 networks, the ISP just needs to tell the access PE the addresses of 444 the APRs. It's more transparent than softwire mesh where PE needs to 445 know the addresses of all other PEs, and fewer configurations are 446 needed. 448 6. Relation with VA 450 This draft adopts the aggregated, centralized architecture, and the 451 basic idea of VP aggregating sub-prefixes from VA. Both the two 452 mechanisms achieve their goals using virtual aggregation, with a 453 slight path length and router load increase. Both the two mechanisms 454 require minor changes to most routers. 456 However, our proposal is actually quite different from VA. First of 457 all, the problem we are trying to solve is different. VA solves the 458 intra-domain FIB size problem using VP and tunnels; every VA router 459 in the domain will benefit from VA with a FIB suppression. Our draft 460 is mainly aimed to propose an IPv6 transition mechanism with a new 461 architecture instead of solving the FIB problem of the routers in the 462 backbone. Second, the sphere of influence of the two mechanisms is 463 different. VA can be deployed for every router in the domain, and 464 all the intra-domain flows in that domain will be redirected by VA. 465 VA-based softwire won't influent the I-IP domain except for the 466 changes in APRs and PEs, and the traffic injected from client 467 network. The native routing and forwarding process in the I-IP 468 domain will work just the same as the situation without VA-based 469 softwire. In fact, all related routing and tunneled forwarding 470 process are implemented in APRs and PEs; other routers in the domain 471 won't even notice the change. Third, the FIB size problems solved by 472 the two mechanisms are different. VA reduces the size of global FIB 473 for every router in the domain. VA-based softwire reduces only the 474 E-IP FIBs of PEs, which is in proportion to the number of client 475 networks. 477 7. Inter-domain consideration 479 The situation will be different if two E-IP networks from two I-IP 480 domains which run VA-based softwire want to get connected. In this 481 inter-domain scenario, APRs in one ISP don't have the regular 482 prefixes of the E-IP network behind the other ISP, though it may fall 483 within its VPs. So if a PE receives an E-IP packet whose destination 484 is in the other ISP, it will still encapsulate and send the packet to 485 the APR whose VP matches the destination in its own ISP; After the 486 corresponding APR receive and decapsulate the packet, it has to drop 487 the packet since there is no regular prefix match in its E-IP FIB 488 table for the destination. So apparently APRs need to learn E-IP 489 routes of the other ISP. 491 The scenario is illustrated in figure3. Detailed design will be our 492 further work. 494 I-IP domain1 I-IP domain2 495 +---------------------------+ +---------------------------+ 496 | [ EBGP ROUTER ]=======|=====|=======[ EBGP ROUTER ] | 497 | : : | | : : | 498 | : : | | : : | 499 | [APR] [APR] | | [APR] [APR] | 500 | : : : : | | : : : : | 501 | : : : | | : : : | 502 | : : : : | | : : : : | 503 | +----------+ +----------+ | | +----------+ +----------+ | 504 +-|Dual-Stack|-|Dual-Stack|-+ +-|Dual-Stack|-|Dual-Stack|-+ 505 | PE | | PE | | PE | | PE | 506 +----------+ +----------+ +----------+ +----------+ 507 | | | | 508 | | | | 509 +--------+ +--------+ +--------+ +--------+ 510 | E-IP | | E-IP | | E-IP | | E-IP | 511 | Client | | Client | | Client | | Client | 512 | Network| | Network| | Network| | Network| 513 +--------+ +--------+ +--------+ +--------+ 515 Figure 3 inter-domain scenario 517 8. Security considerations 519 Since our mechanism is based on VA, we refer to [I-D.ietf-grow-va] 520 for security concerns. Our mechanism doesn't introduce security 521 problems other than the ones of VA's. 523 If VA is configured properly, or we say if all APRs and PEs are 524 configured properly, then any new concerns for intra-domain security 525 appear to be relatively minor. In particular, DoS attack to APR 526 won't significantly worsen the DoS problem, and VA won't limit the 527 deployment of DoS defense systems. 529 As to the situation of Mis-configured VA, VA introduces the 530 possibility that a VP is advertised outside of an AS. Usually a VP 531 is large(i.e. larger than any real prefixes), and the impact is 532 minimal. Smaller prefixes will be preferred because of best-match 533 semantics, and so the only impact is that packets that otherwise have 534 no matching routes will be sent to the misbehaving AS and dropped 535 there. If the VP is small, then it may cause a traffic hijack which 536 can happen with or without VA, so VA doesn't introduce a new security 537 problem. 539 9. Acknowledgements 541 This draft gets the very original idea from VA, and extends the idea 542 to solve a different problem: IPv4-over-IPv6 transiton. The authors 543 would like to thank P.Francis, X.Xu, H.Ballani, D. Jen, R. Raszuk, L. 544 Zhang and everyone else who contributed to VA. 546 10. References 548 10.1. Normative References 550 [RFC4798] De Clercq, J., Ooms, D., Prevost, S., and F. Le Faucheur, 551 "Connecting IPv6 Islands over IPv4 MPLS Using IPv6 552 Provider Edge Routers (6PE)", RFC 4798, February 2007. 554 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 555 Subsequent Address Family Identifier (SAFI) and the BGP 556 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 558 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 559 Layer Reachability Information with an IPv6 Next Hop", 560 RFC 5549, May 2009. 562 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 563 Framework", RFC 5565, June 2009. 565 10.2. Informative References 567 [I-D.ietf-grow-va] 568 Francis, P., Xu, X., Ballani, H., Jen, D., Raszuk, R., and 569 L. Zhang, "FIB Suppression with Virtual Aggregation", 570 draft-ietf-grow-va-00 (work in progress), May 2009. 572 Authors' Addresses 574 Yong Cui 575 Tsinghua University 576 Department of Computer Science, Tsinghua University 577 Beijing 100084 578 P.R.China 580 Phone: +86-10-6278-5822 581 Email: cy@csnet1.cs.tsinghua.edu.cn 583 Peng Wu 584 Tsinghua University 585 Department of Computer Science, Tsinghua University 586 Beijing 100084 587 P.R.China 589 Phone: +86-10-6278-5822 590 Email: weapon@csnet1.cs.tsinghua.edu.cn 592 Shengling Wang 593 Tsinghua University 594 Department of Computer Science, Tsinghua University 595 Beijing 100084 596 P.R.China 598 Phone: +86-10-6278-5822 599 Email: slwang@csnet1.cs.tsinghua.edu.cn 601 Mingwei Xu 602 Tsinghua University 603 Department of Computer Science, Tsinghua University 604 Beijing 100084 605 P.R.China 607 Phone: +86-10-6278-5822 608 Email: xmw@csnet1.cs.tsinghua.edu.cn 609 Jianping Wu 610 Tsinghua University 611 Department of Computer Science, Tsinghua University 612 Beijing 100084 613 P.R.China 615 Phone: +86-10-6278-5983 616 Email: jianping@cernet.edu.cn 618 Xing Li 619 Tsinghua University 620 Department of Electronic Engineering, Tsinghua University 621 Beijing 100084 622 P.R.China 624 Phone: +86-10-6278-5983 625 Email: xing@cernet.edu.cn 627 Lixia Zhang 628 UCLA 630 Email: lixia@cs.ucla.edu 632 Chris Metz 633 Cisco Systems, Inc. 634 3700 Cisco Way 635 San Jose, Ca. 95134 636 USA 638 Email: chmetz@cisco.com