idnits 2.17.1 draft-ietf-v6ops-nat64-experience-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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == 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 (January 31, 2013) is 4095 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC6145' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'I-D.anderson-siit-dc' is defined on line 546, but no explicit reference was found in the text == Unused Reference: 'I-D.donley-behave-deterministic-cgn' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-appsawg-http-forwarded' is defined on line 563, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-v6ops-icp-guidance' is defined on line 587, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 6145 (Obsoleted by RFC 7915) == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-05 == Outdated reference: A later version (-04) exists of draft-ietf-6man-ipv6-atomic-fragments-03 == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-04 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-464xlat-09 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 v6ops G. Chen 3 Internet-Draft Z. Cao 4 Intended status: Informational China Mobile 5 Expires: August 4, 2013 C. Byrne 6 T-Mobile USA 7 C. Xie 8 China Telecom 9 D. Binet 10 France Telecom 11 January 31, 2013 13 NAT64 Deployment Considerations 14 draft-ietf-v6ops-nat64-experience-01 16 Abstract 18 This document summarizes NAT64 deployment scenarios and operational 19 experience with stateful NAT64-CGN(NAT64 Carrier Grade NATs) and 20 NAT64-FE (NAT64 server Front End). 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on August 4, 2013. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 This document may contain material from IETF Documents or IETF 55 Contributions published or made publicly available before November 56 10, 2008. The person(s) controlling the copyright in some of this 57 material may not have granted the IETF Trust the right to allow 58 modifications of such material outside the IETF Standards Process. 59 Without obtaining an adequate license from the person(s) controlling 60 the copyright in such materials, this document may not be modified 61 outside the IETF Standards Process, and derivative works of it may 62 not be created outside the IETF Standards Process, except to format 63 it for publication as an RFC or to translate it into languages other 64 than English. 66 Table of Contents 68 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . . 5 71 3.1. NAT64-CGN Networking . . . . . . . . . . . . . . . . . . . 5 72 3.2. High Availability Considerations . . . . . . . . . . . . . 6 73 3.3. Traceability . . . . . . . . . . . . . . . . . . . . . . . 6 74 3.4. Quality of Experience . . . . . . . . . . . . . . . . . . 7 75 3.5. NAT64-CGN Load Balancer . . . . . . . . . . . . . . . . . 8 76 3.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 8 77 4. NAT64-FE Deployment Experiences . . . . . . . . . . . . . . . 9 78 4.1. NAT64-FE Networking . . . . . . . . . . . . . . . . . . . 9 79 4.2. Source Address Traceability . . . . . . . . . . . . . . . 10 80 4.3. DNS Resolving . . . . . . . . . . . . . . . . . . . . . . 10 81 4.4. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 11 82 4.5. MTU Consideration . . . . . . . . . . . . . . . . . . . . 11 83 4.6. Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 11 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 8. Additional Author List . . . . . . . . . . . . . . . . . . . . 12 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 With IANA's global IPv4 address pool was exhausted, IPv6 is the only 96 sustainable solution for numbering nodes on the Internet. Network 97 operators have to deploy IPv6-only networks in order to meet the 98 numbering needs of the expanding internet without available IPv4 99 addresses. 101 As IPv6 deployment continues, IPv6 networks and hosts will need to 102 coexist with IPv4 numbered resources. The Internet will include 103 nodes that are dual-stack, nodes that remain IPv4-only, and nodes 104 that can be deployed as IPv6-only nodes. 106 Single stack IPv6 network deployment can simplify the network 107 provisioning. Some justifications have been described in 108 [I-D.ietf-v6ops-464xlat]. IPv6-only networks confer some benefits to 109 mobile operators employing them. In the mobile context, it enables 110 the use of a single IPv6 PDP(Packet Data Protocol), which eliminates 111 significant network cost caused by doubling the PDP count on a mass 112 of legacy mobile terminals. In broadband networks overall, it can 113 allow for the scaling of edge-network growth decoupled from IPv4 114 numbering limitations. 116 In a transition scenario, an existing network may rely on the IPv4 117 stack for a long time. There is also the troublesome trend of access 118 network providers squatting on IPv4 address space that they do not 119 own. Allowing for interconnection between IPv4-only nodes and IPv6- 120 only nodes is a critical capability. Widespread dual-stack 121 deployments have not materialized at the anticipated rate over the 122 last 10 years, one possible conclusion being that legacy networks 123 will not make the jump quickly. A translation mechanism based on a 124 NAT64[RFC6146] function will be a key element of the internet 125 infrastructure supporting such legacy networks. 127 [RFC6036] reported at least 30% operators plan to run some kind of 128 translator (presumably NAT64/DNS64). Advice on NAT64 deployment and 129 operation is therefore of some importance. [RFC6586] documented the 130 implications for ipv6 only networks. This document intends to be 131 specific to NAT64 network planning. 133 In regards to IPv4/IPv6 translation, [RFC6144] has described a 134 framework of enabling networks to make interworking possible between 135 IPv4-only and IPv6-only networks. This document has further 136 categorized different NAT64 location and use case. The principle 137 distinction of location is if the NAT64 is located in a NAT64-CGN 138 (Carrier Grade NATs) or NAT64-FE (server Front End). 140 2. Terminology 142 The terms of NAT-CGN/FE are understood to be a topological 143 distinction indicating different features employed in a NAT64 144 deployment. 146 NAT64-CGN: A NAT64-CGN (Carrier Grade NATs) is placed in an ISP 147 network. IPv6 only subscribers leverage the NAT64-CGN to access 148 existing IPv4 internet services. The ISP as an administrative 149 entity takes full control on the IPv6 side, but has limited or no 150 control on the IPv4 side. ISP's should attempt to accommodate the 151 behavior of IPv4 networks and services. 153 NAT64-FE: A NAT64-FE (server Front End) is generally a traffic load 154 balancer with NAT64 functionalities in a ICP network. 156 3. NAT64-CGN Deployment Experiences 158 A NAT64-CGN deployment scenario is depicted in Figure 1 160 ----------- 161 ---------- // \\ 162 // \\ / \ 163 / +----+ \ 164 | |XLAT| | 165 | An IPv6 +----+ The IPv4 | 166 | Network +----+ Internet | XLAT: IPv6/IPv4 167 | |DNS | | Translator 168 \ +----+ / DNS: DNS64 169 \\ // \ / 170 --------- \\ // 171 ----------- 172 ====> 174 Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet 176 3.1. NAT64-CGN Networking 178 The NAT64-CGN use case is employed to connect IPv6-only users to the 179 IPv4 Internet. The NAT64 gateway performs protocol translation from 180 an IPv6 packet header to an IPv4 packet header and vice versa 181 according to the stateful NAT64 [RFC6146]. Address translation maps 182 IPv6 addresses to IPv4 addresses and vice versa for return traffic. 184 All connections to the IPv4 Internet from IPv6-only clients must 185 traverse the NAT64-CGN. It is advantageous from the vantage-point of 186 troubleshooting and traffic engineering to carry the IPv6 traffic 187 natively for as long as possible within an access network and 188 translates only at or near the network egress. In many service 189 provider networks, NAT64 is considered feature of the AS boarder. 190 This allows consistent attribution and traceability within the 191 service provider network. Meaning, within one network, the packet 192 only has one source. As the packet leaves the network destine for 193 another network, the packet source may be translated as needed. 195 In mobile networks, various possibilities can be envisaged to deploy 196 the NAT64 function. Whichever option is selected, the NAT64 function 197 will be deployed beyond the GGSN (Gateway GPRS Support Node) or 198 PDN-GW (Public Data Network-Gateway), i.e. first IP node in currently 199 deployed mobile architectures. 201 In a given implementation, NAT64 functionality can be provided by 202 either a dedicated device or an multifunction gateway with integrated 203 NAT64 functionality. If NAT64 is integrated into an existing node, 204 capacities of existing nods can be potentially limited by the new 205 functionality, e.g. maximum concurrent connections. In a mobile 206 context, the NAT64 function likely be implemented in a firewall, 207 which is the first hop routed from GGSN/PGW. 209 3.2. High Availability Considerations 211 High Availability (HA) is a major requirement for every service. 213 Two mechanisms are typically used to achieve high availability, i.e. 214 cold-standby and hot-standby. Cold-standby systems have synchronized 215 configuration and mechanism to failover traffic between the hot and 216 cold systems such as VRRP [RFC5798] . Unlike hot-standby, cold- 217 standby does not synchronize NAT64 session state. This makes cold- 218 standby less resource intensive and generally simpler, but it 219 requires clients to re-establish sessions when a fail-over occurs. 220 Hot-standby has all the features of cold-standby but must also 221 synchronize the binding information base (BIB). Given that short 222 lived sessions account for most of the bindings, hot-standby does not 223 offer much benefit for those sessions. Consideration should be given 224 to the importance (or lack thereof) of maintaining bindings for long 225 lived sessions across failovers. 227 3.3. Traceability 229 Traceablility is required in many cases such as identifying malicious 230 attacks sources and accounting requirements. NAT64 devices are 231 required to log events like creation and deletion of translations and 232 information about the occupied resources. There are two different 233 demands for traceability,i.e. online or offline. 235 o Regarding the Online requirements, XFF (X-Forwarded-For) 236 [I-D.ietf-appsawg-http-forwarded]would be a candidate, it appends 237 IPv6 address of subscribers to HTTP headers which is passed on to 238 WEB servers, and the querier server can lookup radius servers for 239 the target subscribers based on IPv6 addresses included in XFF 240 HTTP headers. X-Forwarded-For is specific to HTTP, requires the 241 use of an application aware gateway, cannot in general be applied 242 to requests made over HTTPs and cannot be assumed to be preserved 243 end-to-end as it may be overwritten by other application-aware 244 proxies such as load balancers. 246 o Some potential solutions to online traceability are explore in 247 [I-D.ietf-intarea-nat-reveal-analysis]. 249 o A NAT64-CGN could also deliver NAT64 sessions (BIB and STE) to a 250 Radius server by extension of the radius protocol. Such an 251 extension is an alternative solution for online traceability, 252 particularly high performance would be required on Radius servers 253 in order to achieve this. 255 o For off-line traceability, syslog might be a good choice. 256 [RFC6269] indicates address sharing solutions generally need to 257 record and store information for specific periods of time. A 258 stateful NAT64 is supposed to manage one mapping per session. A 259 large volume of logs poses a challenge for storage and processing. 260 In order to mitigate the issue, 261 [I-D.donley-behave-deterministic-cgn]is proposed to pre-allocated 262 a group of ports for each specific IPv6 host. A trade-off among 263 address multiplexing efficiency, port randomization 264 security[RFC6056] and logging storage compression should be 265 considered during the planning. A hybrid mode combining 266 deterministic and dynamic port assignment was recommended 267 regarding the uncertainty of user traffic. 269 3.4. Quality of Experience 271 NAT64 is providing a translation capability between IPv6 and IPv4 272 end-nodes. In order to provide the reachability between two IP 273 address families, NAT64-CGN has to implement appropriate ALGs where 274 address translation is not itself sufficient and security mechanisms 275 do not render it infeasible. e.g. FTP-ALG[RFC6384], RSTP-ALG, H.323- 276 ALG,etc. It should be noted that ALGs may impact the performance on 277 a NAT64 box to some extent. ISPs as well as content providers might 278 choose to avoid situations where the imposition of an ALG might be 279 required. At the same time, it is also important to remind customers 280 and application developers that IPv6 end-to-end usage does not 281 require ALG imposition and therefore results in a better overall user 282 experience. 284 Session status normally is managed by a static life-cycle. In some 285 cases, NAT resource maybe significantly consumed by largely inactive 286 users. The NAT translator and other customers would suffer from 287 service degradation due to port consummation by other subscribers 288 using the same NAT64 device. A flexible NAT session control is 289 desirable to resolve the issues. PCP[I-D.ietf-pcp-base] could be a 290 candidate to provide such capability. A NAT64-CGN should integrate 291 with a PCP server, to allocate available IPv4 address/Port resources. 292 Resources could be assigned to PCP clients through PCP MAP/PEER mode. 293 Such an ability should also be considered to upgrade user 294 experiences, e.g. assigning different sizes of port ranges for 295 different subscribers. Such a mechanism is also helpful to minimize 296 terminal battery consumption and reduce the number of keepalive 297 messages to be sent by terminal devices. 299 3.5. NAT64-CGN Load Balancer 301 Load balancers are an essential tool to avoid the issue of single 302 points of failure and add additional scale. It is potentially 303 important to employ load-balancing considering that deployment of 304 multiple NAT64 devices. Load balancers are required to achieve some 305 service continuity and scale for customers. 306 [I-D.zhang-behave-nat64-load-balancing] discusses several ways of 307 achieving NAT64 load balancing, including anycast based policy and 308 prefix64 selection based policy, either implemented via 309 DNS64[RFC6147] or Prefix64 assignments. Since DNS64 is normally co- 310 located with NAT64 in some scenarios, it could be leveraged to 311 perform the load balance. For traffic which does not require a DNS 312 resolution, prefix64 assignment based 313 on[I-D.ietf-behave-nat64-learn-analysis] could be adopted. 315 3.6. MTU Consideration 317 IPv6 requires that every link in the internet have an MTU of 1280 318 octets or greater[RFC2460]. However, in case of NAT64 translation 319 deployment, some IPv4 MTU constrained link will be used in some 320 communication path and originating IPv6 nodes may therefore receive 321 an ICMP Packet Too Big message, reporting a Next-Hop MTU less than 322 1280. The result would be that IPv6 allows packets to contain a 323 fragmentation header, without the packet being fragmented into 324 multiple pieces. [I-D.ietf-6man-ipv6-atomic-fragments] discusses how 325 this situation could be exploited by an attacker to perform 326 fragmentation-based attacks, and also proposes an improved handling 327 of such packets. It required enhancements on protocol level, which 328 might imply potential upgrade/modifications on behaviors to deployed 329 nodes. Another approach that potentially avoids this issue is to 330 configure IPv4 MTU>=1260. It would forbid the occurrence of 331 PTB<1280. However, such an operational consideration is hard to 332 universally apply to the legacy "IPv4 Internet". 334 4. NAT64-FE Deployment Experiences 336 The NAT64-FE Scenario is depicted in Figure 2 337 -------- 338 // \\ ---------- 339 / \ // \\ 340 / +----+ \ 341 | |XLAT| | 342 | The IPv6 +----+ An IPv4 | 343 | Internet +----+ Network | XLAT: IPv4/IPv6 344 | /Network |DNS | | Translator 345 \ +----+ / DNS: DNS64 346 \ / \\ // 347 \\ // ---------- 348 -------- 349 ====> 351 Figure 2: NAT64-FE Scenario: IPv6 Internet/Network to IPv4 Network 353 4.1. NAT64-FE Networking 355 There are plenty of practices to equip load balancer with NAT64 at 356 front of servers. Two different cases appeared in the NAT64-FE 357 networking. 359 o Some content providers who has a wealth of IPv6 experiences 360 consider IPv6-only strategy to serve customers since it allows new 361 services delivery without having to integrate consideration of 362 IPv4 NAT and address limitations of IPv4 networks. Whereas they 363 have to provide some IPv4 service continuity to their customers, 364 stateless IP/ICMP Translation (SIIT) [RFC6145]has been used to 365 continue provide services for IPv4 subscribers. 367 o ICPs who have insufficient IPv6 incentive likely prefer short-term 368 alternatives to provide IPv6 connectivity due to the widespread 369 impact of supporting IPv6 within a ICP environment. A stateful 370 NAT64 has been located at front of servers. It could 371 simultaneously facilitate the IPv6 accessibility and conservation 372 of IPv4 servers. [I-D.ietf-v6ops-icp-guidance]has described the 373 cases, in which an HTTP proxy can readily be configured to handle 374 incoming connections over IPv6 and to proxy them to a server over 375 IPv4. 377 For first case, [I-D.anderson-siit-dc]has provided further 378 descriptions and guidelines. This document is addressed to second 379 case. An administrator of the IPv4 network needs to be cautious and 380 aware of the operational issues in the case since the native IPv6 is 381 always more desirable than transition solutions. 383 One potential challenge is stateful NAT64-FE facing IPv6 Internet, in 384 which a significant number of IPv6 users may initiate connections. 385 When increasingly numerous users in IPv6 Internet access an IPv4 386 network, scalability concerns(e.g. additional latency, a single point 387 of failure, IPv4 pool exhaustion, etc) are apt to be applied. For a 388 given off-the-shelf NAT64-FE, those challenges should be seriously 389 assessed. Potential issues should be properly identified. 391 Following subsections described several considerations to stateful 392 NAT64-FE case. For operators who seek a clear precedent for 393 operating reliable IPv6-only services, it should be well noted that 394 the usage is problematic. 396 4.2. Source Address Traceability 398 IP addresses are usually used as input to geo-location services. The 399 use of address sharing will prevent these systems from resolving the 400 location of a host based on IP address alone. Applications that 401 assume such geographic information may not work as intended. The 402 possible solutions listed at section 3.3 intended to bridge the gap. 403 However, the analysis reveals those solutions can't be a optimal 404 substitution to solve the problem of host identification, in 405 particular it does not today mitigate problems with source 406 identification through translation. That makes NAT64-FE usage 407 becoming a unappealing approach, if customers require source address 408 tracking. 410 For the operators, who already deployed NAT64-FE approach, the source 411 address of the request is obscured without the source address mapping 412 information previously obtained. It's superior to present mapping 413 information directly to applications. Some application layer proxies 414 e.g. XFF (X-Forwarded-For) , can convey this information in-band. 415 Another approach is to ask application coordinating the information 416 with NAT logging. But that is not sufficient, since the applications 417 itself wants to know the original source address from an application 418 message bus. The logging information may be used by administrators 419 offline to inspect use behavior and preference analysis, and accurate 420 advertisement delivery. 422 4.3. DNS Resolving 424 In the case of NAT64-FE, it is recommended to follow the 425 recommendations in [RFC6144]. There is no need for the DNS to 426 synthesize AAAA from A records, since static AAAA records can be 427 registered in the authoritative DNS for a given domain to represent 428 these IPv4-only hosts. How to design the FQDN for the IPv6 service 429 is out-of-scope of this document. 431 4.4. Load Balancer 433 Load balancing on NAT64-FE has a couple of considerations. If 434 dictated by scale or availability requirements traffic should be 435 balanced among multiple NAT64-CE devices. One point to be noted is 436 that synthetic AAAA records may be added directly in authoritative 437 DNS. load balancing based on DNS64 synthetic resource records may not 438 work in those cases. Secondly, NAT64-FE could also serve as the load 439 balancer for IPv4 backend servers. There are also some ways of load 440 balance for the cases, where load balancer is placed in front of 441 NAT64-FE. 443 4.5. MTU Consideration 445 As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4 446 network are strongly recommended to set to more than 1260. Since a 447 IPv4 network is normally operated by a particular administrative 448 entity, it should take steps to prevent the risk of fragmentation 449 discussed in [I-D.ietf-6man-ipv6-atomic-fragments]. 451 4.6. Anti-DDoS/SYN Flood 453 For every incoming new connection from the IPv6 Internet, the 454 stateful NAT64-FE creates state and maps that connection to an 455 internally-facing IPv4 address and port. An attacker can consume the 456 resources of the NAT64-FE device by sending an excessive number of 457 connection attempts. Without a DDOS limitation mechanism, the 458 NAT64-FE is exposed to attacks. With service provisioning, attacks 459 have the potential could also deteriorate service quality. One 460 consideration in internet content providers is place a L3 load 461 balancer with capable of line rate DDOS defense, such as the 462 employment of SYN PROXY-COOKIE. Security domain division is 463 necessary in this case. Load Balancers could not only serve for 464 optimization of traffic distribution, but also serve as a DOS 465 mitigation device. 467 5. Security Considerations 469 This document presents the deployment experiences of NAT64 in CGN and 470 FE scenario, some security considerations are described in detail 471 regarding to specific NAT64 mode in section 3 and 4. In general, RFC 472 6146[RFC6146] provides TCP-tracking, address-dependent filtering 473 mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also 474 could adopt uRPF and black/white-list to enhance the security by 475 specifying access policies. For example, NAT64-CGN should forbid 476 establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or 477 Loose mode) check does not pass or whose source IPv6 address is 478 associated to black-lists. 480 6. IANA Considerations 482 This memo includes no request to IANA. 484 7. Acknowledgements 486 The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, 487 Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum and Philip 488 Matthews for their helpful comments. Many thanks to Wesley George 489 and Satoru Matsushima for their reviews. 491 The authors especially thank Joel Jaeggli for his efforts and 492 contributions on editing which substantially improves the legibility 493 of the document. 495 8. Additional Author List 497 The following are extended authors who contributed to the effort: 499 Qiong Sun 500 China Telecom 501 Room 708, No.118, Xizhimennei Street 502 Beijing 100035 503 P.R.China 504 Phone: +86-10-58552936 505 Email: sunqiong@ctbri.com.cn 507 QiBo Niu 508 ZTE 509 50,RuanJian Road. 510 YuHua District, 511 Nan Jing 210012 512 P.R.China 513 Email: niu.qibo@zte.com.cn 515 9. References 516 9.1. Normative References 518 [I-D.ietf-pcp-base] 519 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 520 Selkirk, "Port Control Protocol (PCP)", 521 draft-ietf-pcp-base-29 (work in progress), November 2012. 523 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 524 (IPv6) Specification", RFC 2460, December 1998. 526 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 527 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 529 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 530 Algorithm", RFC 6145, April 2011. 532 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 533 NAT64: Network Address and Protocol Translation from IPv6 534 Clients to IPv4 Servers", RFC 6146, April 2011. 536 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 537 Beijnum, "DNS64: DNS Extensions for Network Address 538 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 539 April 2011. 541 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 542 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 544 9.2. Informative References 546 [I-D.anderson-siit-dc] 547 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 548 Centre Environments", draft-anderson-siit-dc-00 (work in 549 progress), November 2012. 551 [I-D.donley-behave-deterministic-cgn] 552 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 553 and O. Vautrin, "Deterministic Address Mapping to Reduce 554 Logging in Carrier Grade NAT Deployments", 555 draft-donley-behave-deterministic-cgn-05 (work in 556 progress), January 2013. 558 [I-D.ietf-6man-ipv6-atomic-fragments] 559 Gont, F., "Processing of IPv6 "atomic" fragments", 560 draft-ietf-6man-ipv6-atomic-fragments-03 (work in 561 progress), December 2012. 563 [I-D.ietf-appsawg-http-forwarded] 564 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 565 draft-ietf-appsawg-http-forwarded-10 (work in progress), 566 October 2012. 568 [I-D.ietf-behave-nat64-learn-analysis] 569 Korhonen, J. and T. Savolainen, "Analysis of solution 570 proposals for hosts to learn NAT64 prefix", 571 draft-ietf-behave-nat64-learn-analysis-03 (work in 572 progress), March 2012. 574 [I-D.ietf-intarea-nat-reveal-analysis] 575 Boucadair, M., Touch, J., Levis, P., and R. Penno, 576 "Analysis of Solution Candidates to Reveal a Host 577 Identifier (HOST_ID) in Shared Address Deployments", 578 draft-ietf-intarea-nat-reveal-analysis-04 (work in 579 progress), August 2012. 581 [I-D.ietf-v6ops-464xlat] 582 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 583 Combination of Stateful and Stateless Translation", 584 draft-ietf-v6ops-464xlat-09 (work in progress), 585 January 2013. 587 [I-D.ietf-v6ops-icp-guidance] 588 Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 589 Content and Application Service Providers", 590 draft-ietf-v6ops-icp-guidance-05 (work in progress), 591 January 2013. 593 [I-D.zhang-behave-nat64-load-balancing] 594 Zhang, D., Xu, X., and M. Boucadair, "Considerations on 595 NAT64 Load-Balancing", 596 draft-zhang-behave-nat64-load-balancing-03 (work in 597 progress), July 2011. 599 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 600 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 602 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 603 Protocol Port Randomization", BCP 156, RFC 6056, 604 January 2011. 606 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 607 IPv4/IPv6 Translation", RFC 6144, April 2011. 609 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 610 Roberts, "Issues with IP Address Sharing", RFC 6269, 611 June 2011. 613 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 614 Network", RFC 6586, April 2012. 616 Authors' Addresses 618 Gang Chen 619 China Mobile 620 53A,Xibianmennei Ave., 621 Xuanwu District, 622 Beijing 100053 623 China 625 Email: phdgang@gmail.com 627 Zhen Cao 628 China Mobile 629 53A,Xibianmennei Ave., 630 Xuanwu District, 631 Beijing 100053 632 China 634 Email: caozhen@chinamobile.com 636 Cameron Byrne 637 T-Mobile USA 638 Bellevue 639 Washington 98105 640 USA 642 Email: cameron.byrne@t-mobile.com 644 Chongfeng Xie 645 China Telecom 646 Room 708 No.118, Xizhimenneidajie 647 Beijing 100035 648 P.R.China 650 Email: xiechf@ctbri.com.cn 651 David Binet 652 France Telecom 653 Rennes 654 35000 655 France 657 Email: david.binet@orange.com