idnits 2.17.1 draft-cui-softwire-pet-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 25, 2010) is 4903 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) ** Downref: Normative reference to an Informational RFC: RFC 1702 ** 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) ** Obsolete normative reference: RFC 2893 (Obsoleted by RFC 4213) ** Obsolete normative reference: RFC 3338 (Obsoleted by RFC 6535) ** Downref: Normative reference to an Informational RFC: RFC 4925 Summary: 8 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Cui 3 Internet-Draft M. Xu 4 Intended status: Standards Track P. Wu 5 Expires: April 28, 2011 S. Wang 6 J. Wu 7 X. Li 8 Tsinghua University 9 C. Metz 10 Cisco Systems, Inc. 11 October 25, 2010 13 Translation Spot Negotiation in IPv4/IPv6-Coexist Mesh 14 draft-cui-softwire-pet-03 16 Abstract 18 IPv4 and IPv6 are expected to coexist for a long period. Currently, 19 there are many IPv4/IPv6 transition/coexistence techniques, roughly 20 divided into the categories of tunneling and translation. Tunneling 21 and translation have respective application scopes, and translation 22 has some technical limitations, including scalability issue, 23 application layer translation, operation complexity, etc. To improve 24 the availability of translation, this draft proposes the method of 25 selecting appropriate translation spot to execute translation. When 26 the translation spot is not on IPv4-IPv6 border, tunnel is used to 27 achieve the traversing between translation spot and IP border. This 28 method applies well in mesh scenario where both IPv4 and IPv6 client 29 network exists, and BGP can be extended to achieve a translation spot 30 signaling. 32 Status of this Memo 34 This Internet-Draft is submitted in full conformance with the 35 provisions of BCP 78 and BCP 79. 37 Internet-Drafts are working documents of the Internet Engineering 38 Task Force (IETF). Note that other groups may also distribute 39 working documents as Internet-Drafts. The list of current Internet- 40 Drafts is at http://datatracker.ietf.org/drafts/current/. 42 Internet-Drafts are draft documents valid for a maximum of six months 43 and may be updated, replaced, or obsoleted by other documents at any 44 time. It is inappropriate to use Internet-Drafts as reference 45 material or to cite them other than as "work in progress." 47 This Internet-Draft will expire on April 28, 2011. 49 Copyright Notice 51 Copyright (c) 2010 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 Simplified BSD License. 64 This document may contain material from IETF Documents or IETF 65 Contributions published or made publicly available before November 66 10, 2008. The person(s) controlling the copyright in some of this 67 material may not have granted the IETF Trust the right to allow 68 modifications of such material outside the IETF Standards Process. 69 Without obtaining an adequate license from the person(s) controlling 70 the copyright in such materials, this document may not be modified 71 outside the IETF Standards Process, and derivative works of it may 72 not be created outside the IETF Standards Process, except to format 73 it for publication as an RFC or to translate it into languages other 74 than English. 76 Table of Contents 78 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 79 2. Translation Spot Selection . . . . . . . . . . . . . . . . . . 6 80 3. Translation Spot Selection in IPv4/IPv6-coexist Mesh . . . . . 8 81 3.1. Scenario description . . . . . . . . . . . . . . . . . . . 8 82 3.2. Translation between IPvX and IPvY networks . . . . . . . . 9 83 3.3. Translation between IPvX network and IPvY Internet . . . . 9 84 3.4. Translation between IPvY network and IPvX Internet . . . . 9 85 4. Translation Spot Signaling . . . . . . . . . . . . . . . . . . 10 86 4.1. Signaling content . . . . . . . . . . . . . . . . . . . . 10 87 4.2. Extensions in MP-BGP . . . . . . . . . . . . . . . . . . . 10 88 5. Further discussion . . . . . . . . . . . . . . . . . . . . . . 13 89 5.1. Achievement of translation spot selection . . . . . . . . 13 90 5.2. Cooperate with softwire . . . . . . . . . . . . . . . . . 13 91 5.3. Using NAT64 or IVI as translation mechanism . . . . . . . 13 92 6. IANA considerations . . . . . . . . . . . . . . . . . . . . . 14 93 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 94 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 95 8.1. Normative References . . . . . . . . . . . . . . . . . . . 16 96 8.2. Informative References . . . . . . . . . . . . . . . . . . 17 97 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 99 1. Introduction 101 Recently more and more IPv6 networks have been deployed, especially 102 IPv6 backbone networks. However the existing IPv4 networks still 103 carry the major network traffic and hold the major network services 104 and applications. It has been widely believed that IPv4 and IPv6 105 networks will coexist for a long term. This leads to the demand for 106 IPv4-IPv6 coexistence technology. 108 Till now there are two types of IPv4-IPv6 coexistence techniques: 109 tunneling and translation. Tunneling can achieve IPv4-over-IPv6/ 110 IPv6-over-IPv4 traversing, by means of encapsulation and 111 decapsulation. Examples of tunneling methods include IP-in-IP tunnel 112 [RFC2893][RFC4213], GRE tunnel [RFC1702], 6to4 tunnel [RFC3056], 113 6over4 tunnel [RFC2529], softwire mesh technique [RFC5565], etc. 114 Tunneling is transparent and light-weighted. It can be implemented 115 fully by hardware. 117 On the other hand, translation is used to achieve IPv4-IPv6 inter- 118 communication, by means of converting the semantic between IPv4 and 119 IPv6. Examples of translation methods include SIIT [RFC2765], NAT-PT 120 [RFC2766], BIS [RFC2767], BIA [RFC3338], IVI [I-D.xli-behave-ivi], 121 NAT64 [I-D.ietf-behave-v6v4-xlate-stateful] and so on. Translation 122 can achieve IPv4-IPv6 interworking which tunneling cannot do, but it 123 has several technical limitations: 125 o Scalability. In stateful translation, the dynamic mapping of 126 (address, port) tuple should be maintained on the translation 127 device. The total number of mapping entries is up to the order of 128 flow number. As to stateless translation, it has to consume IPv4 129 addresses to satisfy IPv6 hosts. This is also not scalable since 130 IPv6 address space is much larger than IPv4 address. 132 o Application layer translation. Since translation will modify the 133 address of an IP packet, or we say an end host, an application 134 protocol that contains IP addresses in its payload won't work if 135 we don't convert the addresses. However, due to the variety of 136 applications protocols, it's unrealistic for the translation 137 device to support all of them. 139 o Operation complexity. To accomplish correct translation, the 140 following operations are required: address or (address, port) 141 tuple conversion, IP and ICMP fields translation, TCP/UDP checksum 142 re-computing, application layer detection and translation, 143 fragmentation when necessary. It's rather complex for a per- 144 packet process and probably unacceptable when the volume is high. 146 o Lack of efficient NAT46 translation mechanism. No efficient IPv4 147 to IPv6 communication mechanism has been proposed since NAT-PT. A 148 fundamental difficulty here is that IPv6 address space is much 149 larger than IPv4 so the translation mechanism has to make DNS or 150 other addressing method stateful. Obviously this is not scalable. 152 Though facing all these issues, translation is irreplaceable in its 153 application scope, so it's necessary to find a way to improve its 154 availability. To solve this problem, this draft proposes the method 155 of finding the appropriate translation spot to execute translation. 156 The method adopts tunnel when necessary, to achieve traversing 157 between translation spot and IP border. As an attempt, this draft 158 applies the method in IPv4/IPv6-coexist mesh scenario, and extends 159 BGP to achieve translation spot signaling in the scenario. 161 2. Translation Spot Selection 163 The issues of translation listed in section 1 are inherent 164 disadvantages due to the principle of translation. Hence it's 165 difficult to solve these problems by improving the mechanism. 166 However, by choosing the appropriate location to perform translation, 167 these problems can be solved or lightened, and translation can be 168 more available. This draft calls the location to perform translation 169 as "translation spot". 171 The basic idea of translation spot selection is to choose the place 172 where the scalability and complexity is not a concern, i.e., the 173 place where the translator is capable for its own translation 174 traffic. Following this thought, a straightforward principle is to 175 push translation down to edge networks. Since the volume of 176 translation traffic in edge networks is relatively low, it's possible 177 to achieve a real-time per-flow mapping and per-packet modification 178 there. On the contrary, traffic in backbone is aggregated and hence 179 much higher in volume. So routers in backbone would rather only 180 support routing and forwarding than take charge of high-speed 181 translation. However, when the total translation volume is low, it's 182 easier to perform a unified translation in backbone than to 183 distribute the job to many edge networks. 185 To achieve flexible translation spot selection, there's still a 186 difficulty in packet forwarding: in a given topology, the IPv4-IPv6 187 border spot is fixed; If the translation spot isn't identical to the 188 IP border spot, the packets can't be forwarded between the two spot 189 due to IP diversity. See the example in Figure 1. The IP border is 190 on spot 2 between IPvY backbone and IPvX Internet while the 191 translation spot can be spot 1 or spot 2. If spot 1 is chosen, then 192 packets from IPvY edge network are translated into IPvX on spot 1; 193 they have to traverse to IPvY backbone to reach IPvX Internet. , and 194 packets from IPvX Internet have to traverse the IPvY backbone to 195 reach spot 1 for translation. Similar thing happens when spot 2 is 196 chosen in Figure 2. 198 translation ========== translation 199 spot1 tunnel spot2 200 +---------+ +---------+ +---------+ 201 |IPvY Edge| +-----+ |IPvY | +-----+ |IPvX | 202 |Network |--|xlate|--|Backbone |--|xlate|--|Internet | 203 | | +-----+ | | +-----+ | | 204 +---------+ +---------+ +---------+ 205 IP border 207 Figure 1 Translation Spot selection 208 translation ========== translation 209 spot1 tunnel spot2 210 +---------+ +---------+ +---------+ 211 |IPvY Edge| +-----+ |IPvX | +-----+ |IPvX | 212 |Network |--|xlate|--|Backbone |--|xlate|--|Internet | 213 | | +-----+ | | +-----+ | | 214 +---------+ +---------+ +---------+ 215 IP border 217 Figure 2 Translation Spot selection 219 This is actually a traversing problem and the typical solution is 220 tunneling. By building a tunnel to connect IP border and the 221 translation spot, the forwarding path can be achieved. In the 222 example of Figure 1, an IPvX-over-IPvY tunnel between spot 1 and spot 223 2 can be used to forward translated-to-IPvX packets from spot 1 to 224 spot 2, and to-be-translated IPvX packets from spot 2 to spot 1. In 225 Figure 2, an IPvY-over-IPvx tunnel between spot 1 and spot 2 can be 226 used to forward to-be-translated IPvY packets from spot 1 to spot 2, 227 and translated-to-IPvY packet from spot 2 to spot 1. Although the 228 flexible translation spot selection may require an extra tunnel, its 229 cost is much lower than translation, and hence acceptable. 231 3. Translation Spot Selection in IPv4/IPv6-coexist Mesh 233 3.1. Scenario description 235 Translation spot selection can be used in many scenarios. As a 236 demonstration this draft applies it to the mesh scenario described in 237 Figure 3. In this scenario, an IPvX-only backbone is connected to 238 both IPvX networks and IPvY networks. The backbone may also have 239 entrance to IPvX and IPvY Internet. Besides native traffic and IPvY- 240 over-IPvX softwire traffic described in [RFC4925], there're also 241 traffics between IPvX and IPvY networks, between IPvX network and 242 IPvY Internet, and between IPvY network and IPvX Internet. All these 243 three types of traffics require translation, which should be 244 performed on AFBRs (Address Family Border Router) or BRs (Border 245 Router) on the border of the backbone. 247 +--------+ +--------+ 248 | IPvY | | IPvX | 249 |Internet| |Internet| 250 | | | | 251 +--------+ +--------+ 252 | | 253 | | 254 +--------+ +--------+ 255 | AFBR | | BR | 256 +--| Xlator |---| Xlator |--+ 257 | +--------+ +--------+ | 258 +--------+ | | +--------+ 259 | IPvY | +--------+ +--------+ | IPvY | 260 | Client | | AFBR | | AFBR | | Client | 261 | Network|--| Xlator | IPvX | Xlator |--| Network| 262 +--------+ +--------+ only +--------+ +--------+ 263 | | 264 | +--------+ +--------+ | 265 +--| BR |---| BR |--+ 266 | Xlator | | Xlator | 267 +--------+ +--------+ 268 | | 269 | | 270 +--------+ +--------+ 271 | IPvX | | IPvX | 272 | Client | | Client | 273 | Network| | Network| 274 +--------+ +--------+ 276 Figure 3 Translation Spot Selection in IPv4/IPv6-coexist Mesh 278 3.2. Translation between IPvX and IPvY networks 280 The communication between an IPvX network and an IPvY network follows 281 the path "IPvX network - BR - IPvX backbone - AFBR - IPvY network". 282 The translation can be performed either on the BR between IPvX 283 network and backbone, or on the AFBR between IPvX backbone and IPvY 284 network. 286 If the BR is chosen to be translation spot, a tunnel should be 287 established for packet forwarding between the BR and the AFBR. 288 Naturally it could be a softwire tunnel since it's a mesh scenario. 289 Besides, to perform correct translation, BR needs the translation 290 context delivered from the AFBR. This will be discussed in the next 291 section. 293 3.3. Translation between IPvX network and IPvY Internet 295 The communication between an IPvX network and IPvY Internet follows 296 the path "IPvX network - BR - IPvX backbone - AFBR - IPvY Internet". 297 The translation spot can be either the BR between IPvX network and 298 backbone, or the AFBR between IPvX backbone and IPvY Internet. BR 299 can be chosen to avoid scalability and operation complexity issues, 300 and AFBR can be chosen for unified translation purpose. 302 If the BR is chosen to be translation spot, a softwire tunnel should 303 be established between the BR and the AFBR. Also BR needs the 304 translation context delivered from the AFBR. 306 3.4. Translation between IPvY network and IPvX Internet 308 The communication between an IPvY network and IPvX Internet follows 309 the path "IPvY network - AFBR - IPvX backbone - BR - IPvX Internet". 310 The translation spot can be either the AFBR between IPvY network and 311 IPvX backbone, or the BR between IPvX backbone and IPvX Internet. 312 Usually the AFBR is preferred in this case, since it's the IP border 313 and traffic is not so aggregated as in BR. However, BR can be chosen 314 for unified translation purpose. 316 If the BR is chosen to be translation spot, a softwire tunnel should 317 be established between the BR and the AFBR. Also BR needs the 318 translation context delivered from the AFBR. 320 In all three types of translation-involved communication, translation 321 spot selection is feasible. Yet an auto negotiation method is 322 required to make the translation spot selection and translation 323 context advertisement process more practical in the mesh scenario. 324 This will be discussed in the next section. 326 4. Translation Spot Signaling 328 In the IPv4/IPv6-coexist mesh, the total number of client networks, 329 and hence the total number of AFBRs and BRs could be quite high, so 330 an auto negotiation method is required to select the translation spot 331 for all translation-involved communications, rather than manual 332 configuration on every AFBR and BR. This negotiation method is 333 called translation spot signaling. 335 4.1. Signaling content 337 It's clear that translation should be performed on an appropriate 338 translator, or as in this scenario, an AFBR or BR device. Here the 339 concept of Translation Preference (TP) is defined to represent the 340 appropriateness of a device to perform translation. TP is a 341 quantified value set by the administrator of the corresponding AFBR 342 or BR device. By exchanging and comparing TP values, two translators 343 can decided which one to be the translation spot. 345 The TP value should be decided by the administrator. The general 346 criterion here is, the translator whose performance is better, whose 347 traffic volume is lower, and the size of network behind which is 348 smaller (thus the translation traffic is less aggregated), is 349 preferred to do translation and should have a high value. TP can 350 also be configured based on administrator's policy, such as unified 351 translation. 353 TPs for stateless and stateful translation are separated because they 354 have different foundations (stateless translation requires IPv6 host 355 to possess IPv4 address). In a mixed scenario, some translators 356 can't perform stateless translation like others because IPv6 hosts in 357 its network don't own IPv4 addresses. 359 Besides TP, translation context should also be advertised through 360 signaling. The translation context is the necessary knowledge to 361 perform a translation. For stateless translation it's the mapping 362 prefix, and for stateful translation it's the address pool used for 363 address mapping. For example, in the type of "IPv6 network - BR - 364 IPv6 Backbone - AFBR - IPv4 Internet" communication, if stateless 365 translation is adopted, then AFBR should tell BR the prefix for IPv4- 366 IPv6 address mapping when BR performs the translation; if stateful 367 translation is adopted, then AFBR should tell BR the IPv4 addresses 368 BR can use for address mapping when BR performs the translation. 370 4.2. Extensions in MP-BGP 372 MP-BGP is adopted to carry the translation spot signaling process 373 since it fits the mesh scenario and is already used in softwire 374 mesh[RFC5565]. 376 We define a new a new BGP Attribute, "Translation Information 377 Attribute" to carry the TP and translation context information. It's 378 an optional transitive attribute, and the attribute type code is TBD 379 by IANA. The value field of this attribute is composed of a set of 380 Type-Length-Value (TLV) encodings. The TLV is structured as follows. 381 The Length field stands for the total number of octets in the Value 382 field. 384 0 1 2 3 385 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 386 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 387 | Type (2 Octets) | Length (2 Octets) | 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | | 390 | Value | 391 | | 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 We define 4 TLVs here: Stateless_TP TLV, Stateful_TP TLV, IPv6_Prefix 395 TLV and IPv4_pool TLV. More TLVs may be defined in the future when 396 necessary. 398 o Stateless_TP TLV has the type field assigned to 1 and length field 399 assigned to 2. The value field is filled with the 16bit TP value 400 for stateless translation. High the TP value means high 401 preference to perform translation. 403 o Stateful_TP TLV has the type field 2 and length field 2. The 404 value field is filled with the 16bit TP value for stateful 405 translation. High the TP value means high preference to perform 406 translation. 408 o IPv6_Prefix TLV has the type field assigned to 3. The length 409 field is variable. The value field is filled with the IPv6 prefix 410 for address mapping in stateless translation, encoding in NLRI 411 format[RFC4760]. 413 o IPv4_pool TLV has the type field assigned to 4. The length field 414 is variable. The value field is filled with the IPv4 pool for 415 address mapping in stateful translation, encoding in NLRI format. 417 The AFBRs and BRs in the mesh should run MP-BGP process and peer with 418 each other. When a new BGP session is established, AFBR and BR send 419 a update containing the Translation Information Attribute to each 420 other, which contains the Stateless_TP TLV or Stateful_TP TLV. Each 421 router independently decides translation spot based on received TP 422 value. When the selected translation spot isn't the AFBR, then the 423 AFBR should send another update with the Translation Information 424 Attribute containing the IPv6_Prefix TLV or the IPv4_pool TLV to the 425 BR. The tunnel-related routing should be triggered too, if there's 426 any. 428 5. Further discussion 430 5.1. Achievement of translation spot selection 432 To be precise, through translation spot selection, we can solve the 433 scalability problem of stateful translation and the operation 434 complexity problem for both stateless and stateful translation. Also 435 we make it more possible to perform application layer translation and 436 adopt NAT46 mechanisms (NAT-PT) by pushing the translation spot down 437 to the edge. 439 5.2. Cooperate with softwire 441 In the mesh scenario, softwire[RFC5565] is usually adopted as the 442 tunnel mechanism. If it's used to support forwarding between the BR 443 and the AFBR, then after translation spot signaling, BR and AFBR 444 should trigger the softwire routing process, in which AFBR should 445 advertise the actual IPv4 prefixes, while BR should advertise to AFBR 446 either the address pool assigned from the AFBR (stateful case), or 447 the IPv4 address prefix containing the IPv4 address possessed by the 448 IPv6 hosts (stateless case). 450 5.3. Using NAT64 or IVI as translation mechanism 452 NAT64[I-D.ietf-behave-v6v4-xlate-stateful] is a typical stateful 453 translation mechanism. It can be used in the IPv4/IPv6-coexist mesh 454 for translation-involved communications across the backbone. If AFBR 455 is chosen to be the translation spot, then the traffic will follow a 456 traditional NAT64 process; else BR is chosen to be the translation 457 spot, then AFBR should divided its public IPv4 address pool and 458 assigned one block to the BR through translation spot signaling. BR 459 will perform the NAT64 translation using the assigned IPv4 address 460 block. In softwire routing, BR should advertise this block to AFBR. 462 IVI[I-D.xli-behave-ivi] is a typical stateless translation mechanism. 463 It can be used in the IPv4/IPv6-coexist mesh for translation-involved 464 communications across the backbone. If AFBR is chosen to be the 465 translation spot, then the traffic will follow a traditional IVI 466 process; else BR is chosen to be the translation spot, then AFBR 467 should inform BR the IVI prefix, then BR can learn the address 468 mapping role and the IPv4 prefix possessed by its network. In 469 softwire routing, BR should advertise this IPv4 prefix to AFBR. 471 6. IANA considerations 473 IANA is requested to assign a value from the "BGP Path Attributes" 474 Registry, to be called "Translation Information Attribute", with this 475 document as the reference. 477 7. Acknowledgements 479 The authors would like to thank Lixia Zhang, Eric Nordmark, Jari 480 Arkko, Alain Durand and David Ward for their valuable comments on 481 this draft. 483 8. References 485 8.1. Normative References 487 [RFC1702] Hanks, S., Li, T., Farinacci, D., and P. Traina, "Generic 488 Routing Encapsulation over IPv4 networks", RFC 1702, 489 October 1994. 491 [RFC2529] Carpenter, B. and C. Jung, "Transmission of IPv6 over IPv4 492 Domains without Explicit Tunnels", RFC 2529, March 1999. 494 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 495 (SIIT)", RFC 2765, February 2000. 497 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 498 Translation - Protocol Translation (NAT-PT)", RFC 2766, 499 February 2000. 501 [RFC2767] Tsuchiya, K., HIGUCHI, H., and Y. Atarashi, "Dual Stack 502 Hosts using the "Bump-In-the-Stack" Technique (BIS)", 503 RFC 2767, February 2000. 505 [RFC2893] Gilligan, R. and E. Nordmark, "Transition Mechanisms for 506 IPv6 Hosts and Routers", RFC 2893, August 2000. 508 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 509 via IPv4 Clouds", RFC 3056, February 2001. 511 [RFC3338] Lee, S., Shin, M-K., Kim, Y-J., Nordmark, E., and A. 512 Durand, "Dual Stack Hosts Using "Bump-in-the-API" (BIA)", 513 RFC 3338, October 2002. 515 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 516 for IPv6 Hosts and Routers", RFC 4213, October 2005. 518 [RFC4760] Bates, T., Chandra, R., Katz, D., and Y. Rekhter, 519 "Multiprotocol Extensions for BGP-4", RFC 4760, 520 January 2007. 522 [RFC4925] Li, X., Dawkins, S., Ward, D., and A. Durand, "Softwire 523 Problem Statement", RFC 4925, July 2007. 525 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 526 Framework", RFC 5565, June 2009. 528 8.2. Informative References 530 [I-D.ietf-behave-v6v4-xlate-stateful] 531 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 532 NAT64: Network Address and Protocol Translation from IPv6 533 Clients to IPv4 Servers", 534 draft-ietf-behave-v6v4-xlate-stateful-12 (work in 535 progress), July 2010. 537 [I-D.xli-behave-ivi] 538 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 539 CERNET IVI Translation Design and Deployment for the IPv4/ 540 IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 541 (work in progress), January 2010. 543 Authors' Addresses 545 Yong Cui 546 Tsinghua University 547 Department of Computer Science, Tsinghua University 548 Beijing 100084 549 P.R.China 551 Phone: +86-10-6278-5822 552 Email: cy@csnet1.cs.tsinghua.edu.cn 554 Mingwei Xu 555 Tsinghua University 556 Department of Computer Science, Tsinghua University 557 Beijing 100084 558 P. R. China 560 Phone: +86-10-6278-5822 561 Email: xmw@csnet1.cs.tsinghua.edu.cn 563 Peng Wu 564 Tsinghua University 565 Department of Computer Science, Tsinghua University 566 Beijing 100084 567 P. R. China 569 Phone: +86-10-6278-5822 570 Email: weapon@csnet1.cs.tsinghua.edu.cn 572 Shengling Wang 573 Tsinghua University 574 Department of Computer Science, Tsinghua University 575 Beijing 100084 576 P. R. China 578 Phone: +86-10-6278-5822 579 Email: slwang@csnet1.cs.tsinghua.edu.cn 580 Jianping Wu 581 Tsinghua University 582 Department of Computer Science, Tsinghua University 583 Beijing 100084 584 P. R. China 586 Phone: +86-10-6278-5983 587 Email: jianping@cernet.edu.cn 589 Xing Li 590 Tsinghua University 591 Department of Electronic Engineering, Tsinghua University 592 Beijing 100084 593 P. R. China 595 Phone: +86-10-6278-5983 596 Email: xing@cernet.edu.cn 598 Chris Metz 599 Cisco Systems, Inc. 600 3700 Cisco Way 601 San Jose, Ca. 95134 602 USA 604 Email: chmetz@cisco.com