idnits 2.17.1 draft-xli-behave-xlate-partial-state-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (March 7, 2010) is 5156 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC1035' is defined on line 556, but no explicit reference was found in the text == Unused Reference: 'CERNET' is defined on line 564, but no explicit reference was found in the text == Unused Reference: 'CNGI-CERNET2' is defined on line 567, but no explicit reference was found in the text == Unused Reference: 'RFC3849' is defined on line 577, but no explicit reference was found in the text == Unused Reference: 'RFC5737' is defined on line 580, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-04 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-07 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-07 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-10 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-08 == Outdated reference: A later version (-07) exists of draft-xli-behave-dns46-for-stateless-02 Summary: 1 error (**), 0 flaws (~~), 13 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Li 3 Internet-Draft C. Bao 4 Intended status: Informational CERNET Center/Tsinghua University 5 Expires: September 8, 2010 C. Metz 6 Cisco Systems, Inc. 7 March 7, 2010 9 Stateless/Partial-state 1:N Network Address and Protocol Translation 10 between IPv4 and IPv6 nodes 11 draft-xli-behave-xlate-partial-state-01 13 Abstract 15 This document presents concepts and implementations of stateless/ 16 partial-state 1:N network address and protocol translation between 17 IPv4 and IPv6 nodes. 19 Stateless 1:N translation keeps the features of stateless, end-to-end 20 address transparency and bidirectional-initiated communications of 21 the original stateless translation (1:1 IVI), in addition it can 22 utilize the IPv4 addresses more effectively. However, it requires 23 the modification of the IPv6 end systems or deploying home gateways. 24 By introducing "partial state" in the translator, this requirement is 25 not necessary. 27 Status of this Memo 29 This Internet-Draft is submitted to IETF in full conformance with the 30 provisions of BCP 78 and BCP 79. 32 Internet-Drafts are working documents of the Internet Engineering 33 Task Force (IETF), its areas, and its working groups. Note that 34 other groups may also distribute working documents as Internet- 35 Drafts. 37 Internet-Drafts are draft documents valid for a maximum of six months 38 and may be updated, replaced, or obsoleted by other documents at any 39 time. It is inappropriate to use Internet-Drafts as reference 40 material or to cite them other than as "work in progress." 42 The list of current Internet-Drafts can be accessed at 43 http://www.ietf.org/ietf/1id-abstracts.txt. 45 The list of Internet-Draft Shadow Directories can be accessed at 46 http://www.ietf.org/shadow.html. 48 This Internet-Draft will expire on September 8, 2010. 50 Copyright Notice 52 Copyright (c) 2010 IETF Trust and the persons identified as the 53 document authors. All rights reserved. 55 This document is subject to BCP 78 and the IETF Trust's Legal 56 Provisions Relating to IETF Documents 57 (http://trustee.ietf.org/license-info) in effect on the date of 58 publication of this document. Please review these documents 59 carefully, as they describe your rights and restrictions with respect 60 to this document. Code Components extracted from this document must 61 include Simplified BSD License text as described in Section 4.e of 62 the Trust Legal Provisions and are provided without warranty as 63 described in the BSD License. 65 Table of Contents 67 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 68 2. Terminologies . . . . . . . . . . . . . . . . . . . . . . . . 4 69 3. Stateless 1:N Translation . . . . . . . . . . . . . . . . . . 4 70 3.1. Address-sharing algorithm . . . . . . . . . . . . . . . . 4 71 3.2. Extended address format . . . . . . . . . . . . . . . . . 5 72 3.3. Transport address mapping algorithm . . . . . . . . . . . 7 73 3.4. Protocol translation . . . . . . . . . . . . . . . . . . . 8 74 3.5. IPv6 end system requirements . . . . . . . . . . . . . . . 8 75 4. Partial-state 1:N Translation . . . . . . . . . . . . . . . . 8 76 4.1. Session tables . . . . . . . . . . . . . . . . . . . . . . 8 77 4.2. Port number mapping algorithm . . . . . . . . . . . . . . 9 78 5. Operation considerations . . . . . . . . . . . . . . . . . . . 10 79 5.1. Routing . . . . . . . . . . . . . . . . . . . . . . . . . 10 80 5.2. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 81 5.3. ALG . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 82 6. Deployment Considerations . . . . . . . . . . . . . . . . . . 10 83 6.1. Using Modified IPv6 Hosts in an IPv6 Network . . . . . . . 10 84 6.2. Using Unmodified IPv6 Hosts in an IPv6 Network . . . . . . 11 85 6.3. Mixed Environment in an IPv6 Network . . . . . . . . . . . 11 86 7. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 88 9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 89 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 90 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 91 10.2. Informative References . . . . . . . . . . . . . . . . . . 13 92 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 94 1. Introduction 96 The experiences for the IPv6 deployment in the past 10 years strongly 97 indicate that for a successful transition, the communication between 98 IPv4 and IPv6 address families should be supported. 100 Recently, the stateless and stateful IPv4/IPv6 translation methods 101 are developed and becoming the IETF standards 102 [I-D.ietf-behave-v6v4-framework], [I-D.ietf-behave-v6v4-xlate], 103 [I-D.ietf-behave-v6v4-xlate-stateful]. The original stateless IPv4/ 104 IPv6 translation (stateless 1:1 IVI) is scalable, maintains the end- 105 to-end address transparency and support both IPv6 initiated and IPv4 106 initiated communications [I-D.ietf-behave-v6v4-framework], 107 [I-D.ietf-behave-v6v4-xlate]. But it can not use the IPv4 addresses 108 effectively. The IPv4 address depletion problem makes the deployment 109 of the stateless 1:1 IVI challenging, in particular as the number of 110 IPv6 hosts increases. The stateful IPv4/IPv6 translation can share 111 the IPv4 addresses among IPv6 hosts, but it only supports IPv6 112 initiated communication [I-D.ietf-behave-v6v4-framework], 113 [I-D.ietf-behave-v6v4-xlate-stateful]. Rely on session initiated 114 states, the stateful translation cannot support the end-to-end 115 address transparency and costs more compared with the stateless 116 translation. 118 We then try to find a translation scheme which keeps end-to-end 119 address transparency can utilize IPv4 address effectively. This 120 turns into stateless and partial-state translators. Stateless 1:N 121 translation is an extensions of the stateless translation, which 122 keeps stateless, end-to-end address transparency and bidirectional- 123 initiated communications. By limiting useable port range for 124 different IPv6 addresses, several IPv6 hosts can share a single IPv4 125 address using limited port range. The partial-state 1:N translator 126 is an further extensions of the stateless 1:N translation. It tracks 127 and maps port range of IPv6 hosts using a simplified scheme of 128 stateful translation. Therefore, the modification of IPv6 hosts is 129 not required. In addition, the partial-state 1:N translation has the 130 following features: 132 1. Less state and complexity than full-blown stateful. 134 2. Supports IPv4-initiated connectivity. 136 3. Require less work to log translation bindings. 138 The stateless/partial-state 1:N translation are solutions for the 139 following scenarios [I-D.ietf-behave-v6v4-framework]. 141 o Scenario 1: An IPv6 network to the IPv4 Internet. 143 o Scenario 2: The IPv4 Internet to an IPv6 network. 145 o Scenario 5: An IPv6 network to an IPv4 network. 147 o Scenario 6: An IPv4 network to an IPv6 network. 149 2. Terminologies 151 This document uses the terminologies defined in 152 [I-D.ietf-behave-v6v4-framework], 153 [I-D.ietf-behave-v6v4-xlate-stateful], 154 [I-D.ietf-behave-address-format]. 156 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 157 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 158 document, are to be interpreted as described in [RFC2119]. 160 3. Stateless 1:N Translation 162 In order to provide IPv4 connectivity for multiple IPv6 hosts sharing 163 a single IPv4 address, the port number multiplexing technique is 164 used. This is to say that a single IPv4 address can be shared for 165 multiple IPv6 hosts under the condition that these individual hosts 166 can only use a subset of the 65,536 port numbers when communicating 167 with the IPv4 Internet. For example, if the port multiplexing ratio 168 is 128, each host with IPv4- translatable address can use 512 169 concurrent port numbers when communicating with IPv4 Internet. Note 170 that there is no port number restriction when these IPv6 hosts 171 communicate with the IPv6 Internet. 173 3.1. Address-sharing algorithm 175 The stateless 1:N translation is shown in the following figure. 177 .-------|Host0| A1/(P%N)+0 178 / 179 ------ ----- | 180 / The \ ------ / An \ | 181 | IPv4 |--|1:N |---| IPv6 |------------|Host1| A1/(P%N)+1 182 \Internet/ |XLATE | \Network/ | 183 ------ ------ ----- | 184 |\ 185 | -------|Host2| A1/(P%N)+2 186 | 187 | 188 \ 189 -------|HostK| A1/(P%N)+K 191 Figure 1: Stateless 1:N translation 193 In the above figure, the Host0, Host1, Host2, ..., HostK are sharing 194 the same IPv4 address A1, but port number range for different hosts 195 are not overlapped. Therefore, when these IPv6 hosts communicate 196 with the IPv4 Internet via the translator, it looks like a single 197 host with IPv4 address A1 communicating with the IPv4 Internet. 199 We use the Modulus Operator to define the port number range. If the 200 multiplexing ratio is N, then: 202 o For host K, the allowed port number (P) are P=j*N + K (j=0, 1, 203 ..., N-1). 205 o For the destination port number (P), the packets will be sent to 206 host K=(P%N) (% is the Modulus Operator). 208 For example: If N=256, then host K=5 is only allowed to use port 209 numbers 5, 261, 517, 773, ..., 65,285 as the source port, while the 210 packets with these port numbers as the destination port number will 211 be send to host K=5. 213 3.2. Extended address format 215 In order to perform the stateless translation between the IPv4 and 216 IPv6, both IPv4-converted and IPv4-translatable address are required 217 [I-D.ietf-behave-v6v4-framework], [I-D.ietf-behave-address-format]. 219 The IPv4-converted addresses are used to represent IPv4 addresses in 220 IPv6, as shown in the following figure. 222 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 223 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 224 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 225 |32| prefix |v4(32) | u | zero | 226 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 227 |40| prefix |v4(24) | u |(8)| zero | 228 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 229 |48| prefix |v4(16) | u | (16) | zero | 230 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 231 |56| prefix |(8)| u | v4(24) | zero | 232 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 233 |64| prefix | u | v4(32) | zero | 234 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 236 Figure 2: IPv4-converted address format 238 There is no port number coding required for the IPv4-converted 239 address. 241 The IPv4-translatable addresses are used to represent IPv6 addresses 242 in IPv4, We use 16-bit suffix to encode the range of the port number 243 as shown in the following figure. 245 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 246 |PL| 0-------------32--40--48--56--64--72--80--88--96--104-112-120-| 247 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 248 |32| prefix |v4(32) | u |Coding | zero | 249 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 250 |40| prefix |v4(24) | u |(8)|Coding | zero | 251 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 252 |48| prefix |v4(16) | u | (16) |Coding | zero | 253 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 254 |56| prefix |(8)| u | v4(24) |Coding | zero | 255 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 256 |64| prefix | u | v4(32) |Coding | 0 | 257 +--+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+---+ 259 Figure 3: Extended IPv4-translatable address format 261 Where, we use reserved 16-bits (Coding) to encode the port number 262 range based on the Modulus Operator. 264 The most significant 4 bits define the multiplexing ratio and the 265 least significant 12 bits define the index of the host, as shown in 266 the following figure. 268 (4 bits) | Index Range(12 bits) | Multx ratio | # of Ports 269 ----------------------------------------------------------------- 270 0 000-000 1 65,536 271 1 000-001 2 32,768 272 2 000-003 4 16,384 273 3 000-007 8 8,192 274 4 000-00f 16 4,096 275 5 000-01f 32 2,048 276 6 000-03f 64 1,024 277 7 000-07f 128 512 278 8 000-0ff 256 256 279 9 000-1ff 512 128 280 A 000-3ff 1,024 64 281 B 000-7ff 2,048 32 282 C 000-fff 4,096 16 283 ----------------------------------------------------------------- 285 Figure 4: Transport layer port number coding 287 3.3. Transport address mapping algorithm 289 For the stateless 1:N translation, the IPv6 end systems are required 290 to follow the port number range defined by the extended IPv4- 291 translatable address format when communicating with the IPv4 292 Internet. The port number handling algorithm is: 294 o If the packets are from IPv4 to IPv6, the IPv4 source addresses 295 are translated to the IPv4-converted addresses and the source port 296 numbers are unchanged; the IPv4 destination addresses are 297 translated to the extended IPv4-translatable addresses based on 298 the destination port number and the destination port numbers are 299 unchanged. 301 o If the packets are from IPv6 to IPv4, the IPv6 source addresses 302 and the source port numbers are checked, if the source port number 303 matches the port number range defined by the extended IPv4- 304 translatable address format, the IPv6 source addresses (which are 305 the IPv4-translatable addresses) are translated to the IPv4 306 addresses and the source port numbers are unchanged; the 307 destination IPv6 addresses (which are the IPv4-converted 308 addresses) are translated to the IPv4 destination addresses and 309 the destination port numbers are unchanged. However, if the 310 source port numbers do not match the port number range defined by 311 the extended IPv4-translatable address format, the packets will be 312 dropped. 314 3.4. Protocol translation 316 The protocol translation is defined in [I-D.ietf-behave-v6v4-xlate], 317 except the address translation, which is defined in sections 3.2 and 318 4.2 of this document. 320 3.5. IPv6 end system requirements 322 The IPv6 end systems MUST follow the port number range defined by the 323 extended IPv4-translatable addresses. The behavior of the IPv6 end 324 system when communicating with the IPv4 Internet are: 326 o If the IPv6 end system is used as a server, different well-known 327 ports will be served by different IPv6 hosts. 329 o If the IPv6 end system is used as a client, the end system must 330 generate the source port numbers in the range defined by the 331 extended IPv4-translatable address format. This can be done by 332 the modification of IPv6 end systems. 334 4. Partial-state 1:N Translation 336 Stateless 1:N translation requires that IPv6 end system generate 337 source port number in the range defined by the extended IPv4- 338 translatable address. Then we introduce partial-state 1:N 339 translation, which consists of session table and port number mapping 340 algorithm in translator without the modification of IPv6 end systems. 342 4.1. Session tables 344 A partial-state translator has three session tables: one for TCP 345 sessions, one for UDP sessions, and one for ICMP Query sessions. For 346 TCP and UDP, the session table contains address and port number. For 347 ICMP Query, the session table contains address and identifier. Each 348 entry in the session tables keeps information on the state of the 349 corresponding session. 351 o UDP session is initiated based on port number mapping algorithm 352 defined in section 4.2 and a timer that tracks the remaining 353 lifetime of the UDP session. When the timer expires, the UDP 354 session is deleted. 356 o TCP Session is based on port number mapping algorithm defined in 357 section 4.2 and TCP state machine. When the state machine reaches 358 the termination state, the TCP session is deleted. 360 o ICMP query session is initiated based on port number mapping 361 algorithm defined in section 4.2 and a timer that tracks the 362 remaining lifetime of the ICMP Query session. When the timer 363 expires, the session is deleted. 365 4.2. Port number mapping algorithm 367 For source port number of the packet from IPv6 to IPv4: 369 o If source port number is not in the range defined by the extended 370 IPv4-translatable address, the translator will check if there is 371 an entry in the session table. 373 * If the entry exists, the translator will use that entry to map 374 source port to the one in the session table. 376 * If the entry does not exist, the translator will create an 377 entry in the session table to map the source port to an allowed 378 range. 380 o If source port number is in the range defined by the extended 381 IPv4-translatable address, the translator will not create an entry 382 in the session table. 384 For destination port number of the packet from IPv4 to IPv6: 386 o If the mapping entry exists in the session table, map the 387 destination port number to the one in the session table. 389 o If the mapping entry does not exist in the session table, keep the 390 original destination port number. 392 For destination port number of the packet from IPv6 to IPv4 and for 393 source port number of the packets from IPv4 to IPv6, no special 394 algorithm is required and there is no port number change. 396 The reason we call this partial-state is that: 398 1. The address mapping is fully algorithm based, as defined in 399 section 3.3. The states are used for port number mapping only, 400 as defined in section 4.2. 402 2. There will be no session table created if the the source port 403 number from IPv6 to IPv4 is in the range defined by the extended 404 IPv4-translatable address. 406 3. For the destination port number of the packet from the IPv4 to 407 IPv6, there will be no session table created 409 5. Operation considerations 411 5.1. Routing 413 The routing follows the general IPv4/IPv6 routing principle, i.e. 414 "more specifics win", same as the original stateless 1:1 IVI. 415 [I-D.xli-behave-ivi]. 417 5.2. DNS 419 The DNS handling is referring to DNS64 [I-D.ietf-behave-dns64] and 420 DNS46 [I-D.xli-behave-dns46-for-stateless]. 422 5.3. ALG 424 The ALG related issue is discussed in 425 [I-D.ietf-behave-v6v4-framework]. 427 6. Deployment Considerations 429 The stateless 1:N translation requires that the IPv6 hosts served by 430 the translator generate the port numbers in the range defined 431 extended IPv4-translatable addresses. 433 6.1. Using Modified IPv6 Hosts in an IPv6 Network 435 Stateless translation can be deployed using modified IPv6 hosts. 436 These IPv6 hosts are using extended IPv4-translatable addresses and 437 the IPv6 hosts will generate the source port number in the range 438 defined by extended IPv4-translatable addresses. In other words, the 439 end systems maintain the port-number mapping states. 441 ----------- 442 .-|Host0 (mdf)| A1/(P%N)+0 443 ------ / ----------- 444 ------ |State-| ----- | 445 / The \ |less | / An \ | ----------- 446 | IPv4 |--|1:N |---| IPv6 |------|Host1 (mdf)| A1/(P%N)+1 447 \Internet/ |XLATE | \Network/ | ----------- 448 ------ ------ ----- | 449 |\ ----------- 450 | -|Host2 (mdf)| A1/(P%N)+2 451 | ----------- 452 | 453 \ ----------- 454 -|HostK (mdf)| A1/(P%N)+K 455 ----------- 457 Figure 5: Using Modified IPv6 Hosts 459 6.2. Using Unmodified IPv6 Hosts in an IPv6 Network 461 Partial-state translation can be deployed using unmodified IPv6 462 hosts. These IPv6 hosts are using extended IPv4-translatable 463 addresses and translator (XLATE) keeps the states for the port-number 464 mapping. 466 ----------- 467 .-| Host0 | A1/(P%N)+0 468 ------ / ----------- 469 ------ |Partia| ----- | 470 / The \ |-state| / An \ | ----------- 471 | IPv4 |--|1:N |---| IPv6 |------| Host1 | A1/(P%N)+1 472 \Internet/ |XLATE | \Network/ | ----------- 473 ------ ------ ----- | 474 |\ ----------- 475 | -| Host2 | A1/(P%N)+2 476 | ----------- 477 | 478 \ ----------- 479 -| HostK | A1/(P%N)+K 480 ----------- 482 Figure 6: Using Unmodified IPv6 Hosts 484 6.3. Mixed Environment in an IPv6 Network 486 In a mixed environment, partial-state translator can be deployed. If 487 the IPv6 packets contain the port numbers which are not in the range 488 defined by extended IPv4-translatable addresses, the states will be 489 created in the translator. Otherwise, no states created and 490 maintained in the translator. 492 7. Security Considerations 494 There are no security considerations in this document. 496 8. IANA Considerations 498 This memo adds no new IANA considerations. 500 Note to RFC Editor: This section will have served its purpose if it 501 correctly tells IANA that no new assignments or registries are 502 required, or if those assignments or registries are created during 503 the RFC publication process. From the author's perspective, it may 504 therefore be removed upon publication as an RFC at the RFC Editor's 505 discretion. 507 9. Acknowledgments 509 The authors would like to acknowledge the following contributors in 510 the different phases of the address-sharing IVI and dIVI development: 511 Maoke Chen, Yu Zhai, Wentao Shang, Weifeng Jiang and Yuncehng Zhu. 513 The authors would like to acknowledge the following contributors who 514 provided helpful inputs: Dan Wing, Fred Baker, Dave Thaler, Randy 515 Bush and Kevin Yin. 517 10. References 519 10.1. Normative References 521 [I-D.ietf-behave-address-format] 522 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 523 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 524 draft-ietf-behave-address-format-04 (work in progress), 525 January 2010. 527 [I-D.ietf-behave-dns64] 528 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 529 "DNS64: DNS extensions for Network Address Translation 530 from IPv6 Clients to IPv4 Servers", 531 draft-ietf-behave-dns64-07 (work in progress), March 2010. 533 [I-D.ietf-behave-v6v4-framework] 534 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 535 IPv4/IPv6 Translation", 536 draft-ietf-behave-v6v4-framework-07 (work in progress), 537 February 2010. 539 [I-D.ietf-behave-v6v4-xlate] 540 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 541 Algorithm", draft-ietf-behave-v6v4-xlate-10 (work in 542 progress), February 2010. 544 [I-D.ietf-behave-v6v4-xlate-stateful] 545 Bagnulo, M., Matthews, P., and I. Beijnum, "Stateful 546 NAT64: Network Address and Protocol Translation from IPv6 547 Clients to IPv4 Servers", 548 draft-ietf-behave-v6v4-xlate-stateful-08 (work in 549 progress), January 2010. 551 [I-D.xli-behave-dns46-for-stateless] 552 Li, X. and C. Bao, "DNS46 for the IPv4/IPv6 Stateless 553 Translator", draft-xli-behave-dns46-for-stateless-02 (work 554 in progress), February 2010. 556 [RFC1035] Mockapetris, P., "Domain names - implementation and 557 specification", STD 13, RFC 1035, November 1987. 559 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 560 Requirement Levels", BCP 14, RFC 2119, March 1997. 562 10.2. Informative References 564 [CERNET] "CERNET Homepage: 565 http://www.edu.cn/english_1369/index.shtml". 567 [CNGI-CERNET2] 568 "CNGI-CERNET2 Homepage: 569 http://www.cernet2.edu.cn/index_en.htm". 571 [I-D.xli-behave-ivi] 572 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 573 CERNET IVI Translation Design and Deployment for the IPv4/ 574 IPv6 Coexistence and Transition", draft-xli-behave-ivi-07 575 (work in progress), January 2010. 577 [RFC3849] Huston, G., Lord, A., and P. Smith, "IPv6 Address Prefix 578 Reserved for Documentation", RFC 3849, July 2004. 580 [RFC5737] Arkko, J., Cotton, M., and L. Vegoda, "IPv4 Address Blocks 581 Reserved for Documentation", RFC 5737, January 2010. 583 [dIVI] "Test homepage for the dIVI: 584 http://202.38.97.114:8056/test.html". 586 Authors' Addresses 588 Xing Li 589 CERNET Center/Tsinghua University 590 Room 225, Main Building, Tsinghua University 591 Beijing 100084 592 CN 594 Phone: +86 10-62785983 595 Email: xing@cernet.edu.cn 597 Congxiao Bao 598 CERNET Center/Tsinghua University 599 Room 225, Main Building, Tsinghua University 600 Beijing 100084 601 CN 603 Phone: +86 10-62785983 604 Email: congxiao@cernet.edu.cn 606 Chris Metz 607 Cisco Systems, Inc." 608 3700 Cisco Way 609 San Jose CA 95134 610 USA 612 Phone: 613 Email: chmetz@cisco.com