idnits 2.17.1 draft-xu-behave-ivit-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 1 character in excess of 72. == There are 18 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 3 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 7 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 352 has weird spacing: '...v4 host pad...' -- The document date (July 6, 2009) is 5380 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- -- Looks like a reference, but probably isn't: '1' on line 93 -- Looks like a reference, but probably isn't: '2' on line 101 -- Looks like a reference, but probably isn't: '3' on line 116 -- Looks like a reference, but probably isn't: '4' on line 128 -- Looks like a reference, but probably isn't: '5' on line 129 -- Looks like a reference, but probably isn't: '6' on line 129 == Unused Reference: 'RFC2119' is defined on line 531, but no explicit reference was found in the text == Unused Reference: 'RFC2765' is defined on line 534, but no explicit reference was found in the text == Unused Reference: 'RFC2766' is defined on line 537, but no explicit reference was found in the text == Unused Reference: 'RFC5214' is defined on line 541, but no explicit reference was found in the text == Unused Reference: 'RFC3056' is defined on line 545, but no explicit reference was found in the text == Unused Reference: 'RFC3068' is defined on line 548, but no explicit reference was found in the text == Unused Reference: 'RFC4966' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'I-D.xli-behave-ivi' is defined on line 557, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2765 (Obsoleted by RFC 6145) ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) == Outdated reference: A later version (-07) exists of draft-xli-behave-ivi-02 Summary: 5 errors (**), 0 flaws (~~), 14 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Xu 3 Internet-Draft C. Xia 4 Intended status: Experimental X. Li 5 Expires: January 7, 2010 Y. Cui 6 J. Wu 7 Tsinghua University 8 July 6, 2009 10 IVIT(IVI+Tunnel) 11 draft-xu-behave-ivit-00 13 Status of this Memo 15 This Internet-Draft is submitted to IETF in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on January 7, 2010. 36 Copyright Notice 38 Copyright (c) 2009 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents in effect on the date of 43 publication of this document (http://trustee.ietf.org/license-info). 44 Please review these documents carefully, as they describe your rights 45 and restrictions with respect to this document. 47 Abstract 49 This document proposes a mechanism, IVIT (IVI+Tunnel), to support 50 non-IVI IPv6 hosts to communicate with IPv4 hosts, and vice versa. 51 IVIT combines IVI translation and Tunnel methods with the IVI 52 translation at the core and the tunnel at the edge. In this 53 document, IVIT provides two modes. One is the dual-stack host mode, 54 which supports the communication between a dual-stack host in an IPv4 55 network and a non-IVI IPv6 host, especially the communication 56 scenario between a dual-stack server in an IPv4 network and a non-IVI 57 IPv6 host. The other is the CPE mode, which supports the 58 communication between an IPv4-only host and a non-IVI IPv6 host, 59 especially the bidirectional communication scenario between a private 60 IPv4 network and a non-IVI IPv6 network. Combined with IVI, IVIT can 61 support the communication between IPv4 networks and IPv6 networks 62 statelessly at the core. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Dual-Stack Host Mode . . . . . . . . . . . . . . . . . . . . . 6 68 2.1. Basic Idea of the Dual-Stack Host Mode . . . . . . . . . . 6 69 2.2. The IPv6 Address Format of the Dual-stack Host . . . . . . 6 70 2.3. Upgrade of an IPv4 Host . . . . . . . . . . . . . . . . . 7 71 2.4. Application Scenarios . . . . . . . . . . . . . . . . . . 7 72 2.5. The Communication Process . . . . . . . . . . . . . . . . 7 73 2.6. An Example . . . . . . . . . . . . . . . . . . . . . . . . 8 74 3. CPE Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10 75 3.1. Basic Idea of the CPE Mode . . . . . . . . . . . . . . . . 10 76 3.2. CPE Modified Operation . . . . . . . . . . . . . . . . . . 10 77 3.3. The Mapping Rule between the CPE IPv6 address and the 78 IPv4 only address . . . . . . . . . . . . . . . . . . . . 10 79 3.4. Application Scenarios . . . . . . . . . . . . . . . . . . 11 80 3.5. The Communication Process . . . . . . . . . . . . . . . . 11 81 3.6. An Example . . . . . . . . . . . . . . . . . . . . . . . . 13 82 4. Integrated with IVI . . . . . . . . . . . . . . . . . . . . . 14 83 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 15 84 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 85 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 86 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 87 8.1. Normative References . . . . . . . . . . . . . . . . . . . 18 88 8.2. Informative References . . . . . . . . . . . . . . . . . . 18 89 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 91 1. Introduction 93 IVI[1] is a simple and stateless translation mechanism for resolving 94 the communication problem between an IPv6 network and an IPv4 95 network. In IVI, address translation and protocol translation are 96 adopted. In the address translation, IVI defines an address mapping 97 rule, as shown in Figure 1, where bits from 32 to 39 are all 98 identifiers of IVI, and bits from 40 to 71 are embedded global IPv4 99 space. Because the mapping is 1-to-1 mapping, IVI is stateless and 100 has the feature of end-to-end address transparency. The protocol 101 translation in IVI obeys SIIT[2]. 103 | 0 |32 |40 |72 127| 104 ------------------------------------------------------------------ 105 | |FF | | | 106 ------------------------------------------------------------------ 107 |<- IPv6 prefix ->| |<- IPv4 address ->|<- zero padding ->| 109 Figure 1: IVI Address Mapping Rule 111 IVI is simple and scalable. In IVI, the communication between the 112 IPv4 network and the IVI IPv6 network is stateless. But IVI can't 113 support the stateless communication between the non-IVI IPv6 network 114 and the IPv4 network. 116 NAT-PT[3] can support the stateful communication between the non-IVI 117 IPv6 network and the IPv4 network. However, NAT-PT has been 118 obsolete. The Non-IVI IPv6 networks account for a large proportion 119 of the total IPv6 networks. So providing a simple method to 120 communicate between a non-IVI IPv6 network and an IPv4 network is 121 important. 123 In this document, IVIT (IVI+Tunnel) mechanism is proposed for 124 supporting the communication between a non-IVI IPv6 network and an 125 IPv4 network. 127 The basic idea of IVIT is the combination of IVI and Tunnel, which 128 mixes IVI address mapping rule, ISATAP[4] tunnel mechanism and 6to4 129 [5][6]tunnel mechanism together. IVIT has two modes. One is dual- 130 stack host mode, in which IPv4-only hosts are upgraded to dual-stack 131 hosts which can support encapsulation and decapsulation. The dual- 132 stack host mode mainly borrows the idea from ISATAP tunnel mechanism 133 to construct the IPv6 in IPv4 tunnel between the dual-stack host in 134 an IPv4 network and the IVI gateway. The other is CPE mode. In this 135 mode, CPEs are upgraded from IPv4 only to dual-stack, and support 136 encapsulation/decapsulation and address mapping. The CPE mode uses 137 the 6to4 tunnel mechanism for reference to construct the tunnel 138 between the CPE and the IVI Gateway. Whichever mode, the IVI Gateway 139 has no change in the address and protocol translation. Of course, 140 IVI gateway needs to support tunnel encapsulation and decapsulation. 141 So IVIT is stateless at the core. 143 2. Dual-Stack Host Mode 145 2.1. Basic Idea of the Dual-Stack Host Mode 147 IPv4 network IPv6 network 148 /-----\ /-----\ 149 ( +-+ ) ------------- ( +-+ ) 150 ( |H|==)==========//=====>| IVI gateway |----//---------- ( |H| ) 151 ( +-+ ) ------------- ( +-+ ) 152 \-----/ \-----/ 153 a a 154 Dual-stack non-IVI 155 Host IPv6 156 Host 157 -------IPv6 in IPv4-----------> 158 Tunnel Tunnel 160 IPv6 in IPv4 Tunnel between the dual-stack host 161 in an IPv4 network and the IVI gateway 163 Figure 2: Dual-stack host mode 165 Figure 2 shows the basic idea of the dual-stack host mode. If a 166 dual-stack host in an IPv4 network communicates with a non-IVI IPv6 167 host, the dual-stack host firstly constructs the IPv6 packets where 168 the Src address is local IPv6 address and the Dst address is the IPv6 169 address of the non-IVI IPv6 host. For transmitting the IPv6 packets 170 over the IPv4 network, the IPv6 in IPv4 tunnel is built with the IVI 171 gateway and the dual-stack host as its endpoints. The IPv6 packets 172 are encapsulated into the IPv4 packets, which arrive at the IVI 173 gateway and are decapsulated into the IPv6 packets. The IVI gateway 174 forwards the IPv6 packets to the non-IVI IPv6 host. The reverse 175 communication is similar. 177 2.2. The IPv6 Address Format of the Dual-stack Host 179 In IVIT, we still use the IVI address mapping rule to assign or 180 configure the IPv6 address of the dual-stack host. But we change the 181 eight bits from 32 to 39 for differentiating IVI feature into eight 182 zeros to identify IVIT mapping, as shown in Figure 3. During the 183 communication, we can distinguish the IPv4 address from the IVI 184 address. 186 | 0 |32 |40 |72 127| 187 ------------------------------------------------------------------ 188 | |00 | | | 189 ------------------------------------------------------------------ 190 |<- IPv6 prefix ->| |<- IPv4 address ->|<- zero padding ->| 192 Figure 3: The IPv6 address format of the dual-stack host 194 2.3. Upgrade of an IPv4 Host 196 If an IPv4-only host wants to communicate with a non-IVI IPv6 host, 197 it must upgrade to a dual-stack host. In the dual-stack host, the 198 IPv6 address is assigned or configured as 2.2 format, so we can 199 extract the IPv4 address from the IPv6 address to build the IPv6 in 200 IPv4 tunnel automatically. In this mode, the modified host may 201 construct the IPv6 packets. Meanwhile, it must support 202 encapsulation/decapsulation in order to build the tunnel between the 203 dual-stack host and the IVI gateway. 205 2.4. Application Scenarios 207 The dual-stack host mode mainly supports the application scenarios of 208 a non-IVI IPv6 host accessing a dual-stack server. Giving an IPv4- 209 only server in an IPv4 network, the server might be accessed by all 210 IPv6 hosts if upgraded into dual-stack host mode. Of course, the 211 mode supports the communication between a dual-stack host in an IPv4 212 network and a non-IVI IPv6 server. 214 2.5. The Communication Process 216 Giving a communication between an IPv6 host and an IPv4-only host, if 217 the IPv6 host is an IVI IPv6 host, we take the IVI mechanism to 218 realize the communication. However, if the IPv6 host is a non-IVI 219 IPv6 host, we adopt the IVIT mechanism instead. That is to say, the 220 IVI and IVIT's integration may solve the communication problem 221 between an IPv4 network and an IPv6 network and ensure statelessness 222 at the core without DNS-ALG. In this section, we mainly give a 223 detailed description about the communication between a non-IVI Ipv6 224 host and a dual-stack host in an IPv4 network. 226 First of all, we describe the communication between a dual-stack host 227 in an IPv4 network and a non-IVI IPv6 host. If a non-IVI IPv6 host H 228 accesses a dual-stack server S in an IPv4 network, which is a main 229 application scenario of dual-stack host mode, S's IPv6 address is 230 according to 2.2 format. Meanwhile, S and the IVI gateway support 231 encapsulation/decapsulation. 233 The communication from H to S is as follows. H queries DNS server 234 for S address and DNS server returns the S's IPv6 address. Then, H 235 sends the IPv6 packets where Src IPv6 address is H's address and Dst 236 IPv6 address is S's IPv6 address of the dual-stack server to the IVI 237 gateway. The IVI gateway extracts the destination's IPv4 address 238 from the Dst IPv6 address and encapsulates the IPv6 packets into IPv4 239 packets since the eight bits from 32 to 39 are all zeros (IVIT ID), 240 where Src IPv4 address is IVI gateway's IPv4 address and Dst IPv4 241 address is S's IPv4 address obtained from the Dst IPv6 address, and 242 then forwards the IPv4 packets to S. S decapsulates the IPv4 packets 243 and hands the IPv6 packets to the upper layer. 245 The response is as follows. S constructs the IPv6 packets where Src 246 IPv6 address is local IPv6 address and Dst IPv6 address is H's 247 address. Then S encapsulates IPv6 packets into IPv4 packets where 248 Src IPv4 address is S's IPv4 address and Dst IPv4 address is IVI 249 gateway's IPv4 address, and then sends the IPv4 packets to IVI 250 gateway. IVI gateway decapsulates IPv4 packets and forwards the IPv6 251 packets to H. 253 If a dual-stack host H in an IPv4 network communicates with a non-IVI 254 IPv6 server S, H's IPv6 addresses are 2.2 format. H and IVI gateway 255 support encapsulation/decapsulation. The communication is as 256 follows. H queries DNS server for S address and DNS server returns 257 S's address. H constructs the IPv6 packets where Src IPv6 address is 258 local IPv6 address and Dst IPv6 address is S's address. Then H 259 encapsulates IPv6 packets into IPv4 packets where Src IPv4 address is 260 H's IPv4 address and Dst IPv4 address is IVI gateway's IPv4 address, 261 and sends the IPv4 packets to IVI gateway. IVI gateway decapsulates 262 the IPv4 packets and forwards the IPv6 packets to S. 264 The response is as follows. S sends the IPv6 packets where Src IPv6 265 address is S's address and Dst IPv6 address is H's IPv6 address. IVI 266 gateway encapsulates the IPv6 packets into IPv4 packets where Src 267 IPv4 address is IVI gateway's IPv4 address and Dst IPv4 address is 268 H's IPv4 address obtained from the Dst IPv6 address, and forwards the 269 IPv4 packets to H. H decapsulates the IPv4 packets and hands the IPv6 270 packets to the upper layer. 272 2.6. An Example 274 Suppose a non-IVI IPv6 host with the address 3FFE:3600:8::1 access a 275 dual-stack server in an IPv4 network whose IPv4 and IPv6 addresses 276 are 163.162.1.1 and 2001:da8:00a3:a201:0100::0/72, where 2001:da8 is 277 the ISP's IVI IPv6 prefix. The IVI gateway has the IPv4 address 278 140.125.1.3 and the IPv6 address 2001:da8:ff8c:7d01:0300::0/72(the 279 IVI address). The non-IVI IPv6 host sends the IPv6 packets where the 280 Src address is 3FFE:3600:8::1 and the Dst address is 2001:da8:00a3: 282 a201:0100::0/72. When the IPv6 packets arrive at the IVI gateway, 283 the IVI gateway encapsulates the IPv6 packets into the IPv4 packets 284 where the Src address is 140.125.1.1 and the Dst address is 285 163.162.1.1 obtained from the Dst IPv6 address. Then, forward the 286 IPv4 packets to the dual-stack server. The dual-stack server 287 receives these packets and decapsulates the IPv4 packets into the 288 IPv6 packets, then sends to the upper layer. 290 The response process is as follows. The dual-stack server sends the 291 IPv6 packets where Src address is 2001:da8:00a3:a201:0100::0/72 and 292 Dst address is 3FFE:3600:8::1. For transmitting the IPv6 packets in 293 the IPv4 network, the dual-stack server then encapsulates the IPv6 294 packets into the IPv4 packets where the Src address is 163.162.1.1 295 and the Dst address is 140.125.1.3. When the encapsulation packets 296 arrive at the IVI gateway, the IVI gateway decapsulates the packets 297 and gets the IPv6 packets. Then, the IVI gateway forwards the IPv6 298 packets to the destination 3FFE:3600:8::1. 300 3. CPE Mode 302 3.1. Basic Idea of the CPE Mode 304 The basic idea of the CPE Mode is similar to that of the dual-stack 305 host mode. But, in this mode, the IPv4-only host needs no change and 306 the CPE is modified into dual-stack and becomes the endpoint of the 307 tunnel. 309 3.2. CPE Modified Operation 311 In the CPE mode, the IPv4-only host has no change and the CPE is 312 upgraded to dual-stack. The modified CPE supports encapsulation/ 313 decapsulation and mapping. For mapping, the CPE has an IPv4 address 314 pool. The CPE maintains the mapping between the IPv6 host's IPv6 315 address and an IPv4 address in the IPv4 address pool. Since the IPv4 316 addresses mapped from the IPv6 host's IPv6 address are used locally, 317 private IPv4 addresses can be used to in the IPv4 address pool. The 318 IPv4 hosts' IPv4 addresses can also be private addresses. The IVI 319 extended IPv6 address of the dual-stack CPE is according to section 320 3.2. Constructing the IPv6 packets and establishing the tunnel on 321 the CPE resemble the dual-stack host mode. But there are some 322 differences as follows. 324 1) When an IPv4-only host wants to access an IPv6 host, the IPv4-only 325 host does DNS query and the DNS server returns the IPv6 address of 326 the IPv6 host. The CPE can capture the DNS response, and map the 327 IPv6 host's IPv6 address into one IPv4 address from the IPv4 address 328 pool, then send the IPv4 address to the IPv4-only host. The IPv4- 329 only host uses the IPv4 address as the Dst IPv4 address to construct 330 IPv4 packets. 332 2) When constructing the IPv6 packets, CPE uses the IVI extended IPv6 333 address as Src address, and uses the IPv6 address mapped from Dst 334 IPv4 address in IPv4 packets as Dst address. 336 3.3. The Mapping Rule between the CPE IPv6 address and the IPv4 only 337 address 339 We need a mapping rule between the CPE's IPv6 address and the IPv4- 340 only address in two cases. One is that the CPE translates the IPv4 341 packets into the IPv6 packets where the Src IPv6 address is created 342 by the mapping rule. The other is that an IPv6 address accesses a 343 private IPv4 address where the mapping rule is adopted to 344 differentiate the private IPv4 address from the Dst CPE IPv6 address. 345 The mapping rule is shown in Figure 4. 347 | 0 |32 |40 |72 |104 127| 348 ------------------------------------------------------------------ 349 | |00 | | | | 350 ------------------------------------------------------------------ 351 |<-IPv6 prefix->| |<-IPv4 address->|<-IPv4 address->|<- zero ->| 352 of CPE of the IPv4 host padding 354 Figure 4: The mapping rule between the IPv4 address and the CPE's 355 IPv6 address 357 In this 1-to-1 mapping, the bits from 72 to 103 are IPv4 address of 358 the IPv4-only host. Accordingly, we can identify the address of the 359 IPv4-only host from the CPE's IPv6 address. Meanwhile, the DNS 360 server creates a mapping in the DNS. For example, if the IPv4 361 address of an IPv4-only host is 10.10.20.1 and the CPE's IPv6 address 362 is 2001:da8:000A:0A0A:0100::0/72, the mapped IPv6 address is 2001: 363 da8:000A:0A0A:010A:0A14:0100::0/104. If another IPv4 address is 364 10.10.30.1, the mapped IPv6 address is 2001:da8:000A:0A0A:010A:0A1E: 365 0100::0/104. When the IPv6 address 2001:da8:000A:0A0A:010A:0A14: 366 0100::0/104 is received, we can map into the 10.10.20.1 IPv4 address. 367 And if the address 2001:da8:000A:0A0A:010A:0A1E:0100::0/104 is 368 received, we can map into the 10.10.30.1 IPv4 address. Contrarily, 369 if the address 10.10.30.1 is received, the CPE translates the IPv4 370 address into 2001:da8:000A:0A0A:010A:0A1E:0100::0/104. 372 3.4. Application Scenarios 374 The CPE mode supports the communication between an IPv4 network and 375 an IPv6 network, especially the bidirectional communications between 376 a private IPv4 host and a non-IVI IPv6 host. 378 3.5. The Communication Process 380 Giving a communication between an IPv6 host and an IPv4-only host, if 381 the IPv6 host is an IVI IPv6 host, we take the IVI mechanism to 382 realize the communication. However, if the IPv6 host is a non-IVI 383 IPv6 host, we adopt the IVIT mechanism instead. That is to say, the 384 IVI and IVIT's integration may solve the communication problem 385 between an IPv4 network and an IPv6 network, and ensure statelessness 386 at the core without DNS-ALG. In this section, we mainly give a 387 detailed description about the communication between a non-IVI Ipv6 388 host and a private IPv4 host in an IPv4 network. 390 If a private IPv4 host H accesses a non-IVI IPv6 server S, the 391 communication process is as follows. H queries the Dst address from 392 DNS server. At first, H sends the query packets, and DNS server 393 returns the S's address to CPE. CPE then receives the returned 394 packets and identifies that the address is an IPv6 address and 395 extracts an IPv4 address from the address pool to map the IPv6 396 address, and then returns the selected IPv4 address to H. H sends the 397 IPv4 packets where the src address is local address and the Dst 398 address is the mapped IPv4 address from the CPE. The CPE receives 399 the IPv4 packets, constructs the IPv6 packets where Src IPv6 address 400 is obtained from the mapping rule described in Section 3.3 and the 401 Dst IPv6 address is S's address (query the mapping list, get the 402 corresponding IPv6 address from the Dst IPv4 address in the IPv4 403 packets). CPE encapsulates IPv6 packets into IPv4 packets where Src 404 IPv4 address is CPE's IPv4 address and Dst IPv4 address is IVI 405 gateway's IPv4 address and sends the IPv4 packets to IVI gateway. 406 IVI gateway decapsulates IPv4 packets and forwards the IPv6 packets 407 to S. 409 The responding packets are as follows. S sends the IPv6 packets 410 where Src IPv6 address is S's address and Dst IPv6 address is the 411 received IPv6 address to IVI gateway. IVI gateway encapsulates the 412 IPv6 packets into IPv4 packets where Src IPv4 address is IVI 413 gateway's IPv4 address and Dst IPv4 address is CPE's IPv4 address 414 obtained from the Dst Ipv6 address, and forwards the IPv4 packets to 415 CPE. CPE decapsulates the IPv4 packets, translates the IPv6 packets 416 into the IPv4 packets(query the mapping table, use the mapping rule 417 described in Section 3.3 and get the corresponding address 418 information) and sends the IPv4 packets to H. 420 If a non-IVI IPv6 host H communicates with a private IPv4 server S in 421 an IPv4 network. The communication is as follows. At first, H 422 queries the address information of S. DNS server returns the IPv6 423 address according to the mapping rule described in Section 3.3. H 424 receives the response and sends the IPv6 packets where Src IPv6 425 address is H's address and Dst IPv6 address is the returned IPv6 426 address to IVI gateway. IVI gateway encapsulates the IPv6 packets 427 into IPv4 packets where Src IPv4 address is IVI gateway's IPv4 428 address and Dst IPv4 address is CPE's IPv4 address, and forwards the 429 IPv4 packets to CPE. CPE decapsulates the IPv4 packets, translates 430 the IPv6 packets into the IPv4 packets and sends the IPv4 packets to 431 S. 433 The responding packets are as follows. S sends the IPv4 packets 434 according to the sent address information. CPE constructs the IPv6 435 packets according to the address mapping table. Then CPE 436 encapsulates IPv6 packets into IPv4 packets where Src IPv4 address is 437 CPE's IPv4 address and Dst IPv4 address is IVI gsteway's IPv4 438 address, and sends the IPv4 packets to IVI gateway. IVI gateway 439 decapsulates IPv4 packets and forwards the IPv6 packets to H. 441 3.6. An Example 443 Suppose a non-IVI IPv6 host with the address 3FFE:3600:8::1 444 communicates with a private IPv4-only host whose IP address is 445 10.10.20.3. In this communication, the IP addresses of the 446 corresponding CPE are 163.162.1.1 and 2001:da8:00a3:a201:0100::0/72. 447 The CPE establishes the mapping 192.168.5.12<->3FFE:3600:8::1. The 448 IVI gateway has the IPv4 address 140.125.1.3 and the IPv6 address 449 2001:da8:ff8c:7d01:0300::0/72(the IVI address). 451 Firstly, the non-IVI IPv6 host queries the Dst IP address, and DNS 452 server returns the IPv6 address 2001:da8:00a3:a201:010A:0A14:0300::0/ 453 104. The IPv6 host sends the IPv6 packets where the Src address is 454 3FFE:3600:8::1 and the Dst address is 2001:da8:00a3:a201:010A:0A14: 455 0300::0/104. When the IPv6 packets arrive at the IVI gateway, it 456 encapsulates the IPv6 packets into the IPv4 packets where the Src 457 address is 140.125.1.1 and the Dst address is 163.162.1.1 obtained 458 from the Dst IPv6 address, and forwards the IPv4 Packets to the dual- 459 stack CPE. The dual-stack CPE receives these packets and 460 decapsulates the IPv4 packets into the IPv6 packets where the Src 461 address is 3FFE:3600:8::1 and the Dst address is 2001:da8:00a3:a201: 462 010A:0A14:0300::0/104. Then the CPE queries the mapping table bases 463 on the mapping rule described in Section 4.2, and obtains the 464 corresponding mapping. At last, it sends the IPv4 packets where the 465 src address is 192.168.5.12 and the dst address is 10.10.20.3 to the 466 private IPv4 server. 468 The response process is as follows. The private IPv4 server sends 469 the IPv4 packets where the Src address is 10.10.20.1 and the Dst 470 address is 192.168.5.12. The dual-stack CPE receives the IPv4 471 packets and constructs the IPv6 packets where the Src address is 472 2001:da8:00a3:a201:010A:0A14:0300::0/104, and the Dst address is 473 3FFE:3600:8::1. For transmitting the IPv6 packets in the IPv4 474 network, the dual-stack CPE then encapsulates the IPv6 packets into 475 the IPv4 packets where the Src address is 163.162.1.1 and the Dst 476 address is 140.125.1.3. When the encapsulation packets arrive at the 477 IVI gateway, it decapsulates the packets and gets the IPv6 packets. 478 Then, the IVI gateway forwards the translated IPv6 packets to the Dst 479 address 3FFE:3600:8::1. 481 4. Integrated with IVI 483 Owing to IVIT, the IVI gateway must identify IVIT from IVI. The 484 identification mechanism should be adopted in The IVI gateway. In 485 the identification mechanism, the operation of the IVI gateway should 486 be classified into the following two cases. 488 1) When the IVI gateway receives the IPv6 packets, if the dst address 489 in the IPv6 packets is an IVI IPv6 address, the IVI gateway 490 implements the IVI function, if the dst address isn't an IVI IPv6 491 address, the IVI gateway implements the IVIT function. 493 2) When the IVI gateway receives the IPv4 packets, if the dst address 494 in the IPv4 packets isn't the IVI gateway's address, the IVI gateway 495 implements the IVI function, if the dst address is the IVI gateway's 496 address, the IVI gateway implements the IVIT function. 498 5. Conclusion 500 In this draft, we proposed an IVI+Tunnel mechanism to solve the 501 communication problem between a non-IVI IPv6 network and an IPv4 502 network. IVIT has evident advantages in the following three aspects. 504 1) In the dual-stack host mode, all IPv6 hosts may access the dual- 505 stack servers in an IPv4 network. 507 2) In the CPE mode, the address pool of a CPE may use the private 508 addresses, which saves more global IPv4 addresses. 510 3) In the CPE mode, IVIT may support the bidirectional communication 511 between a private IPv4 network and an IPv6 network. 513 Integrating IVI and IVIT may resolve the communication problem 514 between an IPv4 network and an IPv6 network. IVI and IVIT union is 515 stateless at the core and without DNS-ALG related issues. So IVIT 516 has high scalability and effectiveness. 518 6. Security Considerations 520 This document presents IVIT (IVI+Tunnel) for the communication 521 between an IPv4 network and a non-IVI IPv6 network. The IPv4 522 security and IPv6 security issues should be addressed using related 523 documents of each address family and are not included in this 524 document. 526 7. IANA Considerations 527 8. References 529 8.1. Normative References 531 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 532 Requirement Levels", BCP 14, RFC 2119, March 1997. 534 [RFC2765] Nordmark, E., "Stateless IP/ICMP Translation Algorithm 535 (SIIT)", RFC 2765, February 2000. 537 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 538 Translation - Protocol Translation (NAT-PT)", RFC 2766, 539 February 2000. 541 [RFC5214] Templin, F., Gleeson, T., and D. Thaler, "Intra-Site 542 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 543 March 2008. 545 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 546 via IPv4 Clouds", RFC 3056, February 2001. 548 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 549 RFC 3068, June 2001. 551 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 552 Address Translator - Protocol Translator (NAT-PT) to 553 Historic Status", RFC 4966, July 2007. 555 8.2. Informative References 557 [I-D.xli-behave-ivi] 558 Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 559 CERNET IVI Translation Design and Deployment for the IPv4/ 560 IPv6 Coexistence and Transition", draft-xli-behave-ivi-02 561 (work in progress), June 2009. 563 Authors' Addresses 565 Mingwei Xu 566 Tsinghua University 567 Department of Computer Science, Tsinghua University 568 Beijing 100084 569 P.R.China 571 Phone: +86-10-6278-5822 572 Email: xmw@csnet1.cs.tsinghua.edu.cn 574 Chunmei Xia 575 Tsinghua University 576 Department of Computer Science, Tsinghua University 577 Beijing 100084 578 P.R.China 580 Phone: +86-10-6278-5822 581 Email: xcm1977@sina.com 583 Xing Li 584 Tsinghua University 585 Department of Electronic Engineering, Tsinghua University 586 Beijing 100084 587 P.R.China 589 Phone: +86-10-6278-5983 590 Email: xing@cernet.edu.cn 592 Yong Cui 593 Tsinghua University 594 Department of Computer Science, Tsinghua University 595 Beijing 100084 596 P.R.China 598 Phone: +86-10-6278-5822 599 Email: cuiyong@tsinghua.edu.cn 600 Jianping Wu 601 Tsinghua University 602 Department of Computer Science, Tsinghua University 603 Beijing 100084 604 P.R.China 606 Phone: +86-10-6278-5983 607 Email: jianping@cernet.edu.cn