idnits 2.17.1 draft-cui-softwire-pet64-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 2 longer pages, the longest (page 14) being 70 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 12 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- Couldn't find a document date in the document -- date freshness check skipped. 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: 'RFC2119' is mentioned on line 187, but not defined == Missing Reference: 'RFC 5565' is mentioned on line 319, but not defined == Unused Reference: 'RFC5565' is defined on line 535, but no explicit reference was found in the text Summary: 4 errors (**), 0 flaws (~~), 5 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 S. Wang 5 Expires: April 4, 2010 X. Li 6 J. Wu 7 Tsinghua University 8 C. Metz 9 Cisco systems 10 Oct. 2009 12 PET for IPv6 to IPv4 communication 13 draft-cui-softwire-pet64-00.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on February 28, 2010. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 This draft offers a solution using PET for the scenario that an IPv6- 52 only client initiates a communication to an IPv4-only server through 53 IPv6 backbone. In this communication scenario,translation is needed. 54 However, translation work has requirements on the performance 55 (hardware or software) of PET and the size of network that the PET is 56 charge for. This draft introduces the concept of translation 57 preference to express the PET's willing of performing translation 58 according to some policies the network administrators constitute. 59 Through exchanging the Translation preference among PETs, PET 60 framework can decide which PET should act as a translator. In 61 addition, this draft also gives how the PET collaborates with DNS to 62 solve the IPv6-to-IPv4 communication problem. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. PET Framework in IPv6-toIPv4 communication scenario . . . . . 4 70 3. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 4. IPv6-to-IPv4 communication in PET framework . . . . . . . . . 7 73 4.1. IPv6-to-IPv4 communication scenario . . . . . . . . . . . 7 74 4.2. IPv6-to-IPv4 communication using PETs . . . . . . . . . . 8 75 4.3. PET and DNS collaboration for IPv6-to-IPv4 76 communication . . . . . . . . . . . . . . . . . . . . . . 9 77 4.3.1. PET1 Translation scenario . . . . . . . . . . . . . . 10 78 4.3.2. PET2 Translation scenario . . . . . . . . . . . . . . 11 79 4.4. Other considerations . . . . . . . . . . . . . . . . . . . 12 81 5. Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . 13 83 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 84 6.1. Normative References . . . . . . . . . . . . . . . . . . . 14 85 6.2. Informative References . . . . . . . . . . . . . . . . . . 14 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 89 1. Introduction 91 IPv6 offers significant advantages over IPv4, however it will take a 92 long time to replace IPv4 with IPv6. Therefore, these two protocols 93 are expected to coexist during the transition period. 95 On one hand, because it is difficult to update IPv4 applications, a 96 lot of IPv6-only client will want to visit IPv4-only servers to enjoy 97 the IPv4 applications. On the other hand, to promote the transition 98 from IPv4 and to propel IPv6 development, some countries are 99 establishing large-scale pure IPv6 backbone networks. So it is a key 100 problem that an IPv6 client dwelled in an IPv6 network can 101 efficiently communicate with an IPv4 server dwelled in an IPv4 102 network through IPv6 backbone. 104 This draft proposes a solution that using PET framework 105 [I-D.draft-cui-softwire-PET-framework-00]to solve the problem that an 106 IPv6-only client initiates a communication to an IPv4-only server 107 through IPv6 backbone (we call this communication scenario is IPv6- 108 to-IPv4 in the following draft). 110 In IPv6-to-IPv4 communication scenario, translation is inevitably 111 adopted. Hence, which PET should act as a translator is a key 112 problem to be considered. The reason is described as follows: 113 Translation mechanism usually needs application level gateway (ALG), 114 which is an application specific agent that allows an IPv6 host to 115 communicate with an IPv4 host and vice versa. However, it is hard to 116 use hardware to do the work of ALG. Thus, translation has 117 requirements on the performance (including hardware performance and 118 software performance) of PET and the network size the PET charges 119 for. Usually, if a PET's performance is higher and the network's 120 size which the PET charges for is smaller, the PET is supposed to 121 perform translation, and vice versa. 123 In this draft, we firstly give the PET framework in IPv6-to-IPv4 124 communication scenario, based on which this draft discusses two 125 communication modes in 6to4 scenario(different PET perform 126 translation in different modes). This draft introduces the concept 127 of translation preference to express the PET's willing of performing 128 translation according to some policies the network administrators 129 constitute. Through exchanging the Translation preference among 130 PETs, PET framework can decide the communication mode. In addition, 131 this draft also gives how the PET collaborates with DNS to solve the 132 IPv6-to-IPv4 communication problem. At last, this draft describes 133 the filtering of PET. 135 2. PET Framework in IPv6-toIPv4 communication scenario 137 Figure 1 shows the PET framework in IPv6-to-IPv4 scenario, which uses 138 PET boxes between IPv6 backbone and its client networks. The client 139 networks include IPv4 network, IPv4 virtual private networks (VPNs), 140 IPv6 network and dual stack networks. In this draft, we only 141 consider the scenario that one PET is charge of one client network. 142 The scenario that Multiple PETs charge for one client network is out 143 of consideration. 145 +------------------+ 146 | | 147 | IPv6 network | 148 | | 149 +------------------+ 150 | 151 +-----------+ 152 | PET | 153 | | 154 +-----------+ 155 | 156 +-----------------------------+ 157 | | 158 +--------+ +--------+ +--------+ +-------+ 159 | IPv6 | | | IPv6 backbone | | | IPv4 | 160 |network |___| PET | | PET |__|network| 161 | | | | | | | | 162 | | +--------+ +--------+ | | 163 +--------+ | | +-------+ 164 +-----------------------------+ 165 | 166 +-----------+ 167 | PET | 168 | | 169 +-----------+ 170 | 171 +------------------+ 172 | | 173 | IPv4 network | 174 | | 175 +------------------+ 177 Figure 1: PET Framework in IPv6-to-IPv4 scenario 179 3. Terminology 181 This section provides the definitions for all the terms used in 182 draft. 184 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 185 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 186 document are to be interpreted as described in RFC 2119 [RFC2119]. 188 The following terms are used in this document: 190 PET: a smart transition toolbox supporting IPv4/IPv6 inter-working. 191 PET toolbox has the following functions: 193 P: representing prefixing. Prefixing includes all transition 194 operations of control plane involved with subnet prefix. 196 E: representing encapsulation. E includes all tunneling operations 197 of data plane, such as encapsulation, decapsulation and maximum 198 transmission unit (MTU) processing and so on. 200 T: representing translation. It includes all translation operations 201 of data plane, such as address mapping and protocol translation, MTU 202 processing. 204 A PET connects the IPv6 backbone to its client networks. It is a 205 dual stack gateway. PETs can exchange their prefixes and Translation 206 Preferences through softwire signaling [RFC 5565].When collaborating 207 with DNSs, a PET charging for an IPv4 network MUST keep one-to-one 208 mapping between the DNS's IPv4 address and its IPv6 mapping address. 210 Translation Preference (TP): is a value set in a PET to show the 211 preference degree that the PET would like to translate a packet. The 212 higher is the TP, the higher probability that the PET translates 213 packets. 215 PET prefix: a prefix of a network which a PET is charge for. Through 216 PET prefix, an IPv6 PET address is constructed. PET prefixes should 217 be announced by PETs through softwire signaling [RFC 5565], based on 218 that other PETs can differentiate an IPv6 PET address and a regular 219 IPv6 address and judge where a packet comes from or is destined to. 221 IPv6 PET address: an IPv6 address constructed by concatenating the 222 /96 prefix of the PET that is charging for the IPv4 network and the 223 IPv4 address assigned to the IPv4 server. 225 IPv6 mapping address: the IPv6 address representing the IPv4 target. 226 In IPv6-to-IPv4 scenario, an IPv4 target's IPv6 mapping address is 227 its IPv6 PET address. 229 IPv4 mapping address: the IPv4 address representing the IPv6 target. 231 DNS4: a DNS deployed in IPv4 network. It has an IPv6 mapping 232 address. DNS4 SHOULD support for DNSSEC and some forms of IPsec. A 233 DNS4 SHOULD keep the DNS6's IPv4 mapping addresses. This information 234 MAY be set by static configuration. 236 DNS6: a DNS deployed in an IPv6 network (including IPv6 backbone and 237 IPv6 client networks). DNS6 SHOULD support for DNSSEC and some forms 238 of IPsec.It has an IPv4 mapping address. A DNS4 SHOULD keep the 239 DNS6's IPv4 mapping addresses. This information MAY be set by static 240 configuration. 242 4. IPv6-to-IPv4 communication in PET framework 244 4.1. IPv6-to-IPv4 communication scenario 246 Figure 2 shows one kind of IPv6-to-IPv4 communication scenario. A 247 PET connects the IPv6 backbone to its client network, along with the 248 deployment of a DNS6 in the IPv6 client network and a DNS4 in the 249 IPv4 client network. 251 +---------------+ +---------------+ +---------------+ 252 | IPv6 network | +-----+ | | +-----+ |IPv4 network | 253 | +------+ |_| PET1|_| IPv6 core |_| PET2|_| +------+ | 254 | | DNS6 | +-----+ | network | +-----+ | | DNS4 | | 255 | +------+ | | | | +------+ | 256 +---------------+ +---------------+ +---------------+ 258 Figure 2: IPv6-to-IPv4 communication scenario (DNS6 deployed in 259 client network 261 Figure 3 shows the other kind of IPv6-to-IPv4 communication scenario. 262 A PET connects the IPv6 backbone to its client network, along with 263 the deployment of a DNS6 in the IPv6 backbones and a DNS4 in the IPv4 264 client network. 266 Of course, there can be multiple DNSs in the client networks though 267 we only discuss the scenario that one DNS deployed in one client 268 network. 270 +---------------+ +---------------+ +---------------+ 271 | IPv6 network | | IPv6 core | | IPv4 network | 272 | | +-----+ | network | +------+ | | 273 | |_| PET1|_| +------+ |_| PET2 |_| +------+ | 274 | | +-----+ | | DNS6 | | +------+ | | DNS4 | | 275 | | | +------+ | | +------+ | 276 +---------------+ +---------------+ +---------------+ 278 Figure 3: IPv6-to-IPv4 communication scenario (DNS6 deployed in core 279 network) 281 PET has two interfaces, an IPv4 (IPv6) interface connects to the IPv4 282 (IPv6) client network, and an IPv6 interface connects to the IPv6 283 backbone. 285 Each PET should know the existence each other, and they communicate 286 the following information through softwire signaling: 288 i) PET prefix. Through PET prefix announcement, PETs can 289 differentiate an IPv6 PET address and a regular IPv6 address, and 290 judge where the packet comes from or is destined to. 292 ii)TP. Through TP announcement, which PET performs translation is 293 decided. 295 When collaborating with DNS, a PET charging for an IPv4 network MUST 296 keep one-to-one mapping between the DNS's IPv4 address and its IPv6 297 mapping address. 299 4.2. IPv6-to-IPv4 communication using PETs 301 When an IPv6 initiator wants to communicate with an IPv4 host, 302 translation is inevitably adopted. Hence, which PET should act as a 303 translator is a key problem to be considered. The reason is 304 described as follows: Translation mechanism usually needs ALG, which 305 is an application specific agent that allows an IPv6 host to 306 communicate with an IPv4 host and vice versa. However, it is hard to 307 use hardware to do the work of ALG. Thus, translation has 308 requirements on the performance (including hardware performance and 309 software performance) of PET and the network size the PET charges 310 for. Usually, if a PET's performance is higher and the network's 311 size which the PET charges for is smaller, the PET is supposed to 312 perform translation, and vice versa. 314 According to the requirements that performing translation on 315 different PETs, there are two modes of IPv6-to-IPv4 communication 316 using PETs as shown in Figures 4 and 5 respectively. In the first 317 mode, when an IPv6 packet arrives at PET 1, it will be translated 318 into an IPv4 packet and then sent to PET2 using softwire mechanism 319 (i.e. 4 over 6 method) [RFC 5565] through IPv6 backbone. At last, 320 this IPv4 packet will be forwarded directly to the IPv4 host in IPv4 321 client network. 323 +-------------+ +-----+ +--------+ +-----+ +-------------+ 324 |IPv6 client | | PET1| | IPv6 | |PET2 | |IPv4 client | 325 | network | | | |backbone| | | | network | 326 +-------------+ +-----+ +--------+ +-----+ +-------------+ 327 | | | | 328 |-forwarding->| | | 329 | translation | | 330 | encap. | | 331 | |-----tunneling--->| | 332 | | | | 333 | | decap. | 334 | | |------forwarding->| 335 | | | | 337 Figure 4: PET1 translation in IPv6-to-IPv4 communication 339 In the second method, when an IPv6 packet arrives at PET 1, it will 340 be directly delivered through IPv6 backbone. Once this packet 341 arrives at PET2, it will be translated in to an IPv4 and then 342 destined to the target. 344 +-------------+ +-----+ +--------+ +-----+ +-------------+ 345 |IPv6 client | | PET1| | IPv6 | |PET2 | |IPv4 client | 346 | network | | | |backbone| | | | network | 347 +-------------+ +-----+ +--------+ +-----+ +-------------+ 348 | | | | 349 |-forwarding->| | | 350 | |----forwarding--->| | 351 | | translation | 352 | | |-----forwarding-->| 354 Figure 5: PET2 translation in IPv6-to-IPv4 communication 356 4.3. PET and DNS collaboration for IPv6-to-IPv4 communication 358 IF an IPv6 initiator does not know the IPv6 mapping address of the 359 IPv4 target, DNS may be need. In this case, PETs should collaborate 360 with DNSs for IPv6-to-IPv4 communication. 362 The following subsections introduce how PETs collaborate with DNSs in 363 each communication mode. 365 4.3.1. PET1 Translation scenario 367 +---------+ +------+ +-----+ +-----+ +------+ +----------+ 368 |v6network| | DNS6 | | PET1| |PET2 | | DNS4 | |v4network | 369 | host A | | | | | | | | | | host B | 370 +---------+ +------+ +-----+ +-----+ +------+ +----------+ 371 |dstv6 addr?>| | | | | 372 | |---dstv6 addr?---> | | | 373 | | | |dstv6,v4addr?>| | 374 | | | |<-IPv4 addr B-| | 375 | | | prefixPET2::v4B=C | | 376 | |<---IPv6 addr C----| | | 377 | save C | | | | 378 || | | | 380 | | translate | | | 381 | |src:PET1v4/srcport:x| | | 382 | | dst:B | | | 383 | | map:A,y,x | | | 384 | | encap. | | | 385 | | |tunneling | | | 386 | | | decap. | | 387 | | | |-----------IPv4 pkt------->| 389 Figure 6: PET operations ( translation+forwarding) 391 In this scenario, if an IPv6 host (i.e. host A) does not know the 392 IPv6 mapping address of IPv4 target, it will launch a name look up 393 request for host B, the lookup query is directed to the DNS server on 394 the V6 network. 396 In case of DNS6 having no information about the IPv6 mapping address 397 of IPv4 target, DNS6 forwards the name look up request to DNS4 (the 398 DNS6 has the IPv6 mapping address of DNS4 beforehand maybe through 399 static configuration). This name look up request will be intercepted 400 by PET2. Since host B may have IPv6 and/or IPv4 addresses, PET2 401 forwards the original AAAA/A6 query to DNS4 unchanged, as well as an 402 A query for the same host. 404 If an AAAA/A6 record exists for the destination, this will be 405 returned to PET2 which will forward it, also unchanged, to the 406 originating host. If there is an A record for host B, the reply also 407 returns to the PET 2, which translates the reply, adds the Prefix of 408 itself (PET prefix) to construct the IPv6 PET address (prefixPET2:: 409 v4B=C) and finally forwards it (IPv6 addr C) to DNS6. 411 Now host A can use this address like any other IPv6 address and the 412 DNS6 server can even cache it as long as the PET Prefix does not 413 change. 415 After getting the IPv6 mapping address, the host A sends a packet to 416 host B with source port 'y'. When PET 1 receives this packet, it 417 performs translation and select an unused port 'x' to create the 418 mapping entry (IPv6 address of host A, source port y and source port 419 x). After that, PET 1 sends the packet to PET 2 through softwire 420 mechanism (4over6 tunneling). When PET 2 receive this packet, it 421 will directly deliver the packet to Host B. 423 In the opposite direction, when a packet sent by host B arrives at 424 PET 2, PET2 uses the softwire mechanism to send this packet to PET1. 425 Because having the mapping information, PET 1 performs translation 426 and then sends this packet to host A. 428 The TTL values on all DNS resource records (RRs) passing through PET 429 SHOULD be set to 0 so that DNS servers/clients do not cache 430 temporarily assigned RRs. Note, however, that due to some buggy DNS 431 client implementations a value of 1 might in some cases work better. 432 The TTL values should be left unchanged for statically mapped. 434 4.3.2. PET2 Translation scenario 436 +---------+ +------+ +-----+ +-----+ +------+ +---------+ 437 |v6network| | DNS6 | | PET1| |PET2 | | DNS4 | |v4network| 438 | host A | | | | | | | | | | host B | 439 +---------+ +------+ +-----+ +-----+ +------+ +---------+ 440 |dstv6 addr?->| | | | | 441 | |---dstv6 addr?--->| | | 442 | | | |dstv6,v4addr?>| | 443 | | | |<-IPv4 addr B-| | 444 | | | prefixPET2::v4B=C | | 445 | |<--IPv6 addr C----| | | 446 | save C | | | | 447 |<-IPv6 addr C| | | | | 448 |--IPv6 pkt/srcport:y ->| | | | 449 | | | IPv6pkt/srcport:y | | 450 | | | translate | | 451 | | | src:PET1v4/srcport:x | | 452 | | | dst:B | | 453 | | | map:A,y,x | | 454 | | | |-------------IPv4 pkt---->| 456 Figure 7:PET operations in IPv6-IPv6-IPv4 scenario(forwarding 457 +translation) 459 In this case, PET 2 performs translation, to that end, PET 2 selects 460 an unused port 'x' to create the mapping entry (IPv6 address of host 461 A, source port y and source port x). Such binding state is created 462 when the first packet flowing from the IPv6 network to the IPv4 463 network is translated. After the binding state has been created, 464 packets flowing in either direction on that particular flow are 465 translated. 467 The other progress is same as that in subsection 4.3.1. 469 4.4. Other considerations 471 Address mappings for incoming sessions, as described above, are 472 subject to denial of service attacks since one can make multiple 473 queries for nodes residing in the V6 network causing the PETs to map 474 and thus block legitimate incoming sessions. Thus, address mappings 475 for incoming sessions should time out to minimize the effect of 476 denial of service attacks. 478 In fact, an IPv6 host can learn the address of IPv4 target from the 479 DNS4 or from the DNS6. In this draft, we learn the idea from NAT64 480 [draft-ietf-behave-v6v4-xlate-stateful-01] that DNS6 servers maintain 481 a mapping of names to IPv6 addresses for internal nodes and possibly 482 cache mappings for some external nodes. In the case where the DNS6 483 contains the mapping for external IPv4 hosts, the DNS queries will 484 not cross the IPv6 domain and that would obviate the need for PET 485 intervention. Otherwise, the queries will cross the IPv6 domain and 486 are subject to PET intervention. We also learn the idea from NAT64 487 [draft-ietf-behave-v6v4-xlate-stateful-01] that DNS4 servers cache 488 name mapping for external nodes (i.e., V4 nodes) only. 490 For basic functionality, the approach only requires the deployment of 491 PETs connecting the IPv6 backbone to its client networks, along with 492 the deployment of a DNS6 in the IPv6 client network and a DNS4 in the 493 IPv4 client network. However, some advanced features such as support 494 for DNSSEC validating stub resolvers or support for some IPsec modes, 495 require software updates to the IPv6-only hosts. 497 We recommend the time to failure of DNS is no longer than that of 498 mapping in PETs to guarantee the available of IPv6 mapping address 499 (i.e. PET address) of IPv4 target. 501 It is important to note that the translation still works if the IPv6 502 initiator learns the IPv6 mapping address of IPv4 address (i.e. 503 Pref64::X) through some schemes other than a DNS look-up. This is 504 because the DNS processing does NOT result in any state installed in 505 the PET box and because the IPv6 mapping address is constructed by 506 concatenating the PET prefix to the original IPv4 address. 508 5. Filtering 510 Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a 511 PET box may do filtering, which means it only allows some kinds of 512 packets through the interface according to the appropriate policies. 514 Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01], a 515 PET may do no filtering, or it may filter on its IPv4 interface. 516 Filtering on the IPv6 interface is not supported because mappings are 517 only created by packets traveling in the IPv6 --> IPv4 direction. 519 Similar to the NAT64 [draft-ietf-behave-v6v4-xlate-stateful-01],PET 520 filtering is consistent with the recommendations of RFC 4787 521 [RFC4787], and the ones of RFC 5382 [RFC5382]. 523 6. References 525 6.1. Normative References 527 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 528 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 529 RFC 4787, January 2007. 531 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 532 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 533 RFC 5382, October 2008. 535 [RFC5565] Wu, J., Cui, Y., Metz, C., and E. Rosen, "Softwire Mesh 536 Framework", RFC 5565, June 2009. 538 6.2. Informative References 540 [I-D. draft-cui-softwire-PET-framework-00.txt] 542 Y.Cui,M.Xu,S.Wang, X.Li,J. Wu, C. Metz, "PET-based framework 543 for IPv4/IPv6 coexistence", July 2, 2009. 545 [I-D. draft-ietf-behave-v6v4-xlate-stateful-01.txt] 547 M.Bagnulo, P. Matthews,I. van Beijnum. "NAT64: Network Address 548 and Protocol Translation from IPv6 Clients to IPv4 Servers", 549 July 11, 2009. 551 Authors' Addresses 553 Yong Cui 554 Tsinghua University 555 Department of Computer Science, Tsinghua University 556 Beijing 100084 557 P.R.China 559 Phone: +86-10-6278-5983 560 Email: cuiyong@tsinghua.edu.cn 562 Mingwei Xu 563 Tsinghua University 564 Department of Computer Science, Tsinghua University 565 Beijing 100084 566 P.R.China 568 Phone: +86-10-6278-5822 569 Email: xmw@csnet1.cs.tsinghua.edu.cn 571 Shengling Wang 572 Tsinghua University 573 Department of Computer Science, Tsinghua University 574 Beijing 100084 575 P.R.China 577 Phone: +86-10-6278-5822 578 Email: slwang@csnet1.cs.tsinghua.edu.cn 580 Xing Li 581 Tsinghua University 582 Department of Electronic Engineering, Tsinghua University 583 Beijing 100084 584 P.R.China 586 Phone: +86-10-6278-5983 587 Email: xing@cernet.edu.cn 588 Jianping Wu 589 Tsinghua University 590 Department of Electronic Engineering, Tsinghua University 591 Beijing 100084 592 P.R.China 594 Phone: +86-10-6278-5983 595 Email: jianping@cernet.edu.cn 597 Chris Metz 598 Cisco systems 599 170 West Tasman Drive 600 San Jose 95134-1706 601 CA 603 Email: chmetz@cisco.com