idnits 2.17.1 draft-cui-pet-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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 4 longer pages, the longest (page 14) being 80 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** 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.) ** There are 83 instances of too long lines in the document, the longest one being 13 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 130 has weird spacing: '...eristic of di...' == Line 627 has weird spacing: '... is an backb...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 2, 2009) is 5405 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: 'RFC 2765' is mentioned on line 633, but not defined ** Obsolete undefined reference: RFC 2765 (Obsoleted by RFC 6145) == Missing Reference: 'RFC 2766' is mentioned on line 102, but not defined ** Obsolete undefined reference: RFC 2766 (Obsoleted by RFC 4966) == Missing Reference: 'RFC 2767' is mentioned on line 634, but not defined ** Obsolete undefined reference: RFC 2767 (Obsoleted by RFC 6535) == Missing Reference: 'RFC 3089' is mentioned on line 634, but not defined == Missing Reference: 'RFC 3338' is mentioned on line 634, but not defined ** Obsolete undefined reference: RFC 3338 (Obsoleted by RFC 6535) == Missing Reference: 'RFC 2893' is mentioned on line 636, but not defined ** Obsolete undefined reference: RFC 2893 (Obsoleted by RFC 4213) == Missing Reference: 'RFC 4213' is mentioned on line 635, but not defined == Missing Reference: 'RFC 1702' is mentioned on line 636, but not defined == Missing Reference: 'RFC 2529' is mentioned on line 112, but not defined == Missing Reference: 'RFC 5565' is mentioned on line 637, but not defined == Missing Reference: 'RFC2119' is mentioned on line 153, but not defined == Unused Reference: 'RFC2765' is defined on line 647, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 650, but no explicit reference was found in the text == Unused Reference: 'RFC2767' is defined on line 653, but no explicit reference was found in the text == Unused Reference: 'RFC3089' is defined on line 657, but no explicit reference was found in the text == Unused Reference: 'RFC3338' is defined on line 660, but no explicit reference was found in the text == Unused Reference: 'RFC2893' is defined on line 673, but no explicit reference was found in the text == Unused Reference: 'RFC4213' is defined on line 667, but no explicit reference was found in the text == Unused Reference: 'RFC1702' is defined on line 670, but no explicit reference was found in the text == Unused Reference: 'RFC2529' is defined on line 676, but no explicit reference was found in the text == Unused Reference: 'RFC5565' is defined on line 679, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2767 (Obsoleted by RFC 6535) ** Downref: Normative reference to an Informational RFC: RFC 3089 ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 1702 Summary: 16 errors (**), 0 flaws (~~), 26 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 softwire Working Group Y.Cui 2 Internet-Draft M. Xu 3 Intended status: Standards Track S.Wang 4 Expires: January 1, 2010 X.Li 5 J.Wu 6 Tsinghua University 7 Chris Metz 8 cisco systems 9 July 2, 2009 11 PET-based solution for IPv4/IPv6 coexistence 12 draft-cui-pet-00.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that 21 other groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 1, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 48 IPv6 offers significant advantages over IPv4, however it will take 49 long time to replace IPv4 with IPv6. Therefore, these two protocols are 50 expected to coexist during the transition period. Currently, there are 51 many transition devices deployed to solve transition problems. Most of 52 them only use one technology (either translation or tunneling). However, 53 any transition technology has limitation and application scope. In 54 transition scenarios, besides IP version of source, middle and destination 55 network, the network characteristic (a regular edge network or a backbone) 56 has key impact on system performance of transition methods. Therefore, we 57 need to decide which transition method should be used in some typical 58 transition scenarios and how the transition and tunneling devices 59 collaborate for solving transition problems. This draft introduces a smart 60 toolbox named PET (shortfor Prefixing, encapsulation and translation) which 61 includes all fundamental elements needed in all transition scenarios, such 62 as the control and data plane operations of tunneling and translation. 63 Based on PET, we propose a network side transition solution. In this framework, 64 there deploys only one kind of transition device, i.e. PET. Through the 65 collaboration of PETs, the transition problems can be solved. In this draft, 66 we give the advantages and disadvantages of all transition methods PET may adopt 67 according to IP version of source, middle and destination network, and the 68 network characteristic. 70 Table of Contents 72 1. Introduction................................................2 73 2. Requirements Terminology....................................3 74 3. Fundamental requirements of IPv4-IPv6 transition methods....3 75 4. Descriptions of PET.........................................8 76 5. PET Framework...............................................9 77 5.1. IPv4-IPv6-IPv4........................................11 78 5.2. IPv4-IPv6-IPv6........................................12 79 5.3. IPv6-IPv6-IPv4........................................13 80 5.4. IPv6-IPv4-IPv6........................................16 81 5.5. IPv4-IPv4-IPv6........................................16 82 5.6. IPv6-IPv4-IPv4........................................18 83 6. Implementation issues......................................19 84 7. References.................................................20 85 7.1. Normative References..................................20 86 7.2. Informative References................................20 87 Author's Addresses............................................21 89 1. Introduction 91 Recently more and more IPv6 networks have been deployed, especially 92 IPv6 backbone networks, while the existing IPv4 networks still carry 93 the major network traffic and hold the major network services and 94 applications, though facing serious address space problem and other 95 problems. It has been agreed that IPv4 and IPv6 networks will co- 96 exist for a long term. This leads to the need of IPv4-IPv6 transition 97 methods. 99 There are many methods for IPv4-IPv6 transition, which can be roughly 100 classified into two groups: translation and tunneling. Translation is 101 a technology that translates emantic between IPv4 and IPv6. There are 102 many translation methods, such as SIIT [RFC 2765], NAT-PT [RFC 2766], 103 BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], IVI [draft-ietf-xli 104 -behave-ivi-02] and so on. Translation technology can realize IPv4 105 and IPv6 interworking directly, however, it will lead to information 106 loss. 108 Tunneling is a technology to encapsulate packets from a different 109 protocol within the protocol of the route that delivers it to the 110 target network. There are many tunneling methods, such as IP-in-IP 111 tunnel [RFC 2893, RFC 4213], GRE tunnel [RFC 1702], 6to4 tunnel 112 [RFC 2893], 6over4 tunnel [RFC 2529], softwire transition technology 113 [RFC 5565] and so on. Tunneling technology can not realize the IPv4 and 114 IPv6 interworking directly. It can only deal with the scenario where 115 two IPv4 (IPv6) nodes want to communicate with each other through 116 IPv6 (IPv4) network. However, tunneling technology has several 117 advantages, besides no information loss, it can be realized 118 easily by hardware, and does not introduce routing information 119 into a network with different address family. 121 Differnt transition methods need differnt transition devices, which 122 may produced by differnt device providers. It is hard for these 123 hetero-devices to collaberate for solving transition probelm. In addition, 124 there exit some transition scenarios where both translation and 125 tunneling technologies are needed. Moreover, in this case, using 126 translation first or tunneling first has important impact on system 127 performance due to their application scope and limitation. In current 128 transition framework, the transition method that the network adopts depends 129 on the transition devices the packets met, which cannot take advantage of 130 the characteristic of different transition technologies. Hence, it is 131 necessary to build a mechanism to decide where and when to use tunneling 132 or translation according to IP version of source, middle and destination 133 network, as well as the network characteristic (a regular edge network or 134 a backbone). 136 Aiming to the above probelms, this draft presents an IPv4-IPv6 transition 137 framework, which is a network side transition solution. It introduces a 138 toolbox named PET (short for Prefixing, encapsulation and translation) to 139 solve IPv4-IPv6 transition. PET includes all fundamental elements needed in 140 transition scenarios, which provides the flexibility for network to decide 141 the proper transition methods according to IP version of source, middle and 142 destination network as well as the network characteristic. In addition, the 143 PET-based transition framework makes network only need one kind of transition 144 device, which brings conveniences to consititue the transition policies. 145 This draft also addresses how to deploy PETs and analyze the advantages and 146 disadvantages of all transition methods that PET may adopt. 148 2. Requirements Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", 151 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 152 interpreted as described in [RFC2119]. 154 3. Fundamental requirements of IPv4-IPv6 transition methods 155 There are two main IPv4-IPv6 transition scenarios. One is to 156 connect several edge networks with the same address family across a 157 transit core network with another address family; the other scenario 158 is to make hosts with one address family capable of directly 159 communicating with hosts with the other address family. We call the 160 first scenario heterogeneous crossing. The scenario where two IPv4 (IPv6) nodes 161 want to communicate with each other through IPv6 (IPv4) network 162 belongs to heterogeneous crossing (see figures 1 and 2). We call the 163 second scenario heterogeneous direct-connection. The scenario 164 where an IPv4 (IPv6) node wants to directly communicate with an IPv6 165 (IPv4) node belongs to heterogeneous direct-connection, (see figure 3 166 and 4). 168 +--------+ +--------+ 169 | IPv6 | | IPv6 | 170 | Client | | Client | 171 | Network| | Network| 172 +--------+ +--------+ 173 | | | | 174 | | | | 175 +--------+ +--------+ 176 | AFBR | | AFBR | 177 +--| IPv4/6 |---| IPv4/6 |--+ 178 | +--------+ +--------+ | 179 +--------+ | | +--------+ 180 | IPv4 | | | | IPv4 | 181 | Client | | | | Client | 182 | Network|------| IPv4 |-------| Network| 183 +--------+ | only | +--------+ 184 | | 185 | +--------+ +--------+ | 186 +--| AFBR |---| AFBR |--+ 187 | IPv4/6 | | IPv4/6 | 188 +--------+ +--------+ 189 | | | | 190 | | | | 191 +--------+ +--------+ 192 | IPv6 | | IPv6 | 193 | Client | | Client | 194 | Network| | Network| 195 +--------+ +--------+ 197 Figure 1: IPv6-over-IPv4 Scenario 199 +--------+ +--------+ 200 | IPv4 | | IPv4 | 201 | Client | | Client | 202 | Network| | Network| 203 +--------+ +--------+ 204 | \ / | 205 | \ / | 206 | \ / | 207 | X | 208 | / \ | 209 | / \ | 210 | / \ | 211 +--------+ +--------+ 212 | AFBR | | AFBR | 213 +--| IPv4/6 |---| IPv4/6 |--+ 214 | +--------+ +--------+ | 215 +--------+ | | +--------+ 216 | IPv6 | | | | IPv6 | 217 | Client | | | | Client | 218 | Network|------| IPv6 |-------| Network| 219 +--------+ | only | +--------+ 220 | | 221 | +--------+ +--------+ | 222 +--| AFBR |---| AFBR |--+ 223 | IPv4/6 | | IPv4/6 | 224 +--------+ +--------+ 225 | \ / | 226 | \ / | 227 | \ / | 228 | X | 229 | / \ | 230 | / \ | 231 | / \ | 232 +--------+ +--------+ 233 | IPv4 | | IPv4 | 234 | Client | | Client | 235 | Network| | Network| 236 +--------+ +--------+ 238 Figure 2: IPv4-over-IPv6 Scenario 240 +--------+ +--------+ 241 | IPv4 | | IPv6 | 242 | |---| | 243 | Network| | Network| 244 +--------+ +--------+ 246 Figure 3: IPv4-IPv6 scenario 248 +--------+ +--------+ 249 | IPv6 | | IPv4 | 250 | |---| | 251 | Network| | Network| 252 +--------+ +--------+ 254 Figure 4: IPv6-IPv4 scenario 256 In fact, all IPv4-IPv6 transition scenarios can be viewed as the 257 combination of heterogeneous crossing and direct-connection. Hence, 258 the fundamental transition elements needed in heterogeneous crossing 259 and direct-connection are those needed in all IPv4-IPv6 transition 260 scenarios. 262 In heterogeneous crossing scenario, tunneling technology can be 263 used to transmit IPv4 (IPv6) packets through IPv6 (IPv4) networks. In 264 addition, through twice translations, IPv4 (IPv6) packets can also be 265 transmitted through IPv6 (IPv4) networks in heterogeneous crossing 266 scenario. In heterogeneous direct-connection scenario, when IPv4 267 (IPv6) nodes want to communicate with IPv6 (IPv4) nodes directly, it 268 can only use translation technology. 270 In addition, when adopting tunneling for supporting IPv4/IPv6 271 inter-working, some control operations involved with subnet prefix 272 should be done beforehand. Theses operations include prefix 273 announcement, tunnel endpoint discovery, the selection of tunnel 274 endpoint and tunnel belonging to the same tunnel endpoint, tunnel 275 configuration, and so on. Similarly, when adopting translation method 276 for supporting IPv4/IPv6 inter-working, some control operations 277 involved with subnet prefix also should be done beforehand. These 278 operations include the establishment of address mapping mechanism, 279 prefix configuration and so on. We call these control operations 280 involved with subnet prefix prefixing. 282 In conclusion, there are three fundamental elements needed in all 283 IPv4-IPv6 transition scenarios, i.e. prefixing, encapsulation and 284 translation. 286 To realize a generic solution in network side for IPv4/IPv6 287 translation, this draft introduces a toolbox named PET which includes 288 the above fundamental elements. Its detailed descriptions are given 289 in section 4. 291 4. Descriptions of PET 292 PET is a smart transition toolbox supporting IPv4/IPv6 inter- 293 working. It can deal with the heterogeneous crossing and direct- 294 connection scenarios. Because all IPv4-IPv6 transition scenarios can 295 be viewed as the combination of the heterogeneous crossing and 296 direct-connection, the PET-based transition method is a generic 297 solution for IPv4/IPv6 transition. PET toolbox has the following 298 functions: 300 P: representing prefixing. Prefixing includes all transition 301 operations of control plane involved with subnet prefix. 303 In detail, in tunneling technology, prefixing includes prefix 304 announcement, tunnel endpoint discovery, the selection of tunnel 305 endpoint and tunnel belonging to the same tunnel endpoint, and so on. 306 For example, in softwire transition technology, the IPv6 prefix and 307 IPv4 next-hop mapping information should be announced out through 308 extended MP-BGP (Multi-protocol BGP) signaling beforehand. Based on 309 this prefixing operation, the auto 4over6 tunnels can be established. 311 In translation technology, prefixing includes the establishment of 312 address mapping mechanism, prefix configuration and so on. For 313 example, in IVI-based translation scheme, the global IPv6 prefix 314 should be configured in an autonomous domain (AS) beforehand, to form 315 the global IVI address, thus realizing the stateless translation. 317 E: representing encapsulation. E includes all tunneling operations 318 of data plane, such as encapsulation, decapsulation and maximum 319 transmission unit (MTU) processing and so on. 321 Through this operation, packets from IPv6 (IPv4) network are 322 encapsulated on the PET toolbox and sent across IPv4 (IPv6) backbone 323 to another IPv6 (IPv4) network according to the mappings stored on 324 the PET box. 326 T: representing translation. It includes all translation 327 operations of data plane, such as address mapping and protocol 328 translation, MTU processing. 330 Address mapping is to map IPv4 addresses to IPv6 addresses, and 331 vice versa. Based on address mapping, packets can be translated from 332 one address family to another. IPv4 and IPv6 are not directly 333 compatible, so programs and systems designed on one standard can not 334 communicate with those designed to the other. Hence we need protocol 335 translation. Here, protocol translation includes IP layer translation 336 and application layer translation. Through protocol translation, the 337 semantic of IP layer and application layer of an IPv4 packet is 338 equivalent with that of the translated IPv6 packet and vice versa. In 339 addition, to implement translation, PET may collaborate with the 340 domain name system (DNS). 342 The basic idea of our solution is to deploy several PET toolboxes 343 between backbone network and customer networks. The following section 344 will discuss how PET deals with different IPv4/IPv6 translation 345 scenarios in detail. 347 5. PET Framework 348 PET is an all-in-one solution for IPv4/IPv6 inter-working. 349 Basically, PET scheme integrates prefixing, translation and tunneling 350 schemes into one solution. Figure 5 shows the overall topology of PET 351 framework, which uses PET boxes between IPv6 backbone and IPv4 352 customer networks. In this topology, an IPv6 backbone is connected 353 with several customer networks including IPv4 backbone, IPv4 virtual 354 private networks (VPNs), IPv6 network and dual stack networks. 356 +------------------+ 357 | | 358 | IPv4 backbone | 359 | | 360 +------------------+ 361 | | 362 | | 363 | | 364 +--------+ +--------+ 365 | PET | | PET | 366 +--| |---| |--+ 367 | +--------+ +--------+ | 368 | | 369 +--------+ +--------+ +--------+ +-------+ 370 | IPv4 | | | IPv6 backbone | | | IPv4 | 371 |network |___| PET | | PET |__|network| 372 | | | | | | | | 373 | | +--------+ +--------+ | | 374 +--------+ | | +-------+ 375 | | 376 | +--------+ +--------+ | 377 +--| PET |---| PET |--+ 378 | | | | 379 +--------+ +--------+ 380 | \ / | 381 | \ / | 382 | \ / | 383 | X | 384 | / \ | 385 | / \ | 386 | / \ | 387 +--------+ +--------+ 388 | IPv6 | | IPv4/ | 389 | | | IPv6 | 390 | Network| | Network| 391 +--------+ +--------+ 393 Figure 5: Topology of PET Framework 395 For different transition scenarios, PET can provide different 396 functionalities to ensure the interworking of IPv4/IPv6 network. We 397 will analyze how PET works in all scenarios in the following 398 subsections. 400 5.1. IPv4-IPv6-IPv4 402 This is the scenario where an IPv4 network wants to talk with 403 another IPv4 network across IPv6 backbone. There are two methods for 404 PET to handle this scenario. One is translation and the other is 405 tunneling. If PET adopts translation method, we need twice 406 translations. In detail, an IPv4 packet need be translated by PET 407 into an IPv6 packet for being delivered through IPv6 backbone. When 408 this packet arrives at another PET, it will be translated into an IPv4 409 packet again for being delivered through IPv4 network. 411 The other method for IPv4-IPv6-IPv4 scenario is tunneling. This 412 requires a PET to encapsulate the packets and sent them to the tunnel 413 endpoint PET across IPv6 backbone. When these packets arrive at the 414 tunnel endpoint PET,they are de-capsulated and sent to IPv4 customer 415 networks. 417 Because translation method will incur information loss, PET 418 prefers to use tunneling technology to handle IPv4-IPv6-IPv4 scenario. 419 Its operations are shown in Fig.6. 421 +-------------+ +-------------+ +-------------+ +-------------+ 422 |IPv4 customer| | PET | | PET | |IPv4 customer| 423 | network | | | | | | network | 424 +-------------+ +-------------+ +-------------+ +-------------+ 425 | | | | 426 |--------pkt----->| | | 427 | encapsulation | | 428 | | | | 429 | |-------tunneling--->| | 430 | | | | 431 | | | | 432 | | decapsulation | 433 | | |-------pkt------->| 434 | | | | 436 Figure 6 : PET operations in IPv4-IPv6-IPv4 scenario 438 5.2. IPv4-IPv6-IPv6 440 This is the scenario where an IPv4 customer network wants to talk 441 with an IPv6 customer network across IPv6 backbone. There are two 442 methods to deal with this scenario. One is translation plus 443 forwarding. The other is tunneling plus translation. 445 In the first method, when an IPv4 packet arrives at PET, it will 446 be translated into an IPv6 packet and then sent to the IPv6 network 447 through IPv6 backbone. In the second method, when an IPv4 packet 448 arrives at PET, it will be encapsulated as an IPv6 packet for being 449 delivered through IPv6 backbone. Once this packet arrives at the 450 tunnel endpoint PET, it will be decapsulated to the original IPv4 451 packet and then be translated as an IPv6 packet to deliver to the 452 IPv6 customer network. 454 If the IPv4 customer network is not an IPv4 backbone, PET prefers to 455 adopt the first method because this complexity of second method is higher 456 than that of the first method. Its operation is shown in Fig.7. 458 +-------------+ +-------------+ +-------------+ +-------------+ 459 |IPv4 customer| | PET | | PET | |IPv6 customer| 460 | network | | | | | | network | 461 +-------------+ +-------------+ +-------------+ +-------------+ 462 | | | | 463 |--------pkt----->| | | 464 | translation | | 465 | | | | 466 | |------forwarding--->| | 467 | | | | 468 | | | | 469 | | | | 470 | | |-------pkt------->| 471 | | | | 473 Figure 7 : PET operations in IPv4-IPv6-IPv6 scenario (IPv4 customer network 474 is not an IPv4 backbone) 476 If the IPv4 customer network is an backbone, PET prefers to adopt the 477 second method for the following reasons: 478 i)Translation mechanism usually needs application level gateway 479 (ALG), which is an application specific agent that allows an 480 IPv6 node to communicate with an IPv4 node and vice versa. 481 Backbone network requires hardware forwarding for high speed 482 transmission. However, it is hard to use hardware to do the work 483 of ALG. 484 ii)To avoid single point of failure, several PETs usually be 485 deployed among networks. They improve performance and robustness 486 using dynamic routing mechanisms. However, translation is a 487 static process. It is hard to use dynamic routing mechanism. 488 iii)At last, some translation mechanisms, such as IVI-based scheme, 489 requires IPv4 routing information introducing to IPv6 backbone, 490 which will increase the routing base size. 491 Based on the above analyses, PET refers to adopt the second method 492 to deal with this scenario. Its operations are shown in Fig.8. 493 +-------------+ +-------------+ +-------------+ +-------------+ 494 |IPv4 customer| | PET | | PET | |IPv6 customer| 495 | network | | | | | | network | 496 +-------------+ +-------------+ +-------------+ +-------------+ 497 | | | | 498 |--------pkt----->| | | 499 | | | | 500 | encapsulation | | 501 | |------tunneling---->| | 502 | | | | 503 | | | | 504 | | decapsulation | 505 | | translation | 506 | | |-------pkt------->| 507 | | | | 508 Figure 8: PET operations in IPv4-IPv6-IPv6 scenario (IPv4 customer network 509 is an IPv4 backbone) 511 5.3. IPv6-IPv6-IPv4 513 This is the scenario where an IPv6 customer network wants to talk 514 with an IPv4 customer network across IPv6 backbone. In this senario, 515 when an IPv6 packet arrives at PET, it will be translated as an IPv4 516 packet and then the PET encapsulates it and sent it to the tunnel 517 endpoint PET. When the translated IPv4 packet arrives at the tunnel 518 endpoint PET, it will be decapsulated and sent to the IPv4 customer 519 network. The operations are shown in Fig.9. 521 +-------------+ +-------------+ +-------------+ +-------------+ 522 |IPv6 customer| | PET | | PET | |IPv4 customer| 523 | network | | | | | | network | 524 +-------------+ +-------------+ +-------------+ +-------------+ 525 | | | | 526 |--------pkt----->| | | 527 | translation | | 528 | encapsulation | | 529 | |------tunneling---->| | 530 | | | | 531 | | | | 532 | | | | 533 | | decapsulation | 534 | | |-------pkt------->| 535 | | | | 536 Figure 9 : PET operations in IPv6-IPv6-IPv4 scenario 538 5.4. IPv6-IPv4-IPv6 540 This is the scenario where an IPv6 network wants to talk with 541 another IPv6 network across IPv4 backbone. This scenario is similar 542 to IPv4-IPv6-IPv4 scenario. Hence, PET prefers to use tunneling 543 technology to handle this scenario. Its operations are shown in 544 Fig.10. 546 +-------------+ +-------------+ +-------------+ +-------------+ 547 |IPv6 customer| | PET | | PET | |IPv6 customer| 548 | network | | | | | | network | 549 +-------------+ +-------------+ +-------------+ +-------------+ 550 | | | | 551 |--------pkt----->| | | 552 | encapsulation | | 553 | |------tunneling---->| | 554 | | | | 555 | | | | 556 | | decapsulation | 557 | | |-------pkt------->| 558 | | | | 560 Figure 10 : PET operations in IPv6-IPv4-IPv6 scenario 562 5.5. IPv4-IPv4-IPv6 564 This is the scenario where an IPv4 customer network wants to talk 565 with an IPv6 customer network across IPv4 backbone. This scenario is 566 similar to IPv6-IPv6-IPv4 scenario. Hence, PET adopts the similar 567 method to deal with this scenario. Its operations are shown in 568 Figs.11. 569 +-------------+ +-------------+ +-------------+ +-------------+ 570 |IPv4 customer| | PET | | PET | |IPv6 customer| 571 | network | | | | | | network | 572 +-------------+ +-------------+ +-------------+ +-------------+ 573 | | | | 574 |--------pkt----->| | | 575 | translation | | 576 | encapsulation | | 577 | |------tunneling---->| | 578 | | | | 579 | | | | 580 | | | | 581 | | decapsulation | 582 | | |-------pkt------->| 583 | | | | 584 Figure 11 : PET operations in IPv4-IPv4-IPv6 scenario 586 5.6. IPv6-IPv4-IPv4 588 This is the scenario where an IPv6 customer network wants to talk 589 with an IPv4 customer network across IPv4 backbone. This scenario is 590 similar to IPv4-IPv6-IPv6 scenario. Hence, PET adopts the similar 591 method to deal with this scenario. Its operations are shown in Fig.12 592 and Fig.13. 593 +-------------+ +-------------+ +-------------+ +-------------+ 594 |IPv6 customer| | PET | | PET | |IPv4 customer| 595 | network | | | | | | network | 596 +-------------+ +-------------+ +-------------+ +-------------+ 597 | | | | 598 |--------pkt----->| | | 599 | translation | | 600 | | | | 601 | |------forwarding--->| | 602 | | | | 603 | | | | 604 | | | | 605 | | |-------pkt------->| 606 | | | | 608 Figure 12 : PET operations in IPv6-IPv4-IPv4 scenario (IPv6 customer network 609 is not a backbone) 611 +-------------+ +-------------+ +-------------+ +-------------+ 612 |IPv6 customer| | PET | | PET | |IPv4 customer| 613 | network | | | | | | network | 614 +-------------+ +-------------+ +-------------+ +-------------+ 615 | | | | 616 |--------pkt----->| | | 617 | | | | 618 | encapsulation | | 619 | |------tunneling---->| | 620 | | | | 621 | | | | 622 | | decapsulation | 623 | | translation | 624 | | |-------pkt------->| 625 | | | | 626 Figure 13: PET operations in IPv6-IPv4-IPv4 scenario (IPv6 customer network 627 is an backbone) 629 6. Implementation issues 630 In this draft, we recommend how to use tunneling and translation 631 method in each scenario using PETs. However, we do not restrict the 632 specific tunneling and translation technology that PET adopts. It can 633 be any transition technology, such as SIIT [RFC 2765], NAT-PT [RFC 634 2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], IVI 635 [draft-ietf-xli-behave-ivi-02],iP-in-IP tunnel [RFC 2893, RFC 4213], 636 GRE tunnel [RFC 1702], 6to4 tunnel [RFC 2893], 6over4 tunnel [RFC 637 2529], softwire transition technology [RFC 5565] and so on. 639 7. Acknowledgment 640 The authors would like to thank Lixia Zhang for her valuable commnets 641 on this draft. 643 8. References 645 8.1. Normative References 647 [RFC2765] E.Nordmark. "Stateless IP/ICMP Translation Algorithm 648 (SIIT)", RFC 2765, February 2000 650 [RFC2766] G. Tsirtsis, P. Srisuresh." Network Address Translation - 651 Protocol Translation (NAT-PT)", RFC 2766, February 2000 653 [RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi. "Dual Stack Hosts 654 using the "Bump-In-the-Stack" Technique (BIS)", RFC 2767, 655 February 2000 657 [RFC3089] H. Kitamura." A SOCKS-based IPv6/IPv4 Gateway Mechanism", 658 RFC 3089, April 2001 660 [RFC3338] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. Durand. "Dual 661 Stack Hosts Using "Bump-in-the-API" (BIA)", RFC 3338, 662 October 2002 664 [RFC2893] R. Gilligan, E. Nordmark. "Transition Mechanisms for IPv6 665 Hosts and Routers", RFC 2893, August 2000 667 [RFC4213] E. Nordmark, R. Gilligan. "Basic Transition Mechanisms for 668 IPv6 Hosts and Routers", RFC 4213, October 2005 670 [RFC1702] S. Hanks, T. Li, D. Farinacci, P. Traina." Generic Routing 671 Encapsulation over IPv4 networks", RFC 1702, October 1994 673 [RFC2893] R. Gilligan, E. Nordmark." Transition Mechanisms for IPv6 674 Hosts and Routers", RFC 2893, August 2000 676 [RFC2529] B. Carpenter, C. Jung." Transmission of IPv6 over IPv4 677 Domains without Explicit Tunnels", RFC2529, March 1999 679 [RFC5565] J. Wu, Y. Cui, C. Metz, E. Rosen. " Softwire Mesh 680 Framework", RFC 5565, June 2009 682 8.2. Informative References 684 [I-D. draft-ietf-xli-behave-ivi-02] 685 X. Li,C.Bao,M.Chen,H.Zhang,J.Wu." The CERNET IVI 686 Translation Design and Deployment for the IPv4/IPv6 687 Coexistence and Transition", Internet Draft, June 13, 2009 689 Author's Addresses 691 Yong Cui 692 Tsinghua University 693 Department of Computer Science, Tsinghua University 694 Beijing 100084 695 P.R.China 697 Phone: +86-10-6278-5822 698 Email: cuiyong@tsinghua.edu.cn 700 Mingwei Xu 701 Tsinghua University 702 Department of Computer Science, Tsinghua University 703 Beijing 100084 704 P.R.China 706 Phone: +86-10-6278-5822 707 Email: xmw@csnet1.cs.tsinghua.edu.cn 709 Shengling Wang 710 Tsinghua University 711 Department of Computer Science, Tsinghua University 712 Beijing 100084 713 P.R.China 715 Phone: +86-10-6278-5822 716 Email: slwang@csnet1.cs.tsinghua.edu.cn 718 Xing Li 719 Tsinghua University 720 CERNET Center, Tsinghua University 721 Beijing 100084 722 P.R.China 724 Phone: +86-10-6278-5983 725 Email: xing@cernet.edu.cn 726 Jianping Wu 727 Tsinghua University 728 CERNET Center, Tsinghua University 729 Beijing 100084 730 P.R.China 732 Phone: +86-10-6278-5983 733 Email: jianping@cernet.edu.cn 735 Chris Metz 736 cisco systems 737 170 West Tasman Drive 738 San Jose 95134-1706 739 CA 741 Email: chmetz@cisco.com