idnits 2.17.1 draft-xli-behave-ivi-07.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. == There are 22 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 2 instances of lines with multicast IPv4 addresses in the document. If these are generic example addresses, they should be changed to use the 233.252.0.x range defined in RFC 5771 == There are 2 instances of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 936 has weird spacing: '...omepage for t...' == 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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 6, 2010) is 5186 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-10) exists of draft-ietf-behave-address-format-03 == Outdated reference: A later version (-11) exists of draft-ietf-behave-dns64-05 == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-04 == Outdated reference: A later version (-23) exists of draft-ietf-behave-v6v4-xlate-05 == Outdated reference: A later version (-12) exists of draft-ietf-behave-v6v4-xlate-stateful-07 ** Obsolete normative reference: RFC 793 (Obsoleted by RFC 9293) ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 3171 (Obsoleted by RFC 5771) -- Obsolete informational reference (is this intentional?): RFC 3484 (Obsoleted by RFC 6724) Summary: 6 errors (**), 0 flaws (~~), 13 warnings (==), 4 comments (--). 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 M. Chen 5 Expires: July 10, 2010 H. Zhang 6 J. Wu 7 CERNET Center/Tsinghua University 8 January 6, 2010 10 The CERNET IVI Translation Design and Deployment for the IPv4/IPv6 11 Coexistence and Transition 12 draft-xli-behave-ivi-07 14 Abstract 16 This document presents the China Education and Research Network 17 (CERNET)'s IVI translation design and deployment for the IPv4/IPv6 18 coexistence and transition. 20 The IVI is a prefix-specific and stateless address mapping mechanism 21 for "an IPv6 network to the IPv4 Internet" and "the IPv4 Internet to 22 an IPv6 network" scenarios. In the IVI design, subsets of the ISP's 23 IPv4 addresses are embedded in the ISP's IPv6 addresses and the hosts 24 using these IPv6 addresses can therefore communicate with the global 25 IPv6 Internet directly and can communicate with the global IPv4 26 Internet via stateless translators, the communications can either be 27 IPv6 initiated or IPv4 initiated. The IVI mechanism supports the 28 end-to-end address transparency and incremental deployment. The IVI 29 is an early design deployed in CERNET as a reference for the IETF 30 standard documents on IPv4/IPv6 translation. 32 Status of this Memo 34 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 39 other groups may also distribute working documents as Internet- 40 Drafts. 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 The list of current Internet-Drafts can be accessed at 48 http://www.ietf.org/ietf/1id-abstracts.txt. 50 The list of Internet-Draft Shadow Directories can be accessed at 51 http://www.ietf.org/shadow.html. 53 This Internet-Draft will expire on July 10, 2010. 55 Copyright Notice 57 Copyright (c) 2010 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Analysis of IPv4-IPv6 Translation Mechanisms . . . . . . . 4 74 1.2. CERNET Translation Requirements . . . . . . . . . . . . . 5 75 2. Terms and Abbreviations . . . . . . . . . . . . . . . . . . . 7 76 3. The IVI Translation Algorithm . . . . . . . . . . . . . . . . 7 77 3.1. Address Format . . . . . . . . . . . . . . . . . . . . . . 9 78 3.2. Routing and Forwarding . . . . . . . . . . . . . . . . . . 9 79 3.3. Network-layer Header Translation . . . . . . . . . . . . . 11 80 3.4. Transport-layer Header Translation . . . . . . . . . . . . 12 81 3.5. Fragmentation and MTU Handling . . . . . . . . . . . . . . 12 82 3.6. ICMP Handling . . . . . . . . . . . . . . . . . . . . . . 12 83 3.7. Application Layer Gateway . . . . . . . . . . . . . . . . 13 84 4. The IVI DNS Configuration . . . . . . . . . . . . . . . . . . 13 85 4.1. DNS Configuration for the IVI6(i) Addresses . . . . . . . 13 86 4.2. DNS Service for the IVIG6(i) Addresses . . . . . . . . . . 13 87 5. The Advanced IVI Translation Functions . . . . . . . . . . . . 13 88 5.1. IVI Multicast . . . . . . . . . . . . . . . . . . . . . . 13 89 6. IVI Host Operation . . . . . . . . . . . . . . . . . . . . . . 14 90 6.1. IVI Address Assignment . . . . . . . . . . . . . . . . . . 14 91 6.2. IPv6 Source Address Selection . . . . . . . . . . . . . . 14 92 7. The IVI Implementation . . . . . . . . . . . . . . . . . . . . 15 93 7.1. Linux Implementation . . . . . . . . . . . . . . . . . . . 15 94 7.2. Testing Environment . . . . . . . . . . . . . . . . . . . 15 95 8. Security Considerations . . . . . . . . . . . . . . . . . . . 15 96 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16 97 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 16 98 11. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 16 99 12. Appendix A. The IVI translator configuration example . . . . . 17 100 13. Appendix B. The traceroute results . . . . . . . . . . . . . . 18 101 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 102 14.1. Normative References . . . . . . . . . . . . . . . . . . . 20 103 14.2. Informative References . . . . . . . . . . . . . . . . . . 21 104 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 106 1. Introduction 108 This document presents the CERNET IVI translation design and 109 deployment for the IPv4/IPv6 coexistence and transition. In roman 110 numerals, the IV stands for 4 and VI stands for 6, so IVI stands for 111 the IPv4/IPv6 translation. 113 The experiences with IPv6 deployment in the past 10 years indicate 114 that the ability to communicate between IPv4 and IPv6 address 115 families would be beneficial. However, the current transition 116 methods do not fully support this requirement [RFC4213]. For 117 example, dual-stack hosts can communicate with both the IPv4 and IPv6 118 hosts, but single-stack hosts can only communicate with hosts in the 119 same address family. While the dual-stack approach continues to work 120 in many cases even in the face of IPv4 address depletion [COUNT], 121 there are situations where it would be desirable to communicate with 122 a device in another address family. Tunneling-based architectures 123 can link the IPv6 islands across IPv4 networks, but they cannot 124 provide communication between the two different address families 125 [RFC3056] [RFC5214] [RFC4380]. Translation can relay communications 126 for hosts located in IPv4 and IPv6 networks, but the current 127 implementation of this kind of architecture is not scalable and it 128 cannot maintain end-to-end address transparency [RFC2766] [RFC3142] 129 [RFC4966] [RFC2775]. 131 1.1. Analysis of IPv4-IPv6 Translation Mechanisms 133 Since IPv4 and IPv6 are different protocols with different addressing 134 structures, a translation mechanism is necessary for communication 135 between endpoints using different address families. There are 136 several ways to implement the translation. One is the stateless IP/ 137 ICMP translation algorithm (SIIT) [RFC2765], which provides a 138 mechanism for translation between IPv4 and IPv6 packet headers 139 (including ICMP headers) without requiring any per-connection state. 140 But, SIIT does not specify the address assignment and routing scheme 141 [RFC2766]. For example, the SIIT uses IPv4 mapped IPv6 addresses 142 [::FFFF:ipv4-addr/96] and IPv4 compatible IPv6 addresses [::ipv4- 143 address/96] for the address mapping, but these addresses violate the 144 aggregation principle of IPv6 routing [RFC4291]. The other 145 translation mechanism is NAT-PT, which has serious technical and 146 operational difficulties and IETF has reclassified it from proposed 147 standard to historic status [RFC4966]. 149 In order to solve the technical difficulties in NAT-PT, the issues 150 and the possible workarounds are: 152 1. NAT-PT disrupts all protocols that embed IP addresses (and/or 153 ports) in packet payloads. There is little that can be done 154 about this, other than using Application Layer Gateways (ALGs) or 155 preferring protocols that transport DNS names instead of 156 addresses. 158 2. Loss of end-to-end address transparency. End-to-end address 159 transparency implies a global address space, ability to pass 160 packets unaltered throughout the network, and the ability to use 161 source and destination addresses as unique labels [RFC2775]. A 162 reversible, algorithmic mapping can restore some of this 163 transparency. However, it is still not possible to ensure that 164 all nodes in the existing Internet support such reversible 165 mappings. 167 3. The states maintained in the translator cause scalability, 168 multihoming and load sharing problems. Hence, a stateless 169 translation scheme is preferred. 171 4. Loss of information due to incompatible semantics between IPv4 172 and IPv6 versions of headers and protocols. A partial remedy to 173 this is the proper attention to the details of the protocol 174 translation, for example the error codes mapping between ICMP and 175 ICMPv6. However, some semantic differences remain. 177 5. The DNS is tightly coupled with the translator and lack of 178 address mapping persistence discussed in Section 3.3 of 179 [RFC4966]. Hence, the DNS should be decoupled from the 180 translator. 182 6. Support for referrals is difficult in NAT-PT, given that 183 translated addresses may leak outside the network where these 184 addresses have a meaning. Stateless translation, algorithmic 185 address mappings, and the decoupling of DNS from the translation 186 process can help the handling of referrals. Nevertheless, it is 187 still possible that an address-based referral is passed to 188 someone who cannot employ it. For instance, an IPv6-only node 189 may pass a referral based on an IPv6 address to a node that only 190 understands IPv4. 192 1.2. CERNET Translation Requirements 194 China Education and Research Network has two backbones using 195 different address families. The CERNET is IPv4-only and CERNET2 is 196 IPv6-only [CERNET] [CNGI-CERNET2], which fits in "an IPv6 network to 197 the IPv4 Internet" and "the IPv4 Internet to an IPv6 network" 198 scenarios in the IETF behave Working Group definition [BEHAVE] 199 [I-D.ietf-behave-v6v4-framework]. In order to make CERNET2 200 communicate with the IPv4 Internet, we designed the IVI mechanism and 201 installed IVI translators between CERNET and CERNET2. 203 The requirements of the IVI mechanism are: 205 1. It should support both IPv6 initiated and IPv4 initiated 206 communications for the IPv6 clients/servers in "an IPv6 network". 208 2. It should follow current IPv4 and IPv6 routing practice without 209 increasing the global routing table size in both address 210 families. 212 3. It should be able to be deployed incrementally. 214 4. It should be able to use IPv4 addresses effectively due to the 215 IPv4 address depletion problem. 217 5. It should be stateless to achieve scalability. 219 6. The DNS function should be decoupled from the translator. 221 The specific IVI design presented in this document can satisfy the 222 above requirements with following notes. 224 1. It restricts the IPv6 hosts to use a subset of the addresses 225 inside the ISP's IPv6 block. Therefore, IPv6 auto-configuration 226 cannot be used for these IPv6 hosts. Manual configuration or 227 autoconfiguration via stateful DHCPv6 is required. 229 2. It defines a one-to-one mapping between IPv4 addresses and IPv6 230 addresses, hence the IPv4 addresses cannot be used efficiently. 231 We suggest using the IVI6 addresses for servers instead of 232 clients. 234 3. An ALG is still required for any applications which embed 235 address(es) in the payload. 237 4. Some issues with end-to-end transparency, address referrals, and 238 incompatible semantics between protocol versions still remain, as 239 discussed above. 241 The IVI is an early design deployed in CERNET for the stateless 242 translation. The IETF standard IPv4-IPv6 stateless and stateful 243 translation mechanisms are defined in 244 [I-D.ietf-behave-v6v4-framework], [I-D.ietf-behave-address-format], 245 [I-D.ietf-behave-v6v4-xlate], [I-D.ietf-behave-v6v4-xlate-stateful] 246 and [I-D.ietf-behave-dns64], etc. 248 2. Terms and Abbreviations 250 The following terms and abbreviations are used in this document: 252 ISP(i): A specific Internet service provider "i". 254 IVIG4: The global IPv4 address space. 256 IPS4(i): A subset of IVIG4 allocated to ISP(i). 258 IVI4(i): A subset of IPS4(i), the addresses in this set will be 259 mapped to IPv6 via IVI mapping mechanism and used by IPv6 hosts of 260 ISP(i). 262 IPG6: The global IPv6 address space. 264 IPS6(i): A subset of IPG6 allocated to ISP(i). 266 IVIG6(i): A subset of IPS6(i), and an image of IVIG4 in IPv6 address 267 family via IVI mapping mechanism. It is defined as the IPv4- 268 converted address in [I-D.ietf-behave-v6v4-framework]. 270 IVI6(i): A subset of IVIG6(i) and an image of IVI4(i) in IPv6 271 address family via IVI mapping mechanism. It is defined as the 272 IPv4-translatable address in [I-D.ietf-behave-v6v4-framework]. 274 IVI translator: The mapping and translation gateway between IPv4 and 275 IPv6 based on IVI mechanism. 277 IVI DNS: Providing IVI Domain Name Service (DNS). 279 The key words MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 280 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 281 document, are to be interpreted as described in [RFC2119]. 283 3. The IVI Translation Algorithm 285 The IVI is a prefix-specific and stateless address mapping scheme 286 which can be carried out by individual ISPs. In the IVI design, 287 subsets of the ISP's IPv4 addresses are embedded in ISP's IPv6 288 addresses and the hosts using these IPv6 addresses can therefore 289 communicate with the global IPv6 Internet directly and can 290 communicate with the global IPv4 Internet via stateless translators, 291 the communications can either be IPv6 initiated or IPv4 initiated. 293 IVI mapping and translation mechanism is implemented in an IVI 294 translator which connects between "an IPv6 network" and the IPv4 295 Internet via the ISP's IPv4 network as shown in the following figure. 297 ------ ----- ------ 298 / The \ ----- / An \ / The \ 299 | IPv4 |-----|Xlate|------| IPv6 |-----| IPv6 | 300 \Internet/ ----- \Network/ \Internet/ 301 ------ ----- ------ 302 <===> 304 Figure 1: The scenarios: An IPv6 network to the IPv4 Internet and the 305 IPv4 Internet to an IPv6 network 307 In order to perform the translation function between IPv4 and IPv6 308 addresses, the translator needs to represent the IPv4 addresses in 309 IPv6 and the IPv6 addresses in IPv4. 311 To represent the IPv4 addresses in IPv6, a unique, prefix-specific 312 and stateless mapping scheme is defined between IPv4 addresses and 313 subsets of IPv6 addresses, so each provider-independent IPv6 address 314 block (usually a /32) will have a small portion of IPv6 addresses 315 (for example /40 defined by PREFIX), which is the image of the 316 totality of the global IPv4 addresses, as shown in the following 317 figure. The SUFFIX is all zeros. 319 +-+-+-+-+-+-+ 320 | IVIG4 | 321 +-+-+-+-+-+-+ 322 || 323 \ / 324 \/ 325 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 326 | PREFIX | IPv4 addr | SUFFIX | 327 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 329 Figure 2: Representing the IPv4 addresses in IPv6 331 To represent the IPv6 addresses in IPv4, each provider can borrow a 332 portion of its IPv4 addresses and map them into IPv6 based on the 333 above mapping rule. These special IPv6 addresses will be physically 334 used by IPv6 hosts. The original IPv4 form of the borrowed addresses 335 is the image of these special IPv6 addresses and it can be accessed 336 by the IPv4 Internet, as shown in the following figure. The SUFFIX 337 can either be all zeros or some other value for future extensions. 339 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 340 | PREFIX | |IVI4| | SUFFIX | 341 +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ 342 || 343 \ / 344 \/ 345 -+-+-+ 346 |IVI4| 347 -+-+-+ 349 Figure 3: Representing the IPv6 addresses in IPv4 351 3.1. Address Format 353 The IVI address format is defined based on an individual ISP's IPv6 354 prefix as shown in the following figure. 356 | 0 |32 |40 |72 127| 357 ------------------------------------------------------------------ 358 | |FF | | | 359 ------------------------------------------------------------------ 360 |<- PREFIX ->|<- IPv4 address ->| <- SUFFIX -> | 362 Figure 4: IVI Address Mapping 364 where bit 0 to bit 31 are the prefix of ISP(i)'s /32 (e.g. using 365 document IPv6 address IPS6=2001:DB8::/32), in the CERNET 366 implementation bit 32 to bit 39 are all one's as the identifier of 367 the IVI addresses, bit 40 to bit 71 are embedded global IPv4 space 368 (IVIG4) presented in hexadecimal format. (e.g. 2001:DB8:ff00::/40). 369 Note that based on the IVI mapping mechanism, an IPv4 /24 is mapped 370 to an IPv6 /64 and an IPv4 /32 is mapped to an IPv6 /72. 372 The IETF standard of the address format is defined in 373 [I-D.ietf-behave-address-format]. 375 3.2. Routing and Forwarding 377 Based on the IVI address mapping rule, routing is straightforward, as 378 shown in the following figure. 380 /-----\ /-----\ 381 ( ISP's ) -- 192.0.2.2 ----------- 2001:DB8::2 -- ( ISP's ) 382 ( IPv4 )--|R1|-------------| IVI Xlate |------------|R2|---( IPv6 ) 383 (network) -- 192.0.2.1 ----------- 2001:DB8::1 -- (network) 384 \-----/ \-----/ 385 | | 386 | | 387 The IPv4 Internet The IPv6 Internet 389 Figure 5: IVI Routing 391 where 393 1. IVI Xlate is a special dual-stack router, with two interfaces, 394 one to the IPv4 network and the other to the IPv6 network (it is 395 also possible to have a single interface configured with both 396 IPv4 and IPv6 addresses). IVI Xlate can support dynamic routing 397 protocols in IPv4 and IPv6 address families. In the above 398 configuration, the static routing configuration can be used. 400 2. Router R1 has an IPv4 route for IVI4(i)/k (k is the prefix length 401 of IVI4(i)) with the next-hop equal to 192.0.2.1 and this route 402 is distributed to the Internet with proper aggregation. 404 3. Router R2 has an IPv6 route for IVIG6(i)/40 with the next-hop 405 equal to 2001:DB8::1 and this route is distributed to the IPv6 406 Internet with proper aggregation. 408 4. The IVI translator has an IPv6 route for IVI6(i)/(40+k) with next 409 hop equal to 2001:DB8::2. The IVI translator also has IPv4 410 default route 0.0.0.0/0 with next hop equals to 192.0.2.2 . 412 Note that the routes described above can be learned/inserted by 413 dynamic routing protocols (IGP or BGP) in the IVI translator peering 414 with R1 and R2. 416 Since both IVI4(i) and IVI6(i) are aggregated to IPS4(i) and IPS6(i) 417 in ISP(i)'s border routers respectively, they will not affect the 418 global IPv4 and IPv6 routing tables [RFC4632]. 420 Since the IVI translation is stateless, it can support multi-homing 421 when the same prefix is used for multiple translators. 423 Since the IVI translation can be implemented independently in each 424 ISP's network, it can be incrementally deployed in the global 425 Internet. 427 3.3. Network-layer Header Translation 429 IPv4 [RFC0791] and IPv6 [RFC2460] are different protocols with 430 different network layer header formats; the translation of the IPv4 431 and IPv6 headers MUST be performed according to SIIT [RFC2765] except 432 the source and destinations addresses in the header, as shown in the 433 following figures. 435 ------------------------------------------------------------- 436 IPv4 Field Translated to IPv6 437 ------------------------------------------------------------- 438 Version (0x4) Version (0x6) 439 IHL discarded 440 Type of Service discarded 441 Total Length Payload Length = Total Length - 20 442 Identification discarded 443 Flags discarded 444 Offset discarded 445 Time to Live Hop Limit 446 Protocol Next Header 447 Header Checksum discarded 448 Source Address IVI address mapping 449 Destination Address IVI address mapping 450 Options discarded 451 ------------------------------------------------------------- 453 Figure 6: IPv4 to IPv6 Header translation 455 ------------------------------------------------------------- 456 IPv6 Field Translated to IPv4 Header 457 ------------------------------------------------------------- 458 Version (0x6) Version (0x4) 459 Traffic Class discarded 460 Flow Label discarded 461 Payload Length Total Length = Payload Length + 20 462 Next Header Protocol 463 Hop Limit TTL 464 Source Address IVI address mapping 465 Destination Address IVI address mapping 466 - IHL = 5 467 - Header Checksum recalculated 468 ------------------------------------------------------------- 470 Figure 7: IPv6 to IPv4 Header translation 472 The IETF standard for IP/ICMP translation is defined in 473 [I-D.ietf-behave-v6v4-xlate], which contains updated technical 474 specifications. 476 3.4. Transport-layer Header Translation 478 Since the TCP and UDP headers [RFC0793] [RFC0768] consist of check 479 sums which include the IP header, the recalculation and updating of 480 the transport-layer headers MUST be performed. Note that SIIT does 481 not recalculate the transport-layer checksum, since checksum neutral 482 IPv6 addresses are used in SIIT [RFC2765]. 484 The IETF standard for Transport-layer Header Translation is defined 485 in [I-D.ietf-behave-v6v4-xlate], which contains updated technical 486 specifications. 488 3.5. Fragmentation and MTU Handling 490 When the packet is translated by the IVI translator, due to the 491 different sizes of the IPv4 and IPv6 headers, the IVI6 packets will 492 be at least 20 bytes larger than the IVI4 packets, which may exceed 493 the MTU of the next link in the IPv6 network. Therefore, the MTU 494 handling and translation between IPv6 fragmentation headers and 495 fragmentation field in the IPv4 headers are necessary, which is 496 performed in the IVI translator according to SIIT [RFC2765]. 498 The IETF standard for Fragmentation and MTU Handling is defined in 499 [I-D.ietf-behave-v6v4-xlate], which contains updated technical 500 specifications. 502 3.6. ICMP Handling 504 For ICMP message translation between IPv4 and IPv6, IVI follows the 505 ICMP/ICMPv6 message correspondence as defined in SIIT [RFC2765]. 506 Note that the ICMP message may be generated by an intermediate router 507 whose IPv6 address does not belong to IVIG6(i). Since ICMP 508 translation is important to the path MTU discovery and trouble 509 shooting, the IPv4 representation of the non-IVIG6 addresses in the 510 ICMP packets is required. In the current IVI prototype, a small IPv4 511 address block is used to identify the non-IVIG6 addresses. This 512 prevents translated ICMP messages from being discarded due to unknown 513 or private IP source. 515 The IETF standard for IP/ICMP translation is defined in 516 [I-D.ietf-behave-v6v4-xlate], which contains updated technical 517 specifications. 519 3.7. Application Layer Gateway 521 Due to the features of 1-to-1 address mapping and stateless 522 operation, IVI can support most of the existing applications, such as 523 HTTP, SSH and Telnet. However, some applications are designed such 524 that IP addresses are used to identify application-layer entities 525 (e.g. FTP). In these cases, application layer gateway (ALG) is 526 unavoidable, and it can be integrated into the IVI translator. 528 The discussion of the use of ALGs is in 529 [I-D.ietf-behave-v6v4-framework]. 531 4. The IVI DNS Configuration 533 The DNS [RFC1035] service is important for the IVI mechanism. 535 4.1. DNS Configuration for the IVI6(i) Addresses 537 For providing authoritative DNS service for IVI4(i) and IVI6(i), each 538 host name will both have an A record and an AAAA record pointing to 539 IVI4(i) and IVI6(i), respectively. Note that the same name always 540 points to a unique host, which is an IVI6(i) host and it has IVI4(i) 541 representation via the IVI translator. 543 4.2. DNS Service for the IVIG6(i) Addresses 545 For resolving the IPv6 form of the global IPv4 space (IVIG6(i)), each 546 ISP must provide customized IVI DNS service for the IVI6(i) hosts. 547 The IVI DNS server MUST be deployed in a dual stack environment. 548 When the IVI6(i) host queries an AAAA record for an IPv4 only domain 549 name, the IVI DNS will query the AAAA record first. If the AAAA 550 record does not exist, the IVI DNS will query the A record and map it 551 to IVIG6(i) and return an AAAA record to the IVI6(i) host. The 552 technical specifications of this process are defined in 553 [I-D.ietf-behave-dns64]. 555 5. The Advanced IVI Translation Functions 557 5.1. IVI Multicast 559 The IVI mechanism can support IPv4/IPv6 communication of the 560 protocol-independent specific-source sparse-mode multicast (PIM SSM) 561 [RFC3171] [RFC3569] [RFC4607]. 563 There will be 2^24 group addresses for IPv4 SSM. The corresponding 564 IPv6 SSM group addresses can be defined as shown in the following 565 figure. 567 ------------------------------------------------------- 568 IPv4 Group Address IPv6 Group Address 569 ------------------------------------------------------- 570 232.0.0.0/8 ff3e:0:0:0:0:0:f000:0000/96 571 232.255.255.255/8 ff3e:0:0:0:0:0:f0ff:ffff/96 572 ------------------------------------------------------- 574 Figure 8: IVI Multicast Group Address Mapping 576 The source address in IPv6 MUST be IVI6(i) in order to perform 577 reverse path forwarding (RPF) as required by PIM-SM. 579 The interoperation of PIM-SM for address families IPv4 and IPv6 can 580 either be implemented via an application layer gateway or via static 581 joins based on IGMPv3 and MLDv2 in IPv4 and IPv6, respectively. 583 6. IVI Host Operation 585 6.1. IVI Address Assignment 587 The IVI6 address has special format (for example IVI4=192.0.2.1/32 588 and IVI6=2001:db8:ffc0:2:100::/72), therefore, stateless IPv6 address 589 auto-configuration cannot be used. However, the IVI6 can be assigned 590 to the IPv6 end system via manual configuration or stateful auto- 591 configuration via DHCPv6. 593 o For the manual configuration, the host needs to configure the IVI6 594 address and the corresponding prefix length, as well as the 595 default gateway address and the DNS resolver address. 597 o For the DHCPv6 configuration, the DHCPv6 will assign the IVI6 598 address and the DNS resolver address to the host. The router in 599 the subnet should enable router advertisement (RA), since the 600 default gateway is learned from the router. 602 6.2. IPv6 Source Address Selection 604 Since each IPv6 host may have multiple addresses, it is important for 605 the host to use an IVI6(i) address to reach the global IPv4 networks. 606 The short-term work around is to use IVI6(i) as the default source 607 IPv6 address of the host, defined as the policy table in [RFC3484]. 608 The long-term solution requires that the application should be able 609 to select the source addresses for different services. 611 7. The IVI Implementation 613 7.1. Linux Implementation 615 An implementation of IVI exists for the Linux operating system. The 616 sources code can be downloaded from [LINUX]. An example of how to 617 configure an IVI deployment is shown in Appendix A. 619 The IVI DNS source code for the IVIG6(i) addresses presented in this 620 document can be downloaded from [DNS]. 622 7.2. Testing Environment 624 The IVI translator based on the Linux implementation has been 625 deployed between [CERNET] (IPv4-only) and [CNGI-CERNET2] (IPv6-only) 626 since March 2006. The pure IPv6 web servers using IVI6 addresses 627 [2001:250:ffca:2672:100::] behind the IVI translator can be accessed 628 by the IPv4 hosts [TEST4], and also by the global IPv6 hosts [TEST6]. 629 The pure IPv6 clients using IVI6 addresses behind IVI translator can 630 access IPv4 servers on the IPv4 Internet. 632 Two traceroute results are presented in Appendix B to show the 633 address mapping of the IVI mechanism. 635 IVI6 manual configuration and DHCPv6 configuration of the IPv6 end 636 system have also been tested with success. 638 8. Security Considerations 640 This document presents the prefix-specific and stateless address 641 mapping mechanism (IVI) for the IPv4/IPv6 coexistence and transition. 642 The IPv4 security and IPv6 security issues should be addressed by 643 related documents of each address family and are not included in this 644 document. 646 However, there are several issues that need special considerations, 647 specifically (a) IPsec and its NAT traversal, (b) DNSSEC, and (c) 648 firewall filter rules. 650 o IPsec and its NAT traversal. Since the IVI scheme maintains end- 651 to-end address transparency, IPsec could work without or with NAT 652 traversal techniques. 654 o DNSSEC verification will be terminated at the IVI DNS for the A 655 record to AAAA record translation. It would be fine to have a 656 translation in a local IVI DNS server that also verifies DNSSEC. 657 Or in the host, if the host both translates the DNS entry and 658 again verifies DNSSEC validity. The DNSSEC discussion is in 659 [I-D.ietf-behave-dns64]. 661 o Firewall filter rules. Since the IVI scheme maintains the end-to- 662 end address transparency and there is a unique mapping between 663 IPv4 and IPv6 addresses, therefore the firewall filter rule can be 664 implemented for one address family or mapped to another address 665 family and implemented in that address family. However, the 666 current IPv6 routers may only support the access-list or uRPF 667 (unicast Reverse Path Forwarding) for the prefix length shorter 668 than /64, there may a practical constraint for the construction of 669 such rules. 671 Except the issues discussed above, we have not found special security 672 problems introduced by the IVI translation in our experiments. 674 9. IANA Considerations 676 This memo adds no new IANA considerations. 678 Note to RFC Editor: This section will have served its purpose if it 679 correctly tells IANA that no new assignments or registries are 680 required, or if those assignments or registries are created during 681 the RFC publication process. From the author's perspective, it may 682 therefore be removed upon publication as an RFC at the RFC Editor's 683 discretion. 685 10. Contributors 687 The authors would like to acknowledge the following contributors in 688 the different phases of the IVI development: Ang Li, Yuncheng Zhu, 689 Junxiu Lu, Yu Zhai, Wentao Shang, Weifeng Jiang and Bizheng Fu. 691 The authors would like to acknowledge the following contributors who 692 provided helpful inputs concerning the IVI concept: Bill Manning, 693 David Ward, Elwyn Davies, Lixia Zhang, Jun Murai, Fred Baker, Jari 694 Arkko, Ralph Droms, Tony Hain and Kevin Yin. 696 11. Acknowledgments 698 The authors thank to the funding supports of the CERNET, CNGI- 699 CERNET2, CNGI Research and Development, China "863" and China "973" 700 projects. 702 12. Appendix A. The IVI translator configuration example 704 IVI Configuration Example 706 #!/bin/bash 707 # open forwarding 708 echo 1 > /proc/sys/net/ipv6/conf/all/forwarding 709 echo 1 > /proc/sys/net/ipv4/conf/all/forwarding 711 # config route for IVI6 = 2001:db8:ffc0:2:0::/64, 712 # IVI4 = 192.0.2.0/24 714 # configure IPv6 route 715 route add -A inet6 2001:db8:ffc0:2:0::/64 \ 716 gw 2001:da8:aaae::206 dev eth0 718 # config mapping for source-PF = 2001:db8::/32 719 # config mapping for destination-PF = 2001:db8::/32 721 # for each mapping, a unique pseudo-address (10.0.0.x/8) 722 # should be configured. 723 # ip addr add 10.0.0.1/8 dev eth0 725 # IPv4-to-IPv6 mapping, multiple mappings can be done via multiple 726 # commands. 727 # mroute IVI4-network IVI4-mask pseudo-address interface \ 728 # source-PF destination-PF 729 /root/mroute 192.0.2.0 255.255.255.0 10.0.0.1 \ 730 eth0 2001:db8:: 2001:db8:: 732 # IPv6-to-IPv4 mapping 733 # mroute6 destination-PF destination-PF-pref-len 734 /root/mroute6 2001:db8:ff00:: 40 736 Figure 9 738 13. Appendix B. The traceroute results 740 ivitraceroute 742 ivitraceroute 202.38.108.2 744 1 202.112.0.65 6 ms 2 ms 1 ms 745 2 202.112.53.73 4 ms 6 ms 12 ms 746 3 202.112.53.178 1 ms 1 ms 1 ms 747 4 202.112.61.242 1 ms 1 ms 1 ms 748 5 192.0.2.100 1 ms 1 ms 1 ms 749 6 192.0.2.102 1 ms 1 ms 1 ms 750 7 192.0.2.103 2 ms 2 ms 2 ms 751 8 192.0.2.104 2 ms 2 ms 2 ms 752 9 192.0.2.105 4 ms 4 ms 3 ms 753 10 202.38.108.2 2 ms 3 ms 3 ms 755 Figure 10 757 Note that the non-IVIG6 addresses are mapped to IPv4 document address 758 192.0.2.0/24. 760 ivitraceroute6 762 ivitraceroute6 www.mit.edu 764 src_ivi4=202.38.97.205 src_ivi6=2001:da8:ffca:2661:cd00:: 765 dst_host=www.mit.edu 766 dst_ip4=18.7.22.83 dst_ivig=2001:da8:ff12:716:5300:: 768 traceroute to 2001:da8:ff12:716:5300:: (2001:da8:ff12:716:5300::), 769 30 hops max, 40 byte packets to not_ivi 771 1 2001:da8:ff0a:0:100:: 0.304 ms 0.262 ms 0.190 ms 772 10.0.0.1 773 2 2001:da8:ffca:7023:fe00:: 0.589 ms * * 774 202.112.35.254 775 3 2001:da8:ffca:7035:4900:: 1.660 ms 1.538 ms 1.905 ms 776 202.112.53.73 777 4 2001:da8:ffca:703d:9e00:: 0.371 ms 0.530 ms 0.459 ms 778 202.112.61.158 779 5 2001:da8:ffca:7035:1200:: 0.776 ms 0.704 ms 0.690 ms 780 202.112.53.18 781 6 2001:da8:ffcb:b5c2:7d00:: 89.382 ms 89.076 ms 89.240 ms 782 203.181.194.125 783 7 2001:da8:ffc0:cb74:9100:: 204.623 ms 204.685 ms 204.494 ms 784 192.203.116.145 785 8 2001:da8:ffcf:e7f0:8300:: 249.842 ms 249.945 ms 250.329 ms 786 207.231.240.131 787 9 2001:da8:ff40:391c:2d00:: 249.891 ms 249.936 ms 250.090 ms 788 64.57.28.45 789 10 2001:da8:ff40:391c:2a00:: 259.030 ms 259.110 ms 259.086 ms 790 64.57.28.42 791 11 2001:da8:ff40:391c:700:: 264.247 ms 264.399 ms 264.364 ms 792 64.57.28.7 793 12 2001:da8:ff40:391c:a00:: 271.014 ms 269.572 ms 269.692 ms 794 64.57.28.10 795 13 2001:da8:ffc0:559:dd00:: 274.300 ms 274.483 ms 274.316 ms 796 192.5.89.221 797 14 2001:da8:ffc0:559:ed00:: 274.534 ms 274.367 ms 274.517 ms 798 192.5.89.237 799 15 * * * 800 16 2001:da8:ff12:a800:1900:: 276.032 ms 275.876 ms 276.090 ms 801 18.168.0.25 802 17 2001:da8:ff12:716:5300:: 276.285 ms 276.370 ms 276.214 ms 803 18.7.22.83 805 Figure 11 807 Note that all of the IPv4 addresses can be mapped to prefix-specific 808 IPv6 addresses (for example 18.7.22.83 is mapped to 2001:da8:ff12: 809 716:5300::). 811 14. References 813 14.1. Normative References 815 [I-D.ietf-behave-address-format] 816 Huitema, C., Bao, C., Bagnulo, M., Boucadair, M., and X. 817 Li, "IPv6 Addressing of IPv4/IPv6 Translators", 818 draft-ietf-behave-address-format-03 (work in progress), 819 December 2009. 821 [I-D.ietf-behave-dns64] 822 Bagnulo, M., Sullivan, A., Matthews, P., and I. Beijnum, 823 "DNS64: DNS extensions for Network Address Translation 824 from IPv6 Clients to IPv4 Servers", 825 draft-ietf-behave-dns64-05 (work in progress), 826 December 2009. 828 [I-D.ietf-behave-v6v4-framework] 829 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 830 IPv4/IPv6 Translation", 831 draft-ietf-behave-v6v4-framework-04 (work in progress), 832 December 2009. 834 [I-D.ietf-behave-v6v4-xlate] 835 Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 836 Algorithm", draft-ietf-behave-v6v4-xlate-05 (work in 837 progress), December 2009. 839 [I-D.ietf-behave-v6v4-xlate-stateful] 840 Bagnulo, M., Matthews, P., and I. Beijnum, "NAT64: Network 841 Address and Protocol Translation from IPv6 Clients to IPv4 842 Servers", draft-ietf-behave-v6v4-xlate-stateful-07 (work 843 in progress), December 2009. 845 [RFC0768] Postel, J., "User Datagram Protocol", STD 6, RFC 768, 846 August 1980. 848 [RFC0791] Postel, J., "Internet Protocol", STD 5, RFC 791, 849 September 1981. 851 [RFC0793] Postel, J., "Transmission Control Protocol", STD 7, 852 RFC 793, September 1981. 854 [RFC1035] Mockapetris, P., "Domain names - implementation and 855 specification", STD 13, RFC 1035, November 1987. 857 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 858 Requirement Levels", BCP 14, RFC 2119, March 1997. 860 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 861 (IPv6) Specification", RFC 2460, December 1998. 863 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 864 (SIIT)", RFC 2765, February 2000. 866 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 867 Translation - Protocol Translation (NAT-PT)", RFC 2766, 868 February 2000. 870 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 871 via IPv4 Clouds", RFC 3056, February 2001. 873 [RFC3171] Albanna, Z., Almeroth, K., Meyer, D., and M. Schipper, 874 "IANA Guidelines for IPv4 Multicast Address Assignments", 875 BCP 51, RFC 3171, August 2001. 877 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 878 for IPv6 Hosts and Routers", RFC 4213, October 2005. 880 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 881 Architecture", RFC 4291, February 2006. 883 [RFC4380] Huitema, C., "Teredo: Tunneling IPv6 over UDP through 884 Network Address Translations (NATs)", RFC 4380, 885 February 2006. 887 [RFC4607] Holbrook, H. and B. Cain, "Source-Specific Multicast for 888 IP", RFC 4607, August 2006. 890 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 891 (CIDR): The Internet Address Assignment and Aggregation 892 Plan", BCP 122, RFC 4632, August 2006. 894 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 895 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 896 March 2008. 898 14.2. Informative References 900 [BEHAVE] "The IETF Behave Working Group Charter: 901 http://www.ietf.org/html.charters/behave-charter.html/". 903 [CERNET] "CERNET Homepage: 904 http://www.edu.cn/english_1369/index.shtml". 906 [CNGI-CERNET2] 907 "CNGI-CERNET2 Homepage: 908 http://www.cernet2.edu.cn/index_en.htm". 910 [COUNT] "IPv4 address count down: http://penrose.uk6x.com/". 912 [DNS] "Source Code of the IVI DNS 913 http://www.ivi2.org/IVI/src/ividns-0.1.tar.gz/". 915 [LINUX] "Source Code of the IVI implementation for Linux: 916 http://linux.ivi2.org/impl/". 918 [RFC2775] Carpenter, B., "Internet Transparency", RFC 2775, 919 February 2000. 921 [RFC3142] Hagino, J. and K. Yamamoto, "An IPv6-to-IPv4 Transport 922 Relay Translator", RFC 3142, June 2001. 924 [RFC3484] Draves, R., "Default Address Selection for Internet 925 Protocol version 6 (IPv6)", RFC 3484, February 2003. 927 [RFC3569] Bhattacharyya, S., "An Overview of Source-Specific 928 Multicast (SSM)", RFC 3569, July 2003. 930 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 931 Address Translator - Protocol Translator (NAT-PT) to 932 Historic Status", RFC 4966, July 2007. 934 [TEST4] "Test homepage for the IVI4(i): http://202.38.114.1/". 936 [TEST6] "Test homepage for the IVI6(i): 937 http://[2001:250:ffca:2672:0100::0]/". 939 Authors' Addresses 941 Xing Li 942 CERNET Center/Tsinghua University 943 Room 225, Main Building, Tsinghua University 944 Beijing 100084 945 CN 947 Phone: +86 62785983 948 Email: xing@cernet.edu.cn 949 Congxiao Bao 950 CERNET Center/Tsinghua University 951 Room 225, Main Building, Tsinghua University 952 Beijing 100084 953 CN 955 Phone: +86 62785983 956 Email: congxiao@cernet.edu.cn 958 Maoke Chen 959 CERNET Center/Tsinghua University 960 Room 225, Main Building, Tsinghua University 961 Beijing 100084 962 CN 964 Phone: +86 62785983 965 Email: mk@cernet.edu.cn 967 Hong Zhang 968 CERNET Center/Tsinghua University 969 Room 225, Main Building, Tsinghua University 970 Beijing 100084 971 CN 973 Phone: +86 62785983 974 Email: neilzh@gmail.com 976 Jianping Wu 977 CERNET Center/Tsinghua University 978 Room 225, Main Building, Tsinghua University 979 Beijing 100084 980 CN 982 Phone: +86 62785983 983 Email: jianping@cernet.edu.cn