idnits 2.17.1 draft-sun-v4tov6-00.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 27 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. 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 (October 21, 2013) is 3834 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 291, but no explicit reference was found in the text == Unused Reference: 'RFC6146' is defined on line 309, 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 (~~), 4 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: April 24, 2014 China Telecom 6 C. Zhou 7 Huawei Technologies 8 X. Li 9 C. Bao 10 CERNET Center/Tsinghua 11 University 12 October 21, 2013 14 4to6: The Approach for IPv4-only users to access IPv6-only Content 15 draft-sun-v4tov6-00 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 an approach for IPv4-only 24 users to access IPv6-only content, and can also achieve address 25 sharing in the server side. It is designed to cover the Scenario 2 26 in [RFC6144]. 28 Status of this Memo 30 This Internet-Draft is submitted in full conformance with the 31 provisions of BCP 78 and BCP 79. 33 Internet-Drafts are working documents of the Internet Engineering 34 Task Force (IETF). Note that other groups may also distribute 35 working documents as Internet-Drafts. The list of current Internet- 36 Drafts is at http://datatracker.ietf.org/drafts/current/. 38 Internet-Drafts are draft documents valid for a maximum of six months 39 and may be updated, replaced, or obsoleted by other documents at any 40 time. It is inappropriate to use Internet-Drafts as reference 41 material or to cite them other than as "work in progress." 43 This Internet-Draft will expire on April 24, 2014. 45 Copyright Notice 47 Copyright (c) 2013 IETF Trust and the persons identified as the 48 document authors. All rights reserved. 50 This document is subject to BCP 78 and the IETF Trust's Legal 51 Provisions Relating to IETF Documents 52 (http://trustee.ietf.org/license-info) in effect on the date of 53 publication of this document. Please review these documents 54 carefully, as they describe your rights and restrictions with respect 55 to this document. Code Components extracted from this document must 56 include Simplified BSD License text as described in Section 4.e of 57 the Trust Legal Provisions and are provided without warranty as 58 described in the Simplified BSD License. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . . 4 64 3. Overall solution architecture for IPv4 Internet to access 65 IPv6 network . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 4. The Workflow of 4to6 Solution . . . . . . . . . . . . . . . . . 5 67 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 7 68 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 7 69 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 7 70 7.1. Normative References . . . . . . . . . . . . . . . . . . . 7 71 7.2. Informative References . . . . . . . . . . . . . . . . . . 8 72 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 8 74 1. Introduction 76 Currently, IPv4 addresses for servers are also facing address 77 shortage problem. When IPv4 addresses are becoming a more scarce 78 resource, it will cost more for content providers to keep using so 79 many IPv4 addresses as today. Besides, the upcoming new 80 applications, e.g. cloud computing, etc., are consuming more and more 81 IPv4 addresses. Therefore, it is better for content provider to 82 upgrade to IPv6 directly. 84 Scenario 2 in [RFC6144] is important for this use case. Not only 85 could servers move directly to IPv6 without trudging through a 86 difficult transition period, but they could do so without risk of 87 losing connectivity with the IPv4-only Internet. In addition, when 88 address sharing can be achieved, the content providers can further 89 save money by requiring less IPv4 addresses and reduce the 90 operational complexity by using IPv6 single-stack servers. For Data 91 Center Operators, they can offer service to more ICPs with limited 92 IPv4 addresses. 94 There are several requirements in the design: 96 1.Considering IPv4 address has been a scarce resource, the amount 97 of public IPv4 addresses consumed by the translator should be less 98 than that the number of IPv6 servers in the IPv6 network. 100 2. It should not require extra modifications on the server-side 101 and on the client-side, e.g. by using a dynamic port number in the 102 server, implementing a TURN client, etc. 104 3. It should not require modification on existing DNS 105 architecture. Otherwise, it would be difficult to deploy in 106 reality. 108 Existing solutions have not solved this scenario well. NAT- 109 PT[RFC2766]can be used in this scenario, but it requires a tightly 110 coupled DNS Application Level Gateway (ALG) in the translator, and 111 have been deprecated by the IETF [RFC4966]. The stateless 112 translation solution [RFC6219] can work too, but since each IPv6 113 server will consume one IPv4 public address, it is not suitable to 114 deploy in situation that operators are running out of IPv4 address. 115 [RFC6156] can be used for IPv4 client to communicate with IPv6 116 client. But this requires the IPv4 client and IPv6 client to 117 implement a TURN client. Therefore, it is not suitable for 118 C-S(Client-Server) and B-S (Browser-Server) mode. 120 [I-D.rfvlb-behave-v6-content-for-v4-clients] can work for IPv4-only 121 user to access IPv6 content. But since it uses private IPv4 address 122 to mapping the IPv6 server, it can only be used for IPv4 network to 123 reach IPv6 network. 125 This document is designed for IPv4 Internet to reach IPv6 network. 126 It is not a new protocol, but just to make use of existing protocols 127 and funtionalities. It can achieve high IPv4 address sharing ratio 128 for IPv6 servers, and there is no impact on the server/client and 129 existing DNS architecture. 131 2. Terminology 133 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 134 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 135 document are to be interpreted as described in [RFC2119]. 137 Terminology defined in [RFC6144] is used extensively in this 138 document. Besides, this document uses the following terminologies: 140 IPv6-converted addresses: IPv4 addresses used to represent IPv6 nodes 141 in an IPv4 Internet. They have an explicit mapping relationship to 142 IPv6 addresses. 144 IPv6-converted port: The port number used to distinguish the traffic 145 destinated to different IPv6 servers from the same IPv4 client. 147 NAT46: a stateful IPv4/IPv6 translation functionality. It is 148 consistent with IP/ICMP translation [RFC6145]. 150 3. Overall solution architecture for IPv4 Internet to access IPv6 151 network 153 The 4to6 solution is used for IPv4 clients in IPv4 Internet to reach 154 IPv6 servers . It is designed for HTTP applications specially. 156 In order to achieve the translation initiated from the IPv4 side, two 157 addresses need to be determined by NAT46 translator. The first one 158 is the IPv6-converted address of the IPv6 server, which is is 159 selected from the IPv4 address pool configured in NAT46. The second 160 one is the IPv4-converted address for the IPv4 client, which can be 161 synthetized using the stateless approach defined in [RFC6052]. 163 In HTTP, since the traffic can be redirected to a different service 164 port, it is able to achieve address sharing for IPv6 servers by using 165 distinctive port numbers (denoted as IPv6-converted port) in IPv4 166 client's upstream traffic . Therefore, one IPv4 address can support 167 up to thousands of IPv6 servers in theory. 169 The overall architecture of the 4to6 solution is depicted in the 170 following figure. 172 ------- +--------------------+ ------ 173 // \\ | +----------------+ | // \\ 174 / \ | |Redirect Server | | / \ 175 +---------+ | The IPv4 | | +----------------+ | | The IPv6 | +--------+ 176 | IPv4 | | Internet | | | | Network | | IPv6 | 177 | Client |--+ +-| +------------+ |--+ +--| Server | 178 +---------+ | | | | NAT46 | | | | +--------+ 179 \ / | +------------+ | \ / 180 \\ // +--------------------+ \\ // 181 ------- ------ 183 Figure 1: Overall solution for IPv4 Internet to IPv6 network 185 It consists of several functionalities: 187 1. NAT46: This functionality is consistent with [RFC6145]. It keeps 188 the binding table between the IPv6 server address, IPv6 service port, 189 IPv6-converted address and IPv6-converted port. When an IPv4 packet 190 initiated from the IPv4 client arrives at the NAT46, NAT46 will 191 extract the destination address and the destination port, lookup the 192 binding table and then translate it to an IPv6 packet. It will take 193 similar action to the downstream packet from the IPv6 server. 195 2. Redirect Server: A redirect server is used to redirect traffic to 196 a different IPv6-converted address and IPv6-converted port. Since 197 the A record for a given IPv6 server is always the IPv4 address of 198 the redirect server, the first packet from the IPv4 client will be 199 routed to the redirect server. The redirect server will return IPv6- 200 converted address and IPv6-converted port to the client by querying 201 from the NAT46. 203 In 4to6 solution, only the first TCP flow will be treated by the 204 redirect server. The subsequent traffic will be translated directly 205 by the NAT46. 207 4. The Workflow of 4to6 Solution 209 The workflow of this apporach is as follows: 211 +--------+ +--------+ +--------+ +--------+ +--------+ 212 | IPv4 | | DNS | |Redirect| | NAT46 | | IPv6 | 213 | Client | | | | Server | | | | Server | 214 +--------+ +--------+ +--------+ +--------+ +--------+ 215 | | | | | 216 | DNS A request | | | | 217 | ipv6.example.com | | | | 218 |----------------->| | | | 219 | A response with | | | | 220 | Redirect Ser Addr| | | | 221 |<-----------------| | | | 222 | HTTP GET request, with domain name | | | 223 | in HOST field | Request for | | 224 |----------------------------------->| IPv4 Dst Addr | Setup mapping | 225 | |-------------->| table | 226 |return 302 not found, carry IPv4 dst|Return Add+Port| | 227 |addr and port in the redirect packet|<--------------| | 228 |<-----------------------------------| | | 229 | IPv4 HTTP request with new v4 dst addr | | 230 |--------------------------------------------------->| Translate to IPv6 | 231 | |------------------>| 232 | |<------------------| 233 |<---------------------------------------------------| | 235 Figure 2: Workflow of Proxy-lite Approach 237 1. An IPv4 client initiates a DNS query for A record (e.g. 238 ipv6.example.com). 240 2. In DNS server, the address of the redirect server is configured 241 as the A record for ipv6.example.com and returns to the IPv4 client. 243 3. The IPv4 client sends HTTP GET request. The domain name (e.g. 244 ipv6.example.com) is carried in HOST field. 246 4. The redirect server interprets the domain name, and sends the 247 request to get IPv6-converted address to NAT46 (carrying the address 248 of IPv4 client and the destination port). The specific protocol for 249 the request is now out of scope. 251 5. NAT46 selects IPv6-converted address and IPv6-converted port by 252 lookuping the binding table. It will also keep the destination port 253 in the binding table. 255 6. NAT46 returns the IPv6-converted address and IPv6-converted port 256 to redirect server and the redirect server in turn returns IPv6- 257 converted address in HTTP redirect packet with HTTP error "302 not 258 found". 260 7. IPv4 client replaces the destination IPv4 address with the 261 returned IPv6-converted address. The IPv4 traffic is routed to the 262 NAT46. 264 8. NAT46 extracts the destination address and destination port in 265 the IPv4 traffic. It will lookup the binding table maintained in 266 NAT46 and NAT46 translates the IPv4 packet to IPv6 packet according 267 to [RFC6145]. 269 5. IANA Considerations 271 No requirement on IANA. 273 6. Acknowledgements 275 The authors would like to thank Dan Wing, Fred Baker and Jari Arkko 276 for their review and comments. 278 7. References 280 7.1. Normative References 282 [I-D.rfvlb-behave-v6-content-for-v4-clients] 283 Rajtar, B., Farrer, I., Ales, V., Li, X., and C. Bao, 284 "Framework for accessing IPv6 content for IPv4-only 285 clients", draft-rfvlb-behave-v6-content-for-v4-clients-01 286 (work in progress), July 2013. 288 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 289 Requirement Levels", BCP 14, RFC 2119, March 1997. 291 [RFC2766] Tsirtsis, G. and P. Srisuresh, "Network Address 292 Translation - Protocol Translation (NAT-PT)", RFC 2766, 293 February 2000. 295 [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network 296 Address Translator - Protocol Translator (NAT-PT) to 297 Historic Status", RFC 4966, July 2007. 299 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 300 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 301 October 2010. 303 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 304 IPv4/IPv6 Translation", RFC 6144, April 2011. 306 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 307 Algorithm", RFC 6145, April 2011. 309 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 310 NAT64: Network Address and Protocol Translation from IPv6 311 Clients to IPv4 Servers", RFC 6146, April 2011. 313 [RFC6156] Camarillo, G., Novo, O., and S. Perreault, "Traversal 314 Using Relays around NAT (TURN) Extension for IPv6", 315 RFC 6156, April 2011. 317 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 318 China Education and Research Network (CERNET) IVI 319 Translation Design and Deployment for the IPv4/IPv6 320 Coexistence and Transition", RFC 6219, May 2011. 322 7.2. Informative References 324 Authors' Addresses 326 Chongfeng Xie 327 China Telecom 328 P.R.China 330 Phone: 86 10 58552116 331 Email: xiechf@ctbri.com.cn 333 Qiong Sun 334 China Telecom 335 P.R.China 337 Phone: 86 10 58552936 338 Email: sunqiong@ctbri.com.cn 340 Qi He 341 China Telecom 342 P.R.China 344 Phone: 86 10 58552332 345 Email: heqi@ctbri.com.cn 346 Cathy Zhou 347 Huawei Technologies 348 Bantian, Longgang District 349 Shenzhen 518129 350 P.R. China 352 Phone: 353 Email: cathy.zhou@huawei.com 355 Xing Li 356 CERNET Center/Tsinghua University 357 Room 225, Main Building 358 Beijing 100084 359 P.R.China 361 Phone: +86 10 6278 5983 362 Email: xing@cernet.edu.cn 364 Congxiao Bao 365 CERNET Center/Tsinghua University 366 Room 225, Main Building 367 Beijing 100084 368 P.R.China 370 Phone: +86 10 6278 5983 371 Email: congxiao@cernet.edu.cn