idnits 2.17.1 draft-cui-softwire-pet-framework-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 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 39 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 58 has weird spacing: '... should be u...' == Line 63 has weird spacing: '...ncludes funda...' == Line 66 has weird spacing: '...dresses how ...' == Line 132 has weird spacing: '...ncludes funda...' == Line 135 has weird spacing: '...dresses how ...' == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (July 2, 2009) is 5410 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) -- Looks like a reference, but probably isn't: 'RFC 2765' on line 523 -- Looks like a reference, but probably isn't: 'RFC 2767' on line 524 -- Looks like a reference, but probably isn't: 'RFC 3089' on line 524 -- Looks like a reference, but probably isn't: 'RFC 3338' on line 524 -- Looks like a reference, but probably isn't: 'RFC 2893' on line 526 -- Looks like a reference, but probably isn't: 'RFC 4213' on line 111 -- Looks like a reference, but probably isn't: 'RFC 1702' on line 526 -- Looks like a reference, but probably isn't: 'RFC 2529' on line 112 -- Looks like a reference, but probably isn't: 'RFC2119' on line 142 -- Looks like a reference, but probably isn't: 'RFC2766' on line 524 -- Looks like a reference, but probably isn't: 'RFC2529' on line 527 -- Looks like a reference, but probably isn't: 'RFC 5565' on line 527 == Unused Reference: '1' is defined on line 541, but no explicit reference was found in the text == Unused Reference: '2' is defined on line 544, but no explicit reference was found in the text == Unused Reference: '3' is defined on line 546, but no explicit reference was found in the text == Unused Reference: '4' is defined on line 550, but no explicit reference was found in the text == Unused Reference: '5' is defined on line 554, but no explicit reference was found in the text == Unused Reference: '6' is defined on line 557, but no explicit reference was found in the text == Unused Reference: '7' is defined on line 561, but no explicit reference was found in the text == Unused Reference: '8' is defined on line 564, but no explicit reference was found in the text == Unused Reference: '9' is defined on line 568, but no explicit reference was found in the text == Unused Reference: '10' is defined on line 572, but no explicit reference was found in the text == Unused Reference: '11' is defined on line 575, but no explicit reference was found in the text == Unused Reference: '12' is defined on line 578, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2765 (ref. '1') (Obsoleted by RFC 6145) -- Duplicate reference: RFC2765, mentioned in '2', was also mentioned in '1'. ** Obsolete normative reference: RFC 2765 (ref. '2') (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (ref. '3') (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 2767 (ref. '4') (Obsoleted by RFC 6535) ** Downref: Normative reference to an Informational RFC: RFC 3089 (ref. '5') ** Obsolete normative reference: RFC 3338 (ref. '6') (Obsoleted by RFC 6535) ** Obsolete normative reference: RFC 2893 (ref. '7') (Obsoleted by RFC 4213) ** Downref: Normative reference to an Informational RFC: RFC 1702 (ref. '9') -- Duplicate reference: RFC2893, mentioned in '10', was also mentioned in '7'. ** Obsolete normative reference: RFC 2893 (ref. '10') (Obsoleted by RFC 4213) Summary: 13 errors (**), 0 flaws (~~), 19 warnings (==), 15 comments (--). 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 10 PET-based framework for IPv4/IPv6 coexistence 11 draft-cui-softwire-pet-framework-00.txt 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet-Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 1, 2010. 35 Copyright Notice 37 Copyright (c) 2009 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents in effect on the date of 42 publication of this document (http://trustee.ietf.org/license-info). 43 Please review these documents carefully, as they describe your rights 44 and restrictions with respect to this document. 46 Abstract 48 IPv6 offers significant advantages over IPv4, however it will take 49 a long time to replace IPv4 with IPv6. Therefore, these two protocols 50 are expected to coexist during the transition period. Currently, 51 there are many transition technologies, such as translation and 52 tunneling. In some typical transition scenarios, both tunneling and 53 translation are needed. However, either translation or tunneling has 54 limitation and application scope. In addition, besides IP version of 55 source, middle and destination network, the network property (a 56 regular edge network or a backbone) has key impact on system 57 performance. Therefore, we need to decide which transition method 58 should be used in some typical transition scenarios and how 59 transition and tunneling collaborate for solving transition problems. 60 This draft presents an IPv4-IPv6 transition framework, which is a 61 network side transition solution. It introduces a toolbox named PET 62 (short for Prefixing, encapsulation and translation) to solve IPv4- 63 IPv6 transition. PET includes fundamental elements needed in 64 transition scenarios, which provides the flexibility for network to 65 decide the proper transition methods. In addition, this draft also 66 addresses how to deploy PETs and analyze the advantages and 67 disadvantages of all transition methods that PET may adopt. 69 Table of Contents 71 1. Introduction................................................2 72 2. Requirements Terminology....................................4 73 3. Fundamental requirements of IPv4-IPv6 transition methods....4 74 4. Descriptions of PET.........................................5 75 5. PET Framework...............................................6 76 5.1. IPv4-IPv6-IPv4.........................................8 77 5.2. IPv4-IPv6-IPv6.........................................9 78 5.3. IPv6-IPv6-IPv4........................................11 79 5.4. IPv6-IPv4-IPv6........................................11 80 5.5. IPv4-IPv4-IPv6........................................12 81 5.6. IPv6-IPv4-IPv4........................................12 82 6. Implementation issues......................................14 83 7. Acknowledgment.............................................14 84 8. References.................................................15 85 8.1. Normative References..................................15 86 8.2. Informative References................................16 87 Author's Addresses............................................16 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 semantic between IPv4 and IPv6. There 102 are many translation methods, such as SIIT [RFC 2765], NAT-PT [RFC 103 2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], IVI 104 [draft-ietf-xli-behave-ivi-02] and so on. Translation technology can 105 realize interworking between IPv4 and IPv6 directly, however, it will 106 lead to information 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 [RFC 112 2893], 6over4 tunnel [RFC 2529], softwire transition technology [RFC 113 5565] and so on. Tunneling technology can not realize the 114 interworking between IPv4 and IPv6 directly. It can only deal with 115 the scenario where two IPv4 (IPv6) nodes want to communicate with 116 each other through IPv6 (IPv4) network. However, tunneling technology 117 has several advantages, besides no information loss, it can be 118 realized easily by hardware, and does not introduce routing 119 information into a network with different address family. 121 In some typical transition scenarios, both tunneling and translation 122 are needed. However, as described above, either translation or 123 tunneling has limitation and application scope. In addition, besides 124 IP version of source, middle and destination network, the network 125 property (a regular edge network or a backbone) has key impact on 126 system performance. Therefore, we need to decide which transition 127 method should be used in some typical transition scenarios and how 128 transition and tunneling collaborate for solving transition problems. 129 This draft presents an IPv4-IPv6 transition framework, which is a 130 network side transition solution. It introduces a toolbox named PET 131 (short for Prefixing, encapsulation and translation) to solve IPv4- 132 IPv6 transition. PET includes fundamental elements needed in 133 transition scenarios, which provides the flexibility for network to 134 decide the proper transition methods. In addition, this draft also 135 addresses how to deploy PETs and analyze the advantages and 136 disadvantages of all transition methods that PET may adopt. 138 2. Requirements Terminology 139 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT","SHOULD", 140 "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 141 interpreted as described in [RFC2119]. 143 3. Fundamental requirements of IPv4-IPv6 transition methods 144 There are two main IPv4-IPv6 transition scenarios. One is to connect 145 several edge networks with the same address family across a transit 146 core network with another address family; the other scenario is to 147 make hosts with one address family capable of directly communicating 148 with hosts with the other address family. We call the first scenario 149 heterogeneous crossing. The scenario where two IPv4 (IPv6) nodes want 150 to communicate with each other through IPv6 (IPv4) network belongs to 151 heterogeneous crossing. We call the second scenario heterogeneous 152 direct-connection. The scenario where an IPv4 (IPv6) node wants to 153 directly communicate with an IPv6 (IPv4) node belongs to 154 heterogeneous direct-connection. 156 In fact, most IPv4-IPv6 transition scenarios can be viewed as the 157 combination of heterogeneous crossing and direct-connection. Hence, 158 the fundamental transition elements needed in heterogeneous crossing 159 and direct-connection are those needed in most IPv4-IPv6 transition 160 scenarios. 162 In heterogeneous crossing scenario, tunneling technology can be used 163 to transmit IPv4 (IPv6) packets through IPv6 (IPv4) networks. In 164 addition, through twice translations, IPv4 (IPv6) packets can also be 165 transmitted through IPv6 (IPv4) networks in heterogeneous crossing 166 scenario. In heterogeneous direct-connection scenario, when IPv4 167 (IPv6) nodes want to communicate with IPv6 (IPv4) nodes directly, it 168 can only use translation technology. 170 In addition, when adopting tunneling for supporting IPv4/IPv6 171 interworking, some control operations involved with subnet prefix 172 should be done beforehand. These operations include prefix 173 announcement, tunnel endpoint discovery, the selection of tunnel 174 endpoint and tunnel belonging to the same tunnel endpoint, tunnel 175 configuration, and so on. Similarly, when adopting translation method 176 for supporting IPv4/IPv6 interworking, some control operations 177 involved with subnet prefix also should be done in advance. These 178 operations include the establishment of address mapping mechanism, 179 prefix configuration and so on. We call these control operations 180 involved with subnet prefix prefixing. 182 In conclusion, there are three fundamental elements needed in IPv4- 183 IPv6 transition scenarios, i.e. prefixing, encapsulation and 184 translation. 186 To realize a framwork in network side for IPv4/IPv6 translation, this 187 draft introduces a toolbox named PET which includes the above 188 fundamental elements. The detailed descriptions are given in section 189 4. 191 4. Descriptions of PET 192 PET is a smart transition toolbox supporting IPv4/IPv6 inter-working. 193 It can deal with the heterogeneous crossing and direct-connection 194 scenarios. Because all IPv4-IPv6 transition scenarios can be viewed 195 as the combination of the heterogeneous crossing and direct- 196 connection, the PET-based transition method is a generic solution for 197 IPv4/IPv6 transition. PET toolbox has the following functions: 199 P: representing prefixing. Prefixing includes all transition 200 operations of control plane involved with subnet prefix. 202 In detail, in tunneling technology, prefixing includes prefix 203 announcement, tunnel endpoint discovery, the selection of tunnel 204 endpoint and tunnel belonging to the same tunnel endpoint, and so on. 205 For example, in softwire transition technology, the IPv6 prefix and 206 IPv4 next-hop mapping information should be announced out through 207 extended MP-BGP (Multi-protocol BGP) signaling beforehand. Based on 208 this prefixing operation, the automatic 4over6 tunnels can be 209 established. In translation technology, prefixing includes the 210 establishment of address mapping mechanism, prefix configuration and 211 so on. For example, in IVI-based translation scheme, the global IPv6 212 prefix should be configured in an autonomous domain (AS) beforehand, 213 to form the global IVI address, thus realizing the stateless 214 translation. 216 E: representing encapsulation. E includes all tunneling operations of 217 data plane, such as encapsulation, decapsulation and maximum 218 transmission unit (MTU) processing and so on. 220 Through this operation, packets from IPv6 (IPv4) network are 221 encapsulated on the PET toolbox and sent across IPv4 (IPv6) backbone 222 to another IPv6 (IPv4) network according to the mappings stored on 223 the PET box. 225 T: representing translation. It includes all translation operations 226 of data plane, such as address mapping and protocol translation, MTU 227 processing. 229 Address mapping is to map IPv4 addresses to IPv6 addresses, and vice 230 versa. Based on address mapping, packets can be translated from one 231 address family to another. IPv4 and IPv6 are not directly compatible, 232 so programs and systems designed on one standard can not communicate 233 with those designed to the other. Hence we need protocol translation. 234 Here, protocol translation includes IP layer translation and 235 application layer translation. Through protocol translation, the 236 semantic of IP layer and application layer of an IPv4 packet is 237 equivalent with that of the translated IPv6 packet and vice versa. In 238 addition, to implement translation, PET may collaborate with the 239 domain name system (DNS). 241 The basic idea of our solution is to deploy several PET toolboxes 242 between backbone network and customer networks. The following section 243 will discuss how PET deals with different IPv4/IPv6 translation 244 scenarios in detail. 246 5. PET Framework 247 Figure 1 shows the overall topology of PET framework, which uses PET 248 boxes between IPv6 backbone and IPv4 customer networks. In this 249 topology, an IPv6 backbone is connected with several customer 250 networks including IPv4 backbone, IPv4 virtual private networks 251 (VPNs), IPv6 network and dual stack networks. 253 +------------------+ 254 | | 255 | IPv4 backbone | 256 | | 257 +------------------+ 258 | | 259 | | 260 | | 261 +--------+ +--------+ 262 | PET | | PET | 263 +--| |---| |--+ 264 | +--------+ +--------+ | 265 | | 266 +--------+ +--------+ +--------+ +-------+ 267 | IPv4 | | | IPv6 backbone | | | IPv4 | 268 |network |___| PET | | PET |__|network| 269 | | | | | | | | 270 | | +--------+ +--------+ | | 271 +--------+ | | +-------+ 272 | | 273 | +--------+ +--------+ | 274 +--| PET |---| PET |--+ 275 | | | | 276 +--------+ +--------+ 277 | \ / | 278 | / \ | 279 | / \ | 280 +--------+ +--------+ 281 | IPv6 | | IPv4/ | 282 | | | IPv6 | 283 | Network| | Network| 284 +--------+ +--------+ 285 Figure 1: Topology of PET Framework 287 For different transition scenarios, PET can provide different 288 functionalities to ensure the inter-working of IPv4/IPv6 network. We 289 will analyze how PET works in some typical scenarios in the following 290 subsections. 292 5.1. IPv4-IPv6-IPv4 294 This is the scenario where an IPv4 network wants to talk with another 295 IPv4 network across IPv6 backbone. There are two methods for PET to 296 handle this scenario. One is translation and the other is tunneling. 297 If PET adopts translation method, we need twice translations. In 298 detail, an IPv4 packet need be translated by PET into an IPv6 packet 299 for being delivered through IPv6 backbone. When this packet arrives 300 at another PET, it will be translated into an IPv4 packet again for 301 being delivered through IPv4 network. 303 The other method for IPv4-IPv6-IPv4 scenario is tunneling. This 304 requires a PET to encapsulate the packets and send them to the tunnel 305 endpoint PET across IPv6 backbone. When these packets arrive at the 306 tunnel endpoint PET, they are de-capsulated and sent to IPv4 customer 307 networks. 309 Because translation method will incur information loss, PET prefers 310 to use tunneling technology to handle IPv4-IPv6-IPv4 scenario. Its 311 operations are shown in Figure 2. 313 +-------------+ +-------------+ +-------------+ +-------------+ 314 |IPv4 customer| | PET | | PET | |IPv4 customer| 315 | network | | | | | | network | 316 +-------------+ +-------------+ +-------------+ +-------------+ 317 | | | | 318 |---forwarding--->| | | 319 | encapsulation | | 320 | | | | 321 | |-----tunneling--->| | 322 | | | | 323 | | decapsulation | 324 | | |------forwarding->| 325 | | | | 326 Figure 2: PET operations in IPv4-IPv6-IPv4 scenario 328 5.2. IPv4-IPv6-IPv6 330 This is the scenario where an IPv4 customer network wants to talk 331 with an IPv6 customer network across IPv6 backbone. There are two 332 methods to deal with this scenario. One is translation plus 333 forwarding. The other is tunneling plus translation. 335 In the first method, when an IPv4 packet arrives at PET, it will be 336 translated into an IPv6 packet and then sent to the IPv6 network 337 through IPv6 backbone. In the second method, when an IPv4 packet 338 arrives at PET, it will be encapsulated as an IPv6 packet for being 339 delivered through IPv6 backbone. Once this packet arrives at the 340 tunnel endpoint PET, it will be de-capsulated to the original IPv4 341 packet and then be translated as an IPv6 packet to be delivered to 342 the IPv6 customer network. 344 If the IPv4 customer network is not an IPv4 backbone, PET prefers to 345 adopt the first method because the complexity of second method is 346 higher than that of the first method. Its operation is shown in 347 Figure 3. 349 +-------------+ +-------------+ +-------------+ +-------------+ 350 |IPv4 customer| | PET | | PET | |IPv6 customer| 351 | network | | | | | | network | 352 +-------------+ +-------------+ +-------------+ +-------------+ 353 | | | | 354 |-----forwarding->| | | 355 | translation | | 356 | | | | 357 | |----forwarding--->| | 358 | | | | 359 | | | | 360 | | | | 361 | | |-----forwarding-->| 362 | | | | 363 Figure 3 : PET operations in IPv4-IPv6-IPv6 scenario (IPv4 customer 364 network is not a backbone) 366 If the IPv4 customer network is a backbone, PET prefers to adopt the 367 second method for the following reasons: 369 i) Translation mechanism usually needs application level gateway 370 (ALG), which is an application specific agent that allows an IPv6 371 node to communicate with an IPv4 node and vice versa. Backbone 372 network requires hardware forwarding for high speed transmission. 373 However, it is hard to use hardware to do the work of ALG. 375 ii) To avoid single point of failure, several PETs usually be 376 deployed among networks. They improve performance and robustness 377 using dynamic routing mechanism. However, translation is a static 378 process. It is hard to use dynamic routing mechanism. 380 iii) At last, some translation mechanisms, such as IVI-based scheme, 381 require IPv4 routing information to be introduced into IPv6 backbone, 382 which will increase the routing base size. Based on the above 383 analyses, PET refers to adopt the second method to deal with this 384 scenario. Its operations are shown in Figure 4. 386 +-------------+ +-------------+ +-------------+ +-------------+ 387 |IPv4 customer| | PET | | PET | |IPv6 customer| 388 | network | | | | | | network | 389 +-------------+ +-------------+ +-------------+ +-------------+ 390 | | | | 391 |----forwarding-->| | | 392 | | | | 393 | encapsulation | | 394 | |----tunneling---->| | 395 | | | | 396 | | decapsulation | 397 | | translation | 398 | | |------forwarding->| 399 | | | | 400 Figure 4: PET operations in IPv4-IPv6-IPv6 scenario (IPv4 customer 401 network is a backbone) 403 5.3. IPv6-IPv6-IPv4 405 This is the scenario where an IPv6 customer network wants to talk 406 with an IPv4 customer network across IPv6 backbone. In this scenario, 407 when an IPv6 packet arrives at PET, it will be translated as an IPv4 408 packet and then the PET encapsulates it and sends it to the tunnel 409 endpoint PET. When the translated IPv4 packet arrives at the tunnel 410 endpoint PET, it will be de-capsulated and sent to the IPv4 customer 411 network. The operations are shown in Figure 5. 413 +-------------+ +-------------+ +-------------+ +-------------+ 414 |IPv6 customer| | PET | | PET | |IPv4 customer| 415 | network | | | | | | network | 416 +-------------+ +-------------+ +-------------+ +-------------+ 417 | | | | 418 |---forwarding--->| | | 419 | translation | | 420 | encapsulation | | 421 | |------tunneling---->| | 422 | | | | 423 | | | | 424 | | decapsulation | 425 | | |--forwarding----->| 426 | | | | 427 Figure 5 : PET operations in IPv6-IPv6-IPv4 scenario 429 5.4. IPv6-IPv4-IPv6 431 This is the scenario where an IPv6 network wants to talk with 432 another IPv6 network across IPv4 backbone. This scenario is similar 433 to IPv4-IPv6-IPv4 scenario. Hence, PET prefers to use tunneling 434 technology to handle this scenario. Its operations are shown in 435 Figure 6. 437 +-------------+ +-------------+ +-------------+ +-------------+ 438 |IPv6 customer| | PET | | PET | |IPv6 customer| 439 | network | | | | | | network | 440 +-------------+ +-------------+ +-------------+ +-------------+ 441 | | | | 442 |---forwarding--->| | | 443 | encapsulation | | 444 | |------tunneling---->| | 445 | | | | 446 | | | | 447 | | decapsulation | 448 | | | | 449 | | |--forwarding----->| 450 | | | | 451 Figure 6: PET operations in IPv6-IPv4-IPv6 scenario 453 5.5. IPv4-IPv4-IPv6 455 This is the scenario where an IPv4 customer network wants to talk 456 with an IPv6 customer network across IPv4 backbone. This scenario is 457 similar to IPv6-IPv6-IPv4 scenario. Hence, PET adopts the similar 458 method to deal with this scenario. Its operations are shown in Figure 459 7. 461 +-------------+ +-------------+ +-------------+ +-------------+ 462 |IPv4 customer| | PET | | PET | |IPv6 customer| 463 | network | | | | | | network | 464 +-------------+ +-------------+ +-------------+ +-------------+ 465 | | | | 466 |---forwarding--->| | | 467 | translation | | 468 | encapsulation | | 469 | |------tunneling---->| | 470 | | | | 471 | | decapsulation | 472 | | |---forwarding---->| 473 | | | | 474 Figure 7: PET operations in IPv4-IPv4-IPv6 scenario 476 5.6. IPv6-IPv4-IPv4 478 This is the scenario where an IPv6 customer network wants to talk 479 with an IPv4 customer network across IPv4 backbone. This scenario is 480 similar to IPv4-IPv6-IPv6 scenario. Hence, PET adopts the similar 481 method to deal with this scenario. Its operations are shown in 482 Figures 8 and 9. 484 +-------------+ +-------------+ +-------------+ +-------------+ 485 |IPv6 customer| | PET | | PET | |IPv4 customer| 486 | network | | | | | | network | 487 +-------------+ +-------------+ +-------------+ +-------------+ 488 | | | | 489 |--forwarding---->| | | 490 | translation | | 491 | | | | 492 | |------forwarding--->| | 493 | | | | 494 | | | | 495 | | | | 496 | | |----forwarding--->| 497 | | | | 498 Figure 8: PET operations in IPv6-IPv4-IPv4 scenario (IPv6 customer 499 network is not a backbone) 501 +-------------+ +-------------+ +-------------+ +-------------+ 502 |IPv6 customer| | PET | | PET | |IPv4 customer| 503 | network | | | | | | network | 504 +-------------+ +-------------+ +-------------+ +-------------+ 505 | | | | 506 |----forwarding-->| | | 507 | | | | 508 | encapsulation | | 509 | |------tunneling---->| | 510 | | | | 511 | | | | 512 | | decapsulation | 513 | | translation | 514 | | |---forwarding---->| 515 | | | | 516 Figure 9: PET operations in IPv6-IPv4-IPv4 scenario (IPv6 customer 517 network is a backbone) 519 6. Implementation issues 520 In this draft, we recommend how to use tunneling and translation 521 method in each scenario using PETs. However, we do not restrict the 522 specific tunneling and translation technology that PET adopts. It can 523 be any transition technology, such as SIIT [RFC 2765], NAT-PT 524 [RFC2766], BIS [RFC 2767], SOCKS64 [RFC 3089], BIA [RFC 3338], 525 IVI[draft-ietf-xli-behave-ivi-02], iP-in-IP tunnel [RFC 2893, RFC 526 4213],GRE tunnel [RFC 1702], 6to4 tunnel [RFC 2893], 6over4 tunnel 527 [RFC2529], softwire transition technology [RFC 5565] and so on. 529 In addition, this draft does not address how PET collaborates with 530 DNS, ALG and other transition devices, as well as inter domain 531 transition problems, which will discuss in the next version. 533 7. Acknowledgment 534 The authors would like to thank Lixia Zhang for her valuable comments 535 on this draft. 537 8. References 539 8.1. Normative References 541 [1] [RFC2765] E.Nordmark. "Stateless IP/ICMP Translation 542 Algorithm 544 [2] (SIIT)", RFC 2765, February 2000 546 [3] [RFC2766] G. Tsirtsis, P. Srisuresh." Network Address 547 Translation - Protocol Translation (NAT-PT)", RFC 2766, 548 February 2000 550 [4] [RFC2767] K. Tsuchiya, H. Higuchi, Y. Atarashi. "Dual Stack 551 Hosts using the "Bump-In-the-Stack" Technique (BIS)", RFC 552 2767, February 2000 554 [5] [RFC3089] H. Kitamura." A SOCKS-based IPv6/IPv4 Gateway 555 Mechanism" RFC 3089, April 2001 557 [6] [RFC3338] S. Lee, M-K. Shin, Y-J. Kim, E. Nordmark, A. 558 Durand. "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 559 RFC 3338, October 2002 561 [7] [RFC2893] R. Gilligan, E. Nordmark. "Transition Mechanisms 562 for IPv6 Hosts and Routers", RFC 2893, August 2000 564 [8] [RFC4213] E. Nordmark, R. Gilligan. "Basic Transition 565 Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 566 2005 568 [9] [RFC1702] S. Hanks, T. Li, D. Farinacci, P. Traina." Generic 569 Routing Encapsulation over IPv4 networks", RFC 1702, 570 October 1994 572 [10] [RFC2893] R. Gilligan, E. Nordmark." Transition Mechanisms 573 for IPv6 Hosts and Routers", RFC 2893, August 2000 575 [11] [RFC2529] B. Carpenter, C. Jung." Transmission of IPv6 over 576 IPv4 Domains without Explicit Tunnels", RFC2529, March 1999 578 [12] [RFC5565] J. Wu, Y. Cui, C. Metz, E. Rosen. " Softwire Mesh 579 Framework", RFC 5565, June 2009 581 8.2. Informative References 583 [I-D. draft-ietf-xli-behave-ivi-02] 585 X. Li,C.Bao,M.Chen,H.Zhang,J.Wu." The CERNET IVI 586 Translation Design and Deployment for the IPv4/IPv6 587 Coexistence and Transition", Internet Draft, June 13, 2009 589 Author's Addresses 591 Yong Cui 592 Tsinghua University 593 Department of Computer Science, Tsinghua University 594 Beijing 100084 595 P.R.China 597 Phone: +86-10-6278-5822 598 Email: cuiyong@tsinghua.edu.cn 600 Mingwei Xu 601 Tsinghua University 602 Department of Computer Science, Tsinghua University 603 Beijing 100084 604 P.R.China 606 Phone: +86-10-6278-5822 607 Email: xmw@csnet1.cs.tsinghua.edu.cn 609 Shengling Wang 610 Tsinghua University 611 Department of Computer Science, Tsinghua University 612 Beijing 100084 613 P.R.China 615 Phone: +86-10-6278-5822 616 Email: slwang@csnet1.cs.tsinghua.edu.cn 617 Xing Li 618 Tsinghua University 619 Network Center, Tsinghua University 620 Beijing 100084 621 P.R.China 623 Phone: +86-10-6278-5983 624 Email: xing@cernet.edu.cn 626 Jianping Wu 627 Tsinghua University 628 Network Center, Tsinghua University 629 Beijing 100084 630 P.R.China 632 Phone: +86-10-6278-5983 633 Email: jianping@cernet.edu.cn 635 Chris Metz 636 cisvo systems 637 170 West Tasman Drive 638 San Jose 95134-1706 639 CA 641 Email: chmetz@cisco.com