idnits 2.17.1 draft-wu-softwire-4over6-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (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 : ---------------------------------------------------------------------------- ** There are 4 instances of too long lines in the document, the longest one being 1 character in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (December 7, 2009) is 5254 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'P' is mentioned on line 154, but not defined ** Obsolete normative reference: RFC 5512 (Obsoleted by RFC 9012) ** Obsolete normative reference: RFC 5549 (Obsoleted by RFC 8950) Summary: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J. Wu 3 Internet-Draft Y. Cui 4 Intended status: Experimental X. Li 5 Expires: June 10, 2010 M. Xu 6 Tsinghua University 7 C. Metz 8 Cisco Systems, Inc. 9 December 7, 2009 11 4over6 Transit Solution using IP Encapsulation and MP-BGP Extensions 12 draft-wu-softwire-4over6-04 14 Abstract 16 The emerging and growing deployment of IPv6 networks will introduce 17 cases where connectivity with IPv4 networks crossing IPv6 transit 18 backbones is desired. This document describes a mechanism for 19 automatic discovery and creation of IPv4 over IPv6 tunnels via 20 extensions to multi- protocol BGP. It is targeted at connecting 21 islands of IPv4 networks across an IPv6-only backbone without the 22 need for a manually configured overlay of tunnels. The mechanisms 23 described in this document have been implemented, tested and deployed 24 on the large research IPv6 network in China. 26 Status of this Memo 28 This Internet-Draft is submitted to IETF in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF), its areas, and its working groups. Note that 33 other groups may also distribute working documents as Internet- 34 Drafts. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 The list of current Internet-Drafts can be accessed at 42 http://www.ietf.org/ietf/1id-abstracts.txt. 44 The list of Internet-Draft Shadow Directories can be accessed at 45 http://www.ietf.org/shadow.html. 47 This Internet-Draft will expire on June 10, 2010. 49 Copyright Notice 51 Copyright (c) 2009 IETF Trust and the persons identified as the 52 document authors. All rights reserved. 54 This document is subject to BCP 78 and the IETF Trust's Legal 55 Provisions Relating to IETF Documents 56 (http://trustee.ietf.org/license-info) in effect on the date of 57 publication of this document. Please review these documents 58 carefully, as they describe your rights and restrictions with respect 59 to this document. Code Components extracted from this document must 60 include Simplified BSD License text as described in Section 4.e of 61 the Trust Legal Provisions and are provided without warranty as 62 described in the BSD License. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. 4over6 Framework Overview . . . . . . . . . . . . . . . . . . 4 70 3. Prototype Implementation . . . . . . . . . . . . . . . . . . . 6 71 3.1. 4over6 Packet Forwarding . . . . . . . . . . . . . . . . . 6 72 3.2. Encapsulation table . . . . . . . . . . . . . . . . . . . 7 73 3.3. MP-BGP 4over6 Protocol Extensions . . . . . . . . . . . . 8 74 3.3.1. Receiving Routing Information from Local CE . . . . . 9 75 3.3.2. Receiving 4over6 Routing Information from a remote 76 4over6 PE . . . . . . . . . . . . . . . . . . . . . . 9 78 4. 4over6 Deployment Experience . . . . . . . . . . . . . . . . . 11 79 4.1. CNGI-CERNET2 . . . . . . . . . . . . . . . . . . . . . . . 11 80 4.2. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network . . . . . 11 81 4.3. Deployment Experiences . . . . . . . . . . . . . . . . . . 12 83 5. On-going Experiment . . . . . . . . . . . . . . . . . . . . . 13 85 6. Relationship to Softwires Mesh Effort . . . . . . . . . . . . 14 87 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 89 8. Security Considerations . . . . . . . . . . . . . . . . . . . 16 91 9. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 93 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 18 95 11. Normative References . . . . . . . . . . . . . . . . . . . . . 19 96 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 98 1. Introduction 100 Due to the lack of IPv4 address space, more and more IPv6 networks 101 have been deployed not only on edge networks, but also on backbone 102 networks. However, there are still a large number of legacy IPv4 103 hosts and applications. As a result, IPv6 networks and IPv4 104 applications/hosts will have to coexist for a long period of time. 106 The emerging and growing deployment of IPv6 networks will introduce 107 cases where connectivity with IPv4 networks is desired. Some IPv6 108 backbones will need to offer transit services to attached IPv4 access 109 networks. The method to achieve this would be to encapsulate and 110 then transport the IPv4 payloads inside IPv6 tunnels spanning the 111 backbone. There are some IPv6/IPv4-related tunneling protocols and 112 mechanisms defined in the literature. But at the time that the 113 mechanism described in this document was introduced, most of these 114 existing techniques focus on the problem of IPv6 over IPv4, rather 115 than the case of IPv4 over IPv6. Encapsulation methods alone, such 116 as that defined in [RFC2473], require manual configuration in order 117 to operate. When a large number of tunnels are necessary, manual 118 configuration can become burdensome. To the above problem, this 119 document describes an approach, referred to as "4over6". 121 The 4over6 mechanism concerns two aspects: the control plane and the 122 data plane. The control plane needs to address the problem of how to 123 setup an IPv4 over IPv6 tunnel in an automatic and scalable fashion 124 between a large number of edge routers. This document describes 125 experimental extensions to MP-BGP [RFC4271] [RFC4760] employed to 126 communicate tunnel end-point information and establish 4over6 tunnels 127 between dual-stack Provider Edge (PE) routers positioned at the edge 128 of the IPv6 backbone network. Once the 4over6 tunnel is in place, 129 the data plane focuses on the packet forwarding processes of 130 encapsulation and decapsulation. 132 2. 4over6 Framework Overview 134 In the topology shown in figure 1, a number of IPv6-only P routers 135 compose a native IPv6 backbone. The PE routers are dual-stack and 136 referred to as 4over6 PE routers. The IPv6 backbone acts as a 137 transit core to transport IPv4 packets across the IPv6 backbone. 138 This enables each of IPv4 access islands to communicate with each 139 other via 4over6 tunnels spanning the IPv6 transit core. 141 _._._._._ _._._._._ 142 | IPv4 | | IPv4 | 143 | access | | access | 144 | island | | island | 145 _._._._._ _._._._._ 146 | | 147 Dual-Stack Dual-Stack 148 "4over6 PE" "4over6 PE" 149 | | 150 | | 151 __+____________________+__ 152 4over6 / : : : : \ IPv6 only 153 Tunnels | : : : : | transit core 154 between | : [P] : | with multiple 155 PEs | : : : : | [P routers] 156 | : : : : | 157 \_._._._._._._._._._._._._./ 158 | / \ | 159 | | 160 Dual-Stack Dual-Stack 161 "4over6 PE" "4over6 PE" 162 | | | 163 _._._._._ _._._._._ 164 | IPv4 | | IPv4 | 165 | access | | access | 166 | island | | island | 167 _._._._._ _._._._._ 169 Figure 1: IPv4 over IPv6 network topology 171 As shown in figure 1, there are multiple dual-stack PE routers 172 connected to the IPv6 transit core. In order for the ingress 4over6 173 PE router to forward an IPv4 packet across the IPv6 backbone to the 174 correct egress 4over6 PE router, the ingress 4over6 PE router must 175 learn which IPv4 destination prefixes are reachable through each 176 egress 4over6 PE router. MP-BGP will be extended to distribute the 177 destination IPv4 prefix information between peering dual-stack PE 178 routers. Section 4 of this document presents the definition of the 179 4over6 protocol field in MP-BGP and section 5 describes MP-BGP's 180 extended behavior in support of this capability. 182 After the ingress 4over6 PE router learns the correct egress 4over6 183 PE router via MP-BGP, it will forward the packet across the IPv6 184 backbone using IP encapsulation. The egress 4over6 PE router will 185 receive the encapsulated packet, remove the IPv6 header and then 186 forward the original IPv4 packet to its final IPv4 destination. 187 Section 6 describes the procedure of packet forwarding. 189 3. Prototype Implementation 191 An implementatoin of the 4over6 mechanisms described in this document 192 was developed, tested and deployed on Linux with kernel version 2.4. 193 The prototype system is composed of three components: packet 194 forwarding, the encapsulation table and MP-BGP extensions. The 195 packet forwarding and encapsulation table are Linux kernel modules 196 and the MP-BGP extension was developed by extending Zebra routing 197 software. 199 The following sections will discuss these parts in detail. 201 3.1. 4over6 Packet Forwarding 203 Forwarding an IPv4 packet through the IPv6 transit core includes 3 204 parts: encapsulation of the incoming IPv4 packet with the IPv6 tunnel 205 header; transmission of the encapsulated packet over the IPv6 transit 206 backbone; and decapsulation of the IPv6 header and forwarding of the 207 original IPv4 packet. Native IPv6 routing and forwarding are 208 employed in the backbone network since the P routers take the 4over6 209 tunneled packets as just native IPv6 packets. Therefore, 4over6 210 packet forwarding involves only the encapsulation process and the 211 decapsulation process, both of which are peformed on the 4over6 PE 212 routers. 214 Tunnel from Ingress PE to Egress PE 215 ----------------------------> 216 Tunnel Tunnel 217 Entry-Point Exit-Point 218 Node Node 219 +-+ IPv4 +--+ IPv6 Transit Core +--+ IPv4 +-+ 220 |S|-->--//-->--|PE|=====>=====//=====>=====|PE|-->--//-->--|D| 221 +-+ +--+ +--+ +-+ 222 Original Ingress PE Egress PE Original 223 Packet (Encapsulation) (Decapsulation) Packet 224 Source Destination 225 Node Node 227 Figure 2: Packet forwarding along 4over6 Tunnel 229 As shown in Figure 2, packet encapsulation and decapsulaion are both 230 on the dual-stack 4over6 PE routers. Figure 3 shows the format of 231 packet encapsulation and decapsulation. 233 +----------------------------------//-----+ 234 | IPv4 Header | Packet Payload | 235 +----------------------------------//-----+ 236 < Original IPv4 Packet > 237 | 238 |(Encapsulation on ingress PE) 239 | 240 v 241 < Tunnel IPv6 Headers > < Original IPv4 Packet > 242 +-----------+ - - - - - +-------------+-----------//--------------+ 243 | IPv6 | IPv6 | IPv4 | | 244 | | Extension | | Packet Payload | 245 | Header | Headers | Header | | 246 +-----------+ - - - - - +-------------+-----------//--------------+ 247 < Tunnel IPv6 Packet > 248 | 249 |(Decapsulation on egress PE) 250 | 251 v 252 +----------------------------------//-----+ 253 | IPv4 Header | Packet Payload | 254 +----------------------------------//-----+ 255 < Original IPv4 Packet > 257 Figure 3: Packet encapsulation and decapsulation on dual-stack 4over6 258 PE router 260 The encapsulation format to apply is IPv4 encapsulated in IPv6 as 261 outlined in [RFC2473]. 263 3.2. Encapsulation table 265 Each 4over6 PE router maintains an encapsulation table as depicted in 266 Figure 4. Each entry in the encapsulation table consists of an IPv4 267 prefix and its corresponding IPv6 address. The IPv4 prefix is a 268 particular network located in an IPv4 access island network. The 269 IPv6 address is the 4over6 virtual interface (VIF) address of the 270 4over6 PE router that the IPv4 prefix is reachable through. The 271 encapsulation table is built and maintained using local configuration 272 information and MP-BGP advertisements received from remote 4over6 PE 273 routers. 275 The 4over6 VIF is an IPv6 /128 address that is locally configured on 276 each 4over6 router. This address, as an ordinary global IPv6 277 address, must also be injected into the IPv6 IGP so that it is 278 reachable across the IPv6 backbone. 280 +-------------+------------------------+ 281 | IPv4 Prefix | IPv6 Advertising AFBR | 282 +-------------+------------------------+ 284 Figure 4: Encapsulation Table 286 When an IPv4 packet arrives at the ingress 4over6 PE router, a lookup 287 in the local IPv4 routing table will result in a pointer to the local 288 encapsulation table entry with the matching destination IPv4 prefix. 289 There is a corresponding IPv6 address in the encapsulation table. 290 The IPv4 packet is encapsulated in an IPv6 header. The source 291 address in the IPv6 header is the IPv6 VIF address of the local 292 4over6 PE router and the destination address is the IPv6 VIF address 293 of the remote 4over6 PE router contained in the local encapsulation 294 table. The packet is then subjected to normal IPv6 forwarding for 295 transport across the IPv6 backbone. 297 When the encapsulated packet arrives at the egress 4over6 PE router, 298 the IPv6 header is removed and the original IPv4 packet is forwarded 299 to the destination IPv4 network based on the outcome of the lookup in 300 the IPv4 routing table contained in the egress 4over6 PE router. 302 3.3. MP-BGP 4over6 Protocol Extensions 304 Each 4over6 PE router possesses an IPv4 interface connected to an 305 IPv4 access network(s). It can peer with other IPv4 routers using 306 IGP or BGP routing protocols to exchange local IPv4 routing 307 information. Routing information can also be installed on the 4over6 308 PE router using static configuration methods. 310 Each 4over6 PE also possesses at least one IPv6 interface to connect 311 it into the IPv6 transit backbone. The 4over6 PE typically uses IGP 312 routing protocols to exchange IPv6 backbone routing information with 313 other IPv6 P routers. The 4over6 PE router will also form an MP-iBGP 314 peering relationship with other 4over6 PE routers connected to the 315 IPv6 backbone network. 317 The use of MP-iBGP suggests that the participating 4over6 PE routers 318 that share a route reflector or form a full mesh of TCP connections 319 are contained in the same autonomous system (AS). This 320 implementation is in fact only deployed over a single AS. This was 321 not an intentional design constraint but rather reflected the single 322 AS topology of the CNGI-CERNET2 national IPv6 backbone used in the 323 testing and deployment of this solution. 325 3.3.1. Receiving Routing Information from Local CE 327 When a 4over6 PE router learns routing information from the locally 328 attached IPv4 access networks, the 4over6 MP-iBGP entity should 329 process the information as follows: 331 1. Install and maintain local IPv4 routing information in the IPv4 332 routing database. 334 2. Install and maintain new entries in encapsulation table. Each 335 entry should consist of the IPv4 prefix and the local IPv6 VIF 336 address. 338 3. Advertise the new contents of the local encapsulation table in 339 the form of MP_REACH_NLRI update information to remote 4over6 PE 340 routers. The format of these updates is as follows: 342 * AFI = 1 (IPv4) 344 * SAFI = 67 (4OVER6) 346 * NLRI = IPv4 network prefix 348 * Network Address of Next Hop = IPv6 address of its 4over6 VIF 350 4. A new SAFI for this solution was obtained as SAFI_4OVER6 (67) 351 from IANA. We call BGP update with SAFI being 67 as 4over6 352 routing information. 354 3.3.2. Receiving 4over6 Routing Information from a remote 4over6 PE 356 A local 4over6 PE router will receive MP_REACH_NLRI updates from 357 remote 4over6 routers and use that information to populate the local 358 encapsulation table and the BGP routing database. After validating 359 correctness of the received attribute, the following procedures are 360 used to update the local encapsulation table and redistribute to 361 local IPv4 routing table: 363 1. Validate the received BGP update packet as 4over6 routing 364 information by AFI = 1 (IPv4) and SAFI = 67 (4OVER6) 366 2. Extract the IPv4 network address from the NLRI field and install 367 as the IPv4 network prefix 369 3. Extract the IPv6 address from the Network Address of the Next Hop 370 field and place that as an associated entry next to the IPv4 371 network index. (Note this describes the update of local encap 372 table.) 374 4. Install and maintain a new entry in encapsulation table with the 375 extracted IPv4 prefix and its corresponding IPv6 address. 377 5. Redistribute the new 4over6 routing information to local IPv4 378 routing table. Set the destination network prefix as the 379 extracted IPv4 prefix, set the Next Hop as Null, and Set the 380 OUTPUT Interface as the 4over6 VIF on the local 4over6 PE router. 382 Therefore, when an ingress 4over6 PE router receives an IPv4 packet, 383 the lookup in its IPv4 routing table will have a result of the output 384 interface as the local 4over6 VIF, where the incoming IPv4 packet 385 will be encapsulated with a new IPv6 header as indicated in the 386 encapsulation table. 388 4. 4over6 Deployment Experience 390 4.1. CNGI-CERNET2 392 A prototype of the 4over6 solution is implemented and deployed on 393 CNGI-CERNET2. CNGI-CERNET2 is one of the China Next Generation 394 Internet (CNGI) backbones, operated by the China Education and 395 Research Network (CERNET). CNGI-CERNET2 connects approximately 25 396 core nodes distributed in 20 cities in China at speeds of 2.5-10 397 Gb/s. The CNGI-CERNET2 backbone is IPv6-only with some attached 398 customer premise networks (CPN) being dual-stack. The CNGI-CERNET2 399 backbone, attached CNGI-CERNET2 CPNs, and CNGI-6IX Exchange all have 400 globally unique AS numbers. This IPv6 backbone is used to provide 401 transit IPv4 services for customer IPv4 networks connected via 4over6 402 PE routers to the backbone. 404 4.2. 4over6 Testbed on the CNGI-CERNET2 IPv6 Network 406 Figure 5 shows 4over6 deployment network topology. 408 +-----------------------------------------------------+ 409 | IPv6 (CERNET2) | 410 | | 411 +-----------------------------------------------------+ 412 | | | | 413 Tsinghua|Univ. Peking|Univ. SJTU| Southeast|Univ. 414 +------+ +------+ +------+ +------+ 415 |4over6| ... |4over6| |4over6| ... |4over6| 416 |router| |router| |router| |router| 417 +------+ +------+ +------+ +------+ 418 | | | | 419 | | | | 420 | | | | 421 +-----------+ +-----------+ +-----------+ +-----------+ 422 |IPv4 access| ... |IPv4 access| |IPv4 access| ... |IPv4 access| 423 | network | | network | | network | | network | 424 +-----------+ +-----------+ +-----------+ +-----------+ 425 | 426 +----------------------+ 427 | IPv4 (Internet) | 428 | | 429 +----------------------+ 431 Figure 5: 4over6 deployment network topology 433 The IPv4-only access networks are equipped with servers and clients 434 running different applications. The 4over6 PE routers are deployed 435 at 8 x IPv6 nodes of CNGI-CERNET2, located in 7 universities and 5 436 cities across China. As suggested in figure 5 some of the IPv4 437 access networks are connected to both IPv6 and IPv4 networks and 438 others are only connected to the IPv6 backbone. In the deployment, 439 users in different IPv4 networks can communicate with each other 440 through 4over6 tunnels. 442 4.3. Deployment Experiences 444 A number of 4over6 PE routers were deployed and configured to support 445 the 4over6 transit solution. MP-BGP peerings were established, and 446 successful distribution of 4over6 SAFI information occured. 447 Inspection of the BGP routing and encapsulation tables confirmed that 448 the correct entries were sent and received. ICMP ping traffic 449 indicated that IPv4 packets were successfully transiting the IPv6 450 backbone. 452 In addition other application protocols were successfully tested per 453 the following: 455 o HTTP. A client running Internet Explorer in one IPv4 client 456 network was able to access and download multiple objects from an 457 HTTP server located in another IPv4 client network. 459 o P2P. BitComet software running on several PCs placed in different 460 IPv4 client networks were able to find each other and share files. 462 Other protocols, including FTP, SSH, IM(MSN, GTalk) and Multimedia 463 Streaming, all functioned correctly. 465 5. On-going Experiment 467 Based on the above successful experiment, we are going to have 468 further experiments in the following two aspects. 470 1. Inter-AS 4over6 472 The above experiment is only deployed over a single AS. With the 473 growth of the network, there could be multiple ASes between the edge 474 networks. Specifically, the next-hop field in MP-BGP indicates the 475 tunnel end point in the current 4over6 techonology. However, in the 476 inter-AS scenario, the tunnel end point needs to be seperated from 477 the field of next hop. Moreover, since the technology of 4over6 is 478 deployed on the router running MP-BGP, the supportability of 4over6 479 on each ASBR will be a main concern in the Inter-AS experiment. We 480 may consider different situations: (1) Some of ASBRs do not support 481 4over6; (2) ASBRs only support 4over6 control plane (i.e. MP-BGP 482 extension of 4over6) rather than 4over6 data plane; (3) ASBRs support 483 both the control plane and the data plane for 4over6. 485 2. Multicast 4over6 487 The current 4over6 technology only supports unicast routing and data 488 forwarding. With the deployment of network-layer multicast in 489 multiple IPv4 edge networks, we need to extend the 4over6 technology 490 to support multicast including both multicast tree manipulation on 491 the control plane and multicast traffic forwarding on the data plane. 492 Based on the current unicast 4over6 technology providing the unicast 493 connectivity of edge networks over the backbone in another address 494 family, the multicast 4over6 will focus on the mapping technologies 495 between the multicast groups in the different address families. 497 6. Relationship to Softwires Mesh Effort 499 The 4over6 solution was presented at the IETF Softwires Working Group 500 Interim meeting in Hong Kong in January 2006. The existence of this 501 large- scale implementation and deployment clearly showed that MP-BGP 502 could be employed to support tunnel setup in a scalable fashion 503 across an IPv6 backbone. Perhaps most important was the use-case 504 presented, that being an IPv6 backbone offering transit to attached 505 client IPv4 networks. 507 The 4over6 solution can be viewed as a precursor to softwires mesh 508 framework proposed to the softwire problem statement [RFC4925]. 509 However there are several differences with this solution and the 510 effort that emerged from the softwires working group called softwires 511 mesh framework [RFC5565] and the related solutions [RFC5512] 512 [RFC5549]. 514 o MP-BGP Extensions. 4over6 employs a new SAFI (4OVER6) to convey 515 client IPv4 prefixes between 4over6 PE routers. Softwires Mesh 516 retains original AFI-SAFI designations but uses a modified 517 MP_REACH_NLRI format to convey IPv4 NLRI prefix information with 518 an IPv6 next_hop address [RFC5549]. 520 o Encapsulation. 4over6 assumes IP-in-IP or it is possible to 521 configure GRE. Softwires uses those two scenarios configured 522 locally or for IP headers that require dynamic updating. As a 523 result, the BGP encap safi is introduced in Softwires [RFC5512]. 525 o Multicast. The basic 4over6 solution only implemented unicast 526 communications. The multicast communications is specified in the 527 Softwire Mesh Framework, and also supported by the multicast 528 extension of 4over6. 530 o Use-Cases. The 4over6 solution in this document specifies the 531 4over6 use-case, which is also pretty easy to extend for the use- 532 case of 6over4. The softwires mesh framework supports both 4over6 533 and 6over4. 535 7. IANA Considerations 537 A new SAFI value (67) was assigned by IANA for 4over6 BGP extension: 538 SAFI_4OVER6. 540 8. Security Considerations 542 Tunneling mechanisms, especially automatic ones, often have potential 543 problems of DDoS attacks on the tunnel-entry point or tunnel-end 544 point. As the advantage, 4over6 BGP extension don't allocate 545 resources to a single flow or maintain the state for a flow. 546 However, since the IPv6 tunnel endpoints are globally reachable IPv6 547 addresses, it would be trivial to spoof IPv4 packets by encapsulating 548 and sending them over IPv6 to the tunnel interface. This could 549 bypass IPv4 RPF or other antispoofing techniques. Also, any IPv4 550 filters may be bypassed. 552 I-BGP peering relationship may be maintained over IPSec or other 553 secure communications. 555 9. Conclusion 557 The emerging and growing deployment of IPv6 networks, in particular 558 IPv6 backbone networks, will introduce cases where connectivity with 559 IPv4 networks is desired. Some IPv6 backbones will need to offer 560 transit services to attached IPv4 access networks. The 4over6 561 solution outlined in this document supports such a capability through 562 an extension to MP-BGP to convey IPv4 routing information along with 563 an associated IPv6 address. Basic IP encapsulation is used in the 564 dataplane as IPv4 packets are tunneled through the IPv6 backbone. 566 An actual implemention has been developed and deployed on the CNGI- 567 CERNET2 IPv6 backbone. 569 10. Acknowledgements 571 During the design procedure of the 4over6 framework and definition of 572 BGP-MP 4over6 extension, Professor Ke Xu gave the authors many 573 valuable comments. The support of IETF softwire WG is also 574 gratefully acknowledged with special thanks to David Ward, Alain 575 Durand and Mark Townsley for their rich experience and knowledge in 576 this field. Yakov Rekhter provided helpful comments and advice. 577 Mark Townsley reviewed this document carefully and gave the authors a 578 lot of valuable comments, which are very important for improving this 579 document. 581 The deployment and test for the prototype system was conducted among 582 7 universities -- namely, Tsinghua University, Peking University, 583 Beijing University of Post and Telecommunications, Shanghai Jiaotong 584 University, Huazhong University of Science and Technology, Southeast 585 University, South China University of Technology. The authors would 586 like to thank everyone involved in this effort in these universities. 588 11. Normative References 590 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 591 IPv6 Specification", RFC 2473, December 1998. 593 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 594 Protocol 4 (BGP-4)", RFC 4271, January 2006. 596 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 597 "Multiprotocol Extensions for BGP-4", RFC 4760, 598 January 2007. 600 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 601 Problem Statement", RFC 4925, July 2007. 603 [RFC5512] Mohapatra, P. and E. Rosen, "The BGP Encapsulation 604 Subsequent Address Family Identifier (SAFI) and the BGP 605 Tunnel Encapsulation Attribute", RFC 5512, April 2009. 607 [RFC5549] Le Faucheur, F. and E. Rosen, "Advertising IPv4 Network 608 Layer Reachability Information with an IPv6 Next Hop", 609 RFC 5549, May 2009. 611 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 612 Framework", RFC 5565, June 2009. 614 Authors' Addresses 616 Jianping Wu 617 Tsinghua University 618 Department of Computer Science, Tsinghua University 619 Beijing 100084 620 P.R.China 622 Phone: +86-10-6278-5983 623 Email: jianping@cernet.edu.cn 625 Yong Cui 626 Tsinghua University 627 Department of Computer Science, Tsinghua University 628 Beijing 100084 629 P.R.China 631 Phone: +86-10-6278-5822 632 Email: cy@csnet1.cs.tsinghua.edu.cn 634 Xing Li 635 Tsinghua University 636 Department of Electronic Engineering, Tsinghua University 637 Beijing 100084 638 P.R.China 640 Phone: +86-10-6278-5983 641 Email: xing@cernet.edu.cn 643 Mingwei Xu 644 Tsinghua University 645 Department of Computer Science, Tsinghua University 646 Beijing 100084 647 P.R.China 649 Phone: +86-10-6278-5822 650 Email: xmw@csnet1.cs.tsinghua.edu.cn 651 Chris Metz 652 Cisco Systems, Inc. 653 3700 Cisco Way 654 San Jose, Ca. 95134 655 USA 657 Email: chmetz@cisco.com