idnits 2.17.1 draft-sun-behave-v4tov6-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack a Security Considerations section. ** There are 36 instances of too long lines in the document, the longest one being 9 characters in excess of 72. ** The abstract seems to contain references ([RFC6144]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. == There are 1 instance of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. == There are 1 instance 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 == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 29, 2013) is 3922 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2766' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 370, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2766 (Obsoleted by RFC 4966) ** Downref: Normative reference to an Informational RFC: RFC 4966 ** Downref: Normative reference to an Informational RFC: RFC 6144 ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) ** Obsolete normative reference: RFC 6156 (Obsoleted by RFC 8656) ** Downref: Normative reference to an Informational RFC: RFC 6219 Summary: 9 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Xie 3 Internet-Draft Q. Sun 4 Intended status: Standards Track Q. He 5 Expires: January 30, 2014 China Telecom 6 C. Zhou 7 Huawei Technologies 8 X. Li 9 C. Bao 10 CERNET Center/Tsinghua 11 University 12 July 29, 2013 14 The Approach for IPv4-only users to access IPv6-only Content 15 draft-sun-behave-v4tov6-01 17 Abstract 19 Current approaches can not solve the scenario that the users from 20 IPv4 Internet to access IPv6-only content. When IPv6 content are 21 becoming more and more popular, it is important to ensure that IPv6- 22 only content can be reachable from legacy IPv4-only clients via some 23 IPv4-only network. This document proposes two approaches for IPv4- 24 only users to access IPv6-only content. It is designed to cover the 25 Scenario 2 in [RFC6144]. 27 Status of this Memo 29 This Internet-Draft is submitted 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). Note that other groups may also distribute 34 working documents as Internet-Drafts. The list of current Internet- 35 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on January 30, 2014. 44 Copyright Notice 46 Copyright (c) 2013 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the Simplified BSD License. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 3. The NAT46 translator for IPv4 Internet to access IPv6 64 network . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 65 4. Approach 1: DNS-based solution . . . . . . . . . . . . . . . . 4 66 5. Approach 2: Redirect-based Solution . . . . . . . . . . . . . . 6 67 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 8 68 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 8 69 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 8 70 8.1. Normative References . . . . . . . . . . . . . . . . . . . 8 71 8.2. Informative References . . . . . . . . . . . . . . . . . . 9 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 9 74 1. Introduction 76 In [RFC6144], Scenario 2 is an important use case. Not only could 77 servers move directly to IPv6 without trudging through a difficult 78 transition period, but they could do so without risk of losing 79 connectivity with the IPv4-only Internet. 81 Existing solutions have not solved this scenario well. NAT- 82 PT[RFC2766]can be used in this scenario, but it requires a tightly 83 coupled DNS Application Level Gateway (ALG) in the translator, and 84 have been deprecated by the IETF [RFC4966]. The stateless 85 translation solution [RFC6219] can work too, but since each IPv6 86 server will consume one IPv4 public address, it is not suitable to 87 deploy in situation that operators are running out of IPv4 address. 88 [RFC6156] can be used for IPv4 client to communicate with IPv6 89 client. But this requires the IPv4 client and IPv6 client to 90 implement a TURN client. Therefore, it is not suitable for 91 C-S(Client-Server) and B-S (Browser-Server) mode. 93 [I-D.rfvlb-behave-v6-content-for-v4-clients] can work for IPv4-only 94 user to access IPv6 content. But since it uses private IPv4 address 95 to mapping the IPv6 server, it can only be used for IPv4 network to 96 reach IPv6 network. 98 This document is designed for IPv4 Internet to reach IPv6 network. 99 There are several requirements in this design: 101 1.Considering IPv4 address has been a scarce resource, the amount 102 of public IPv4 addresses consumed by the translator should be less 103 than that the number of IPv6 servers in the IPv6 network. 105 2. It should not require extra modifications on the server, e.g. 106 by using a dynamic port number, implementing TURN client, etc. 108 In this document, we propose two approaches for this scenario. These 109 two approaches can make use of existing DNS architecture. The 110 binding table in these two approaches are static. Therefore, there 111 will be no dynamic issue as in NAT-PT or DNS cache syncronization. 113 2. Terminology 115 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 116 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 117 document are to be interpreted as described in [RFC2119]. 119 Terminology defined in [RFC6144] is used extensively in this 120 document. Besides, this document uses the following terminologies: 122 IPv6-converted addresses: IPv4 addresses used to represent IPv6 nodes 123 in an IPv4 Internet. They have an explicit mapping relationship to 124 IPv6 addresses. 126 NAT46: a stateful IPv4/IPv6 translation functionality. It is 127 consistent with IP/ICMP translation [RFC6145], and can also support 128 IPv6-converted address selection and binding table maintenance. 130 3. The NAT46 translator for IPv4 Internet to access IPv6 network 132 The NAT46 solution is used for IPv4 clients in IPv4 Internet to reach 133 IPv6 servers (depicted in Figure 1). 135 ------- ------ 136 // \\ Address Pool: // \\ 137 / \ {210.0.0.0/20, / \ 138 23.0.0.1 | | 213.0.1.0/18...} | | 2001:c61::1 139 +---------+ | The IPv4 | +-----------------+ | The IPv6 | +--------+ 140 | IPv4 | | Internet | | Translator | | Network | | IPv6 | 141 | Client |--+ +-| (NAT46) |----+ +--| Server | 142 +---------+ | | +-----------------+ | | +--------+ 143 \ / Prefix:2001:c68::/96 \ / 144 \\ // \\ // 145 ------- ------ 147 Figure 1: Overall solution for IPv4 Internet to IPv6 network 149 In order to achieve the translation initiated from IPv4 side, two 150 addresses need to be determined by NAT46 translator. The first one 151 is the IPv6-converted address of the IPv6 server, which is is 152 selected from the IPv4 address pool configured in NAT46. The second 153 one is the IPv4-converted address for the IPv4 client, which can be 154 synthetized using the stateless approach defined in [RFC6052]. 156 In our approach, the mapping relationship between IPv6-converted 157 address and the IPv6 address for the server is pre-determined in 158 advance. As a result, the A record in the DNS server for a 159 particular server is always the same for different IPv4 clients. 161 4. Approach 1: DNS-based solution 163 This approach is independent of translated protocol. For 164 applications without DNS process can not be solved by this approach. 165 In order to support IPv4 address sharing for multiple IPv6 servers, 166 one IPv4 address can be shared by multiple servers with different 167 service ports. If there are too many servers with the same service 168 port, the second approach can be used as a complement. 170 The overall solution is depicted in Figure 3. 172 ------- +---------------+ ------ 173 // \\ | +-----------+ | // \\ 174 / \ | | DNS | | / \ 175 +---------+ | The IPv4 | | +-----------+ | | The IPv6 | +--------+ 176 | IPv4 | | Internet | | | | Network | | IPv6 | 177 | Client |--+ +-| +--------+ |--+ +--| Server | 178 +---------+ | | | | NAT46 | | | | +--------+ 179 \ / | +--------+ | \ / 180 \\ // +---------------+ \\ // 181 ------- ------ 183 Figure 2: DNS-based approach 185 It consists of several functionalities: 187 1.NAT46: This functionality achieves the translation between IPv4 188 packet and IPv6 packet. It is consistent with [RFC6145]. Besides, 189 it maintained the binding table including the IPv6 server address, 190 IPv6-converted address for IPv6 server, and the service port 191 statically. 193 2.DNS: The DNS server is configured with the IPv6-converted address 194 as the A record for IPv6 server. 196 The workflow of this apporach is as follows: 198 +--------+ +--------+ +--------+ +--------+ 199 | IPv4 | | DNS | | NAT46 | | IPv6 | 200 | Client | | | | | | Server | 201 +--------+ +--------+ +--------+ +--------+ 202 | | | | 203 |DNS A record query| | | 204 | ipv6.example.com | | | 205 |----------------->| | | 206 | | | | 207 | return A record | | | 208 |<-----------------| | | 209 | IPv4 traffic | Lookup the | 210 |----------------------------------->| Binding Table | 211 | | IPv6 Traffic | 212 | |-------------->| 213 | IPv4 traffic(Returned) |<--------------| 214 |<-----------------------------------| | 215 Figure 3: Workflow of DNS-based approach 217 1. An IPv4 client initiates a DNS query for A record (e.g. 218 ipv6.example.com). 220 2. DNS receives the query. As it is configured with the IPv6- 221 converted address in advance, the A record will be returned to the 222 IPv4 client. 224 3. IPv4 client sends IPv4 traffic with the returned IPv6-converted 225 address as the destination address. 227 4. When the IPv4 traffic arrives at the NAT46, NAT46 extracts the 228 destination address and destination port in the IPv4 traffic. It 229 will lookup the binding table maintained in NAT46 and NAT46 230 translates the IPv4 packet to IPv6 packet according to [RFC6145]. No 231 port translation will be performed here. 233 5. The return traffic is treated in the same way. 235 5. Approach 2: Redirect-based Solution 237 This approach is designed for HTTP application. It will have a high 238 address sharing ratio. In HTTP, since the traffic can be redirected 239 to a different service port, it is able to achieve address sharing 240 for IPv6 servers by using different ports (denoted as IPv6-converted 241 port). Therefore, one IPv4 address can support up to thousands of 242 IPv6 servers in theory. 244 The overall solution is depicted in Figure 4. 246 ------- +--------------------+ ------ 247 // \\ | +----------------+ | // \\ 248 / \ | |Redirect Server | | / \ 249 +---------+ | The IPv4 | | +----------------+ | | The IPv6 | +--------+ 250 | IPv4 | | Internet | | | | Network | | IPv6 | 251 | Client |--+ +-| +------------+ |--+ +--| Server | 252 +---------+ | | | | NAT46 | | | | +--------+ 253 \ / | +------------+ | \ / 254 \\ // +--------------------+ \\ // 255 ------- ------ 257 Figure 4: Redirect-based Solution 259 It consists of several functionalities: 261 1. NAT46: This functionality is basically the same as the first 262 approach, except for the binding table includes IPv6 server address, 263 IPv6 service port, IPv6-converted address and IPv6-converted port. 265 2. Redirect Server: A Redirect server is used to redirect traffic to 266 a different IPv6-converted address and IPv6-converted port. The 267 redirect server may either store the binding table, or query for the 268 redirected address and port from NAT46. 270 The workflow of this apporach is as follows: 272 +--------+ +--------+ +--------+ +--------+ +--------+ 273 | IPv4 | | DNS | |Redirect| | NAT46 | | IPv6 | 274 | Client | | | | Server | | | | Server | 275 +--------+ +--------+ +--------+ +--------+ +--------+ 276 | | | | | 277 | DNS A request | | | | 278 | ipv6.example.com | | | | 279 |----------------->| | | | 280 | A response with | | | | 281 | Redirect Ser Addr| | | | 282 |<-----------------| | | | 283 | HTTP GET request, with domain name | | | 284 | in HOST field | Request for | | 285 |----------------------------------->| IPv4 Dst Addr | Setup mapping | 286 | |-------------->| table | 287 |return 302 not found, carry IPv4 dst| | | 288 |addr in HTTP redirect packet | | | 289 |<-----------------------------------| | | 290 | IPv4 HTTP request with new v4 dst addr | | 291 |--------------------------------------------------->| Translate to IPv6 | 292 | |------------------>| 293 | |<------------------| 294 |<---------------------------------------------------| | 296 Figure 5: Workflow of Proxy-lite Approach 298 1. An IPv4 client initiates a DNS query for A record (e.g. 299 ipv6.example.com). 301 2. In DNS server, the address of the redirect server is configured 302 as the A record for ipv6.example.com and returns to the IPv4 client. 304 3. The IPv4 client sends HTTP GET request. The domain name (e.g. 305 ipv6.example.com) is carried in HOST field. 307 4. The redirect server interprets the domain name, and sends the 308 request to get IPv6-converted address to NAT46 (carrying the address 309 of IPv4 client and the destination port). The specific protocol for 310 the request is now out of scope. 312 5. NAT46 selects IPv6-converted address and IPv6-converted port by 313 lookuping the binding table. It will also keep the destination port 314 in the binding table. 316 6. NAT46 returns the IPv6-converted address and IPv6-converted port 317 to redirect server and the redirect server in turn returns IPv6- 318 converted address in HTTP redirect packet with HTTP error "302 not 319 found". 321 7. IPv4 client replaces the destination IPv4 address with the 322 returned IPv6-converted address. The IPv4 traffic is routed to the 323 NAT46. 325 8. extracts the destination address and destination port in the IPv4 326 traffic. It will lookup the binding table maintained in NAT46 and 327 NAT46 translates the IPv4 packet to IPv6 packet according to 328 [RFC6145]. 330 6. IANA Considerations 332 No requirement on IANA. 334 7. Acknowledgements 336 The authors would like to thank Dan Wing, Fred Baker for their review 337 and comments. 339 8. References 341 8.1. Normative References 343 [I-D.rfvlb-behave-v6-content-for-v4-clients] 344 Rajtar, B., Farrer, I., Ales, V., Li, X., and C. Bao, 345 "Framework for accessing IPv6 content for IPv4-only 346 clients", draft-rfvlb-behave-v6-content-for-v4-clients-01 347 (work in progress), July 2013. 349 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 350 Requirement Levels", BCP 14, RFC 2119, March 1997. 352 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 353 Translation - Protocol Translation (NAT-PT)", RFC 2766, 354 February 2000. 356 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 357 Address Translator - Protocol Translator (NAT-PT) to 358 Historic Status", RFC 4966, July 2007. 360 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 361 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 362 October 2010. 364 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 365 IPv4/IPv6 Translation", RFC 6144, April 2011. 367 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 368 Algorithm", RFC 6145, April 2011. 370 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 371 NAT64: Network Address and Protocol Translation from IPv6 372 Clients to IPv4 Servers", RFC 6146, April 2011. 374 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 375 Using Relays around NAT (TURN) Extension for IPv6", 376 RFC 6156, April 2011. 378 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 379 China Education and Research Network (CERNET) IVI 380 Translation Design and Deployment for the IPv4/IPv6 381 Coexistence and Transition", RFC 6219, May 2011. 383 8.2. Informative References 385 Authors' Addresses 387 Chongfeng Xie 388 China Telecom 389 P.R.China 391 Phone: 86 10 58552116 392 Email: xiechf@ctbri.com.cn 393 Qiong Sun 394 China Telecom 395 P.R.China 397 Phone: 86 10 58552936 398 Email: sunqiong@ctbri.com.cn 400 Qi He 401 China Telecom 402 P.R.China 404 Phone: 86 10 58552332 405 Email: heqi@ctbri.com.cn 407 Cathy Zhou 408 Huawei Technologies 409 Bantian, Longgang District 410 Shenzhen 518129 411 P.R. China 413 Phone: 414 Email: cathy.zhou@huawei.com 416 Xing Li 417 CERNET Center/Tsinghua University 418 Room 225, Main Building 419 Beijing 100084 420 P.R.China 422 Phone: +86 10 6278 5983 423 Email: xing@cernet.edu.cn 425 Congxiao Bao 426 CERNET Center/Tsinghua University 427 Room 225, Main Building 428 Beijing 100084 429 P.R.China 431 Phone: +86 10 6278 5983 432 Email: congxiao@cernet.edu.cn