idnits 2.17.1 draft-sunq-v6ops-contents-transition-03.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 16) being 63 lines 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 2 characters in excess of 72. ** There are 2 instances of lines with control characters in the document. == There are 5 instances of lines with non-RFC2606-compliant FQDNs in the document. == 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. 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 seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 12, 2012) is 4421 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6144' is defined on line 624, but no explicit reference was found in the text == Unused Reference: 'RFC6154' is defined on line 634, but no explicit reference was found in the text == Unused Reference: 'I-D.wing-behave-http-ip-address-literals' is defined on line 644, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 650, but no explicit reference was found in the text ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 10 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops C. Xie 3 Internet-Draft China Telecom 4 Intended status: Informational X. Li 5 Expires: September 13, 2012 Tsinghua University 6 J. Qin 7 Consultant 8 M. Chen 9 FreeBit 10 A. Durand 11 Juniper Networks 12 March 12, 2012 14 Practice of IPv4/IPv6 transition system for data center 15 draft-sunq-v6ops-contents-transition-03 17 Abstract 19 This document describes deployment practice of IPv4/IPv6 translation 20 technologies for data center transition, aiming at rapidly increasing 21 the amount of IPv6 accessible contents for users from IPv6 Internet 22 while preserving the continuity of IPv4 service delivery. System 23 based on this design has been deployed in production network to 24 provide transition service for several ICP websites. 26 Status of this Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on September 13, 2012. 43 Copyright Notice 45 Copyright (c) 2012 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 This document may contain material from IETF Documents or IETF 59 Contributions published or made publicly available before November 60 10, 2008. The person(s) controlling the copyright in some of this 61 material may not have granted the IETF Trust the right to allow 62 modifications of such material outside the IETF Standards Process. 63 Without obtaining an adequate license from the person(s) controlling 64 the copyright in such materials, this document may not be modified 65 outside the IETF Standards Process, and derivative works of it may 66 not be created outside the IETF Standards Process, except to format 67 it for publication as an RFC or to translate it into languages other 68 than English. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 2. Requirements Language . . . . . . . . . . . . . . . . . . . . 4 74 3. Motivations . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3.1. Transition As A Service . . . . . . . . . . . . . . . . . 5 76 3.2. Guiding the traffic to IPv6 network . . . . . . . . . . . 6 77 4. Deployment practice one: Communication from IPv6 users to 78 IPv4 server . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 4.1. Deployment scenario . . . . . . . . . . . . . . . . . . . 6 80 4.2. Mapping and Addressing . . . . . . . . . . . . . . . . . . 7 81 4.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 8 82 4.4. Fragmentation . . . . . . . . . . . . . . . . . . . . . . 8 83 4.5. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 8 84 4.6. Geographically aware services . . . . . . . . . . . . . . 9 85 4.7. ALG issues . . . . . . . . . . . . . . . . . . . . . . . . 9 86 4.8. High Availability . . . . . . . . . . . . . . . . . . . . 10 87 4.9. Security . . . . . . . . . . . . . . . . . . . . . . . . . 10 88 4.10. Deployment practices . . . . . . . . . . . . . . . . . . . 10 89 5. Deployment practice two: communications from IPv4 users to 90 IPv6 server . . . . . . . . . . . . . . . . . . . . . . . . . 11 91 5.1. Deployment scenario . . . . . . . . . . . . . . . . . . . 11 92 5.2. Mapping and Addressing . . . . . . . . . . . . . . . . . . 11 93 5.3. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 94 5.4. Logging . . . . . . . . . . . . . . . . . . . . . . . . . 12 95 5.5. Geographically aware services . . . . . . . . . . . . . . 12 96 5.6. ALG issues . . . . . . . . . . . . . . . . . . . . . . . . 12 97 5.7. High Availability . . . . . . . . . . . . . . . . . . . . 12 98 5.8. Security . . . . . . . . . . . . . . . . . . . . . . . . . 12 99 5.9. Deployment practices . . . . . . . . . . . . . . . . . . . 13 100 6. Additional Author List . . . . . . . . . . . . . . . . . . . . 13 101 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 103 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 104 9.1. Normative References . . . . . . . . . . . . . . . . . . . 14 105 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 106 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 108 1. Introduction 110 Facing the pressure of IPv4 address shortage, the operators may like 111 to provide services through IPv6 by upgrade their IP infrastructure 112 to support IPv6. As part of the Infrastructure, Data center (in 113 short, IDC) is the main faculty to house service system that provides 114 services and contents. It is obvious that data center also plays an 115 important role in IPv6 transition in accordance with the transition 116 of IP network. Dual-stack is the basic transition strategy for most 117 data centers, as well as IP transport network. However, in our 118 practices, we found that dual-stack alone is not enough to meet the 119 transition demand of ICPs(in short, ICP) in data centers. The reason 120 behind this is that providing IPv6 services requires the service 121 software of ICP, i.e., website system, database system, supporting 122 system, etc., should be IPv6-aware and can deal with IPv6-related 123 information. Upgrading the service system to support IPv6 is 124 technological-complicated and financially costly, especially for some 125 small and medium-sized ICPs, which is the main reason that the IPv6 126 transition on the ICP sides moves even more slowly than the readiness 127 of operators' IP network. The lack of IPv6-reachable contents 128 becomes one of the main obstacles. On the other hand, some 129 progressive ICPs who are willing to setup an IPv6-only system also 130 would like to offer IPv4 continuity for end-users. 132 Under such circumstances, we propose to deploy IDC transition system 133 in data center, aiming at aiding CP/SP to provide IPv6 services 134 rapidly and smoothly. Another purpose of our approach is to increase 135 the amount of IPv6 accessible contents for users from IPv6 Internet. 136 It can also keep the IPv4 continuity for IPv6-only contents. 138 This document describes our current experiences on two deployment 139 models for the transition of data center based on the approaches 140 specified by IETF (e.g., NAT64 [RFC6146], Dual-Stack [RFC4213], 141 IVI[RFC6219], etc.), targeting different use cases or conditions. 142 Based on these models, an IDC transition system was designed and 143 developed by China Telecom to provide transition services to ICPs in 144 data centers. Some issues and considerations were also identified 145 from the actual deployment. 147 2. Requirements Language 149 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 150 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 151 document are to be interpreted as described in [RFC2119]. 153 3. Motivations 155 As mentioned above, IDC's transition is closely related to the IPv6 156 service provisioning of ICPs. There have been statements from 157 several popular ICPs that they have turned on IPv6 (no matter by 158 which means), which do have a beneficial effect on encouraging end 159 users' transition to IPv6. However, given the operational cost, it 160 is still difficult for most ICPs (especially the great many ones of 161 small-to- medium size) to immediately make their publically-facing 162 services accessible through both IPv4 and IPv6 natively. It will 163 involve a lot of workload for upgrading numerous application systems 164 and the supporting systems in ICPs. On the other hand, from the 165 users' perspective, the IPv6 reachability of resources required for 166 their daily lives is one of the foremost concerns when making the 167 decision on whether or not to access Internet using IPv6. It is a 168 chicken or egg dilemma, but the two perspectives are interdependent. 169 If the transition of one side passes the point of inflexion, the 170 other side will be speeded up after. So, more efforts are needed to 171 encourage the IPv6 adoption and reach the point. 173 Moreover, some progressive ICPs are willing to maintain a separated 174 IPv6-only system, which will lower the risk of the potential impact 175 on their existing wildly used IPv4 system in the early phase. 176 Besides, single-stack system is also easy for operation, management 177 and troubleshooting. There are no duplicated policies need to be 178 applied, including e.g. ACL control, accounting, authentication, 179 etc. In this case, it is also the requirement to offer IPv4 180 continuity to IPv6-only contents. 182 Therefore, the transition system provided by operators in data 183 centers will not only help promote ICP transition in a step-by-step 184 way, but also break out the chicken or egg dilemma for the whole IPv6 185 industry. 187 3.1. Transition As A Service 189 In China Telecom, we have deployed a transition platform in our IDC 190 network. It can be regarded as transition services offered by the 191 operators, to small-to-medium size ICPs (e.g., those who rent servers 192 from the operators). 194 The ICPs can choose to take different approaches according to their 195 scenarios and business strategies. For the conservative ones, the 196 IPv4 services can be still offered natively, and the IPv6 services 197 can be offered by the stateful IPv4/IPv6 translation [RFC6146]. 198 While for progressive ones and newly incomers, the stateless IVI 199 [RFC6219], [RFC6052] can be employed to offer native IPv6 services 200 reachable via IPv4. 202 3.2. Guiding the traffic to IPv6 network 204 IPv4 address shortage has driven some network providers began to run 205 IPv6 in part or the whole network. However, even if IPv6 is ready in 206 the IP network, most ICPs in IDC have not been ready to provide IPv6 207 services. As a result, almost all the traffic is still IPv4-based, 208 which makes the IPv6 network nearly empty. With this in mind, IPv4/ 209 IPv6 translation system deployed in IDC can translate the IPv4 210 packets sourced from the existing servers into IPv6 packets, and 211 forward them into IPv6 network, which is equal to move the traffic 212 from IPv4 network to IPv6 network. and encourage the customers to use 213 IPv6 from the beginning. Furthermore, only translation will be 214 performed on the edge of the network and it is independent of user- 215 side transition mechanisms. 217 4. Deployment practice one: Communication from IPv6 users to IPv4 218 server 220 4.1. Deployment scenario 222 We have deployed transition service gateway in the exit of our IDCs. 223 It is a shared platform which can serve multiple servers 224 simultaneously. It can be integrated with existing network element 225 of our IDC, e.g. egress router, load balancer, etc., or can be 226 deployed as a new standalone device. The integrated deployment 227 scenario would have little impact on existing network topology; 228 however, it is highly coupled with existing devices. The standalone 229 deployment scenario would be easier to implement on existing network 230 incrementally. However, it will result in extra cost for new 231 devices. 233 The egress router of our IDC is IPv6-reachable, however, either the 234 content servers or the whole IDC infrastructure have been upgraded to 235 IPv6 directly. With the help of transition gateway, we can provide 236 IPv6 reachable content to customers in a quick manner. Our 237 deployment model is depicted in the following picture. 239 +----------------+ +---------------+ +--------------+ 240 | Data Center | | Transition | | IPv6 | 241 | | --- | Gateway | --- | Internet | 242 | +--------+ | +---------------+ +--------------+ 243 | | IPv4 | | 244 | | Server | | +--------------+ 245 | +--------+ | ------------------------ | IPv4 | 246 | | | Internet | 247 +----------------+ +--------------+ 249 Figure 1: Deployment Model 1 251 In this deployment model, the Stateful NAT64 is performed to 252 translate IPv6 packets to IPv4 and vice versa. The guidance in 253 [RFC6146] should be followed. The communications are initiated from 254 the IPv6 side. When an IPv6 packet arrives, a lookup of the mapping 255 table will be carried out to get the IPv4 address used for the 256 translation. If there is no one matched, a new entry will be 257 created. 259 The server-side deployment model is independent of user-side 260 transition When a dual-stack user gets both A and AAAA records for a 261 remote server, it will be encouraged to reach IPv4 content via IPv6 262 connectivity through the only NAT64 gateway along the path. So even 263 if there are some other CGNs deployed in the customer-side, IPv6 264 traffic will be forwarded in a traditional way. Therefore, there 265 will be no double-translation problems around here. 267 Up to now, there are 8 sites including the official website of China 268 Telecom have been upgrading to IPv6 with this mechanism. More than 269 15 thousands different IPv6 users ever accessing the above eight ICPs 270 through the transition box totally, with 4000 to 6000 active users 271 every day. www.voc.com.cn is the most popular one accessed by more 272 than 4000 IPv6 users daily, and www.chinatelecom.com.cn (the official 273 website of china telecom) has amounts of access from 1200 IPv6 users 274 on average every day. 276 4.2. Mapping and Addressing 278 The Stateful NAT64 can support the following two mapping modes: 280 o 1:1, one IPv6 address is mapped to one IPv4 address (exclusively 281 for given lifetime); 283 o N:1, each of the IPv4 addresses (i.e. IPv4 address pool) will be 284 shared by multiple IPv6 users from Internet. 286 To save global IPv4 addresses which has become scarce resource, 287 private blocks, for instance 10.0.0.0/8 may be used for the Stateful 288 NAT64. This private address block can only be seen within the IDC 289 network. 291 Considering the scale of traffic in the foreseeable future, the 1:1 292 Mapping Mode with private blocks (one IPv6 address mapped to one 293 private IPv4 address within 10.0.0.0/8) is selected as the default mode 294 for the Stateful NAT64. In this mode, there is only address-layer 295 mapping and no TCP/UDP session maintenance anymore. By this mean, 296 the efficiency of stateful operations could be improved and the 297 problems introduced by the address sharing could be alleviated (for 298 example, the burden of logging will be reduced in this mode). 300 However, there may be conflicts if the same private space is used 301 internally for the interconnection of servers (e.g. multiple servers 302 for load balancing). In this case, N:1 mode with public blocks can 303 be used. In order to reduce state management burden in N:1 stateful 304 NAT64 gateway as well as logging system, a bulk of ports can be 305 allocated for each subscriber. In this port-set based mapping mode, 306 one IPv6 address will be mapped to the same IPv4 address and a given 307 port-set. 309 In addition, an IPv6 prefix is used to serve the IPv4 servers in the 310 IDC, and the route of the prefix has been advertised to the IPv6 311 Internet. The IPv4 address of the server can be embedded in the IPv6 312 prefix following the algorithm specified in [RFC6052]. 314 4.3. DNS 316 To make sure the addresses of servers can be retrieved by IPv6 users 317 before initiating sessions, the AAAA records which formed through 318 IPv4-translated addresses have been added directly on the domain's 319 authoritative DNS, or upgrade authoritative DNS to support DNS64. In 320 this way, the AAAA records under one domain name could be retrieved 321 by IPv6 users around the world. 323 Please note that if the authoritative DNS of given ICPs' domain names 324 are maintained by some third-party DNS Providers but not by 325 themselves or the operator from whom this transition service (i.e. 326 the deployment model of Stateful NAT64 discussed herein) is 327 purchased, the ICPs must make sure the authoritative AAAA records can 328 be added. 330 4.4. Fragmentation 332 Basically, the processing of packets carrying fragments follows the 333 guidance specified in [RFC6145] and [RFC6146] with exceptions that 334 fragmented IPv4/IPv6 packets will be firstly reassembled to an 335 integrated packet before doing packet translation and so on. 337 4.5. Logging 339 The logging is essential for tracing back specific users in stateful 340 NAT64. In 1:1 mode, only per-user logging events need to be recorded 341 as {IPv6 address, IPv4 address, timestamp}. For N:1 mode, in order 342 to reduce the number of sessions need to be logged, we adopt port-set 343 based mechanism to assign a bulk of ports to each subscriber. 344 Therefore, one subscriber will only create one corresponding log 345 report, e.g. {IPv4 address, IPv6 address, port-set, timestamp}. 347 4.6. Geographically aware services 349 Since converted IPv4 address would not represent any geographical 350 feature anymore, applications that assume such geographic information 351 may not work as intended. 353 Two solutions were designed and implemented, one is to maintain the 354 above logging information in geographic server as well, and offer an 355 open API to ICPs to retrieve its original IPv6 address when 356 necessary. It will have little impact on NAT64 gateway since there 357 is no application-layer procedure. However, due to the transmission 358 and computational latency in geographic servers, it is more suitable 359 for ICPs to retrieve IPv6 users' source address offline. Another way 360 is to embed user's source IPv6 address in x-forward field of user's 361 request when it traverses NAT64 gateway. This involves application- 362 layer process which will bring extra burden on NAT64 gateway. So 363 only for ICPs who really need online users' source address will be 364 offered with this additional service. 366 4.7. ALG issues 368 Since the types of applications are relatively limited due to the 369 deployment policy, it would be easier to solve the ALG issue compared 370 to client-side deployment. For example, Web-based ICPs might be 371 introduced in the first stage, and so specific ALGs can be applied 372 accordingly. 374 Since video traffic constitutes a great portion of the whole Internet 375 traffic, we have implemented HTTP AGLs for video traffic in 376 particular. 378 In our test for TOP100 Websites in China, there are basically three 379 types of HTTP ALGs for video traffic. 381 HTTP/1.1 302 Found: This is a common way of performing a 382 redirection. Usually, IPv4 address literals for redirected server 383 will be embedded in Location header. 385 HTTP/1.1 301 Moved Permanently: This is also a redirect way 386 indicating the requested resource has been assigned a new 387 permanent place, and the IPv4 address literals for redirected 388 server will also be embedded in Location header. 390 HTTP/1.1 200 ok: This code means the request has succeeded. 391 However, some ICPs will still embed the IPv4 address literals to 392 indicate the redirected server in the following communication, and 393 they will use a great variety of keywords. For example, 394 www.sina.com.cn uses the keyword "CDATA[http://" followed by a 395 list of IPv4 addresses, and v.6.cn use "watchip" as its keyword. 397 Since the first two types occupy the great majority of existing ALGs 398 for HTTP-based videos traffic, we have implemented the ALG for the 399 first two cases to synchronize an IPv4-translated address if the 400 server of the embedded IPv4 address is located within the NAT64 401 region. 403 4.8. High Availability 405 In general, there are two mechanisms to achieve high reliability, 406 i.e. cold-standby and hot-standby. In cold-standby mode, the NAT64 407 states are not replicated from the Primary NAT64 gateway to the 408 Backup NAT64 gateway. When the Primary NAT64 gateway fails, all the 409 existing established sessions will be flushed out. The hosts are 410 required to re-establish sessions with the external hosts. Another 411 high availability option is the hot standby mode. In this mode the 412 NAT64 gateway keeps established sessions while failover happens. The 413 1:1 mapping mode will greatly reduce the amount of sessions needed to 414 be replicated on-the-fly from the Primary NAT64 gateway to the Backup 415 gateway. Another option is to deploy an Anycast NAT64 prefix. This 416 is similar to cold-standby that NAT64 states are not replicated 417 between Primary gateway and Backup gateway, except that the heartbeat 418 line is not needed anymore. 420 4.9. Security 422 The security issues and considerations discussed in [RFC6146] apply 423 to the deployment model described in this document. However, when 424 deploying stateful NAT64 in server side, it is hard to apply source- 425 based filtering policy. As a result, we have introduced alarming 426 mechanism to report the current status of state-consuming speed in 427 NAT64 gateway. 429 Besides, both 1:1 mapping mode and port-set based N:1 mapping mode 430 can guarantee that one IPv6 source address will be mapped to a single 431 IPv4 address. Therefore, the ICP can identify a single subscriber 432 either by IPv4 source address in 1:1 mapping, or IPv4 source address 433 plus port-set in N:1 mapping. 435 4.10. Deployment practices 437 Up to now, there are 8 sites including the official website of China 438 Telecom have been upgrading to IPv6 with this mechanism. More than15 439 thousands different IPv6 users ever accessing the above eight Content 440 Providers through the transition box totally, with 4000 to 6000 441 active users every day. www.voc.com.cn is the most popular one 442 accessed by more than 4000 IPv6 users daily, and 443 www.chinatelecom.com.cn (the official website of china telecom) has 444 amounts of access from 1200 IPv6 users on average every day. 446 5. Deployment practice two: communications from IPv4 users to IPv6 447 server 449 5.1. Deployment scenario 451 Considering in the foreseeable future, IPv6 will be a widely accepted 452 protocol in the Internet, some ICPs, especially newcomers, will setup 453 IPv6-only servers, to reduce the operation and maintenance 454 complexity. When the server in question itself is IPv6- 455 capable,communications initiated from IPv6 users will not encounter 456 any transition problem. What we are concerned is the communications 457 initiated from IPv4 users. To mitigate this problem, IPv4/IPv6 458 translation is utilized in the IDC that the server resides. In this 459 scenario, the IPv4 node will firstly get A/AAAA records of the server 460 from DNS, and then the communication will follow the path to NAT64 461 Gateway. When an IPv4 packet arrives at NAT64 Gateway, it would be 462 translated to an IPv6 packet based on stateless 1:1 mapping algorithm 463 [RFC6219]. 465 +----------------+ +------------+ +--------------+ 466 | Data Center | | Transition | | IPv4 | 467 | | --- | Gateway | --- | Internet | 468 | +--------+ | +------------+ +--------------+ 469 | | IPv6 | | 470 | | Server | | +--------------+ 471 | +--------+ | -------------------- | IPv6 | 472 | | | Internet | 473 +----------------+ +--------------+ 475 Figure 2: Deployment Model2 477 5.2. Mapping and Addressing 479 To eliminate the state management burden, we adopted stateless 480 transition gateway to do the Interworking between IPv4 Internet and 481 IPv6-only server within IDC, IPv6-only server should be configured 482 with an IPv4-translatable address. Then both source address and 483 destination address are applied with 1:1 mapping to keep the 484 simplicity and transparency. 486 In addition, an IPv4 address within the range of a given IPv4 prefix 487 is used to represent the IPv6 server, and the route of the IPv4 488 prefix has been advertised to the IPv4 Internet. An IPv6 prefix will 489 be assigned to the IDC to represent the whole IPv4 Internet, when 490 IPv4 packet traverse the transition gateway, IPv6 addresses, e.g., 491 source address and destination address, will be formed by combine the 492 IPv4 address with a IPv6 prefix following the algorithm specified in 493 [RFC6052]. In this way, the server can be reachable from IPv4 494 Internet without mapping states in transition gateway. 496 5.3. DNS 498 To make sure that addresses of servers can be retrieved by IPv4 users 499 before initiating sessions, the A records which are extracted from 500 IPv4-translated addresses should be added directly on the domain's 501 authoritative DNS, or upgrade authoritative DNS to support DNS64. 502 Other considerations are actually the same with Section 4. 504 5.4. Logging 506 There is no logging issue in stateless transition solution. 508 5.5. Geographically aware services 510 When a ICP gets an IPv4-converted IPv6 addresses with a pre-defined 511 Prefix, it should extract the embedded IPv4 address which would 512 reflects its original geographical information. 514 5.6. ALG issues 516 ALG issues would be the same with section 4.6. 518 5.7. High Availability 520 Since there is no state maintained in the transition gateway, state 521 replication or re-establishment encountered in the HA of the first 522 deployment model will not exist in the second one. 524 5.8. Security 526 IPv4/IPv6 translators which can be modeled as special routers, are 527 subject to the same risks, and can implement the same mitigations. 528 (The discussion of generic threats to routers and their mitigations 529 is beyond the scope of this document.) There is, however, a 530 particular risk that often happens in IPv4 Internet: address 531 spoofing. 533 An attacker could use a faked IPv4 address as the source address of 534 malicious packets. After translation, the packets will appear as 535 IPv6 packets from the specified source, and the attacker may be hard 536 to track. If left without mitigation, the attack would allow 537 malicious IPv4 nodes to spoof arbitrary IPv4 addresses. 539 The mitigation is to implement reverse path checks and to verify 540 throughout the network that packets are coming from an authorized 541 location. 543 5.9. Deployment practices 545 The following IPv6-only websites has been setup to provide native 546 IPV6 service to IPv6 users, all of them are hosted in a dual-stack 547 IDC. 549 http://iptv.bupt.edu.cn 551 http://www.mayan.cn 553 http://www.ivi.buptnet.edu.cn 555 In order to accommodate the access of great volume of existing IPv4- 556 only users, stateless transition gateway was deployed to provide 557 translation in the exit of the IDC. Currently, the peak of the 558 traffic is around 900Mbps. 560 6. Additional Author List 562 Qiong Sun 564 China Telecom 566 Room 708 No.118, Xizhimenneidajie 568 Beijing, 100035 570 P.R.China 572 Phone: +86 10 5855 2923 574 Email: sunqiong@ctbri.com.cn 576 Qian Liu 578 China Telecom 580 No.359 Wuyi Rd., 582 Changsha, Hunan 410011 583 P.R.China 585 Phone: +86 731 8226 0127 587 Email: 18973133999@189.cn 589 Qin Zhao 591 BUPT 593 Beijing 100876 595 P.R.China 597 Phone: +86 138 1127 1524 599 Email: zhaoqin@bupt.edu.cn 601 7. IANA Considerations 603 This document includes no request to IANA. 605 8. Acknowledgements 607 The authors would like to thank Fred Baker, Joel Jaeggli, Erik Kline, 608 Randy Bush for their comments and feedback. 610 9. References 612 9.1. Normative References 614 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 615 Requirement Levels", BCP 14, RFC 2119, March 1997. 617 [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms 618 for IPv6 Hosts and Routers", RFC 4213, October 2005. 620 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 621 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 622 October 2010. 624 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 625 IPv4/IPv6 Translation", RFC 6144, April 2011. 627 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 628 Algorithm", RFC 6145, April 2011. 630 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 631 NAT64: Network Address and Protocol Translation from IPv6 632 Clients to IPv4 Servers", RFC 6146, April 2011. 634 [RFC6154] Leiba, B. and J. Nicolson, "IMAP LIST Extension for 635 Special-Use Mailboxes", RFC 6154, March 2011. 637 [RFC6219] Li, X., Bao, C., Chen, M., Zhang, H., and J. Wu, "The 638 China Education and Research Network (CERNET) IVI 639 Translation Design and Deployment for the IPv4/IPv6 640 Coexistence and Transition", RFC 6219, May 2011. 642 9.2. Informative References 644 [I-D.wing-behave-http-ip-address-literals] 645 Wing, D., "Coping with IP Address Literals in HTTP URIs 646 with IPv6/IPv4 Translators", 647 draft-wing-behave-http-ip-address-literals-02 (work in 648 progress), March 2010. 650 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 651 June 1999. 653 Authors' Addresses 655 Chongfeng Xie 656 China Telecom 657 Room 708 No.118, Xizhimenneidajie 658 Beijing, 100035 659 P.R.China 661 Phone: +86 10 5855 2116 662 Email: xiechf@ctbri.com.cn 664 Xing Li 665 Tsinghua University 666 Room 225, Main Building 667 Beijing 100084 668 P.R.China 670 Phone: +86 10 6278 5983 671 Email: xing@cernet.edu.cn 672 Jacni Qin 673 Consultant 674 Shanghai, 675 China 677 Phone: +86 1391 861 9913 678 Email: jacniq@gmail.com 680 Maoke Chen 681 FreeBit Co., Ltd. 682 13F E-space Tower, Maruyama-cho 3-6 683 Shibuya-ku, Tokyo 150-0044 684 Japan 686 Email: fibrib@gmail.com 688 Alain Durand 689 Juniper Networks 690 1194 North Mathilda Avenue 691 Sunnyvale, CA 94089-1206 692 USA 694 EMail: adurand@juniper.net