idnits 2.17.1 draft-ietf-v6ops-nat64-experience-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 : ---------------------------------------------------------------------------- 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 (August 07, 2012) is 4280 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.donley-behave-deterministic-cgn' is defined on line 562, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-appsawg-http-forwarded' is defined on line 574, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-26 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-04 == Outdated reference: A later version (-04) exists of draft-ietf-6man-ipv6-atomic-fragments-00 == Outdated reference: A later version (-10) exists of draft-ietf-appsawg-http-forwarded-06 == Outdated reference: A later version (-10) exists of draft-ietf-intarea-nat-reveal-analysis-02 == Outdated reference: A later version (-10) exists of draft-ietf-v6ops-464xlat-06 == Outdated reference: A later version (-05) exists of draft-ietf-v6ops-icp-guidance-02 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 1 error (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Chen 3 Internet-Draft Z. Cao 4 Intended status: Informational China Mobile 5 Expires: February 8, 2013 C. Byrne 6 T-Mobile USA 7 C. Xie 8 China Telecom 9 D. Binet 10 France Telecom 11 August 07, 2012 13 NAT64 Operational Experiences 14 draft-ietf-v6ops-nat64-experience-00 16 Abstract 18 This document summarizes stateful NAT64 deployment scenarios and 19 operational experience with NAT64-CGN(NAT64 Carrier Grade NATs) and 20 NAT64-CE (NAT64 Customer Edges). 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 February 8, 2013. 39 Copyright Notice 41 Copyright (c) 2012 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 . . . . . . . . . . . . . . . 6 71 3.1. NAT64-CGN Networking . . . . . . . . . . . . . . . . . . . 6 72 3.2. High Availability Considerations . . . . . . . . . . . . . 7 73 3.3. Traceability . . . . . . . . . . . . . . . . . . . . . . . 7 74 3.4. Quality of Experience . . . . . . . . . . . . . . . . . . 8 75 3.5. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 9 76 3.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 9 77 4. NAT64-CE Deployment Experiences . . . . . . . . . . . . . . . 9 78 4.1. NAT64-CE Networking . . . . . . . . . . . . . . . . . . . 10 79 4.2. Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 11 80 4.3. User Behavior Analysis . . . . . . . . . . . . . . . . . . 11 81 4.4. DNS Resolving . . . . . . . . . . . . . . . . . . . . . . 11 82 4.5. Load Balancer . . . . . . . . . . . . . . . . . . . . . . 12 83 4.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 12 84 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 87 8. Additional Author List . . . . . . . . . . . . . . . . . . . . 13 88 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 89 9.1. Normative References . . . . . . . . . . . . . . . . . . . 13 90 9.2. Informative References . . . . . . . . . . . . . . . . . . 14 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 93 1. Introduction 95 Continued development of global Internet demands IP address 96 consumption. The IANA global IPv4 address pool was exhausted on 97 February 3, 2011. IPv6 is the only sustainable solution for 98 numbering nodes on the Internet. Network operators have to deploy 99 IPv6 networks in order to meet the numbering needs of the expanding 100 internet without available IPv4 addresses. IPv4 numbering resources 101 and IPv4-only schemes to reduce the numbering utilization during the 102 transitional will not be adequate to maintain connectivity and 103 deliver Internet services. 105 As IPv6 deployment continues, IPv6 networks and hosts will need to 106 coexist with IPv4 numbered resources. The Internet will include 107 nodes that are Dual-stack, nodes that remain IPv4-only and IPv6-only 108 nodes. It may be desirable in some cases for operators to deploy a 109 single stack network, for reasons of simplicity, cost or performance 110 relative to a dual stack network. As IPv4 utilization eventually 111 declines, the appeal of single stack network deployments will likely 112 increase. In a dual-stack architecture, operators have to maintain 113 double management interfaces, provide operational support systems for 114 two networks, track multiple addresses in different families per 115 host, trouble shoot host behavior related to dual stack operation and 116 engage in other activities that increase the overhead of operating 117 the network. 119 Single stack IPv6 network deployment can simplify the network 120 provisioning. Some justification has been described in 121 [I-D.ietf-v6ops-464xlat]. IPv6-only networks confer some benefits to 122 mobile operators employing them. In the mobile context, it enables 123 the use of a single IPv6 PDP(Packet Data Protocol), which eliminates 124 significant network cost caused by doubling the PDP count on a mass 125 of legacy mobile terminals. In broadband networks overall, it can 126 allow for the scaling of edge-network growth decoupled from IPv4 127 numbering limitations. 129 In a transition scenario, an existing network may rely on the IPv4 130 stack for a long time. There is also the troublesome trend of access 131 network providers squatting on IPv4 address space that they do not 132 own. Allowing for interconnection between IPv4-only nodes and IPv6- 133 only nodes is a critical capability. Widespread dual-stack 134 deployments have not materialized at the anticipated rate over the 135 last 10 years on possible conclusion being that legacy networks will 136 not make the jump quickly. A translation mechanism based on a 137 NAT64[RFC6146] function might be a key element of the internet 138 infrastructure supporting such legacy networks. 140 [RFC6036] reported at least 30% operators plan to run some kind of 141 translator (presumably NAT64/DNS64). Advice on NAT64 deployment and 142 operation is therefore of some importance. [RFC6586] documented the 143 implications for ipv6 only networks. This document intends to be 144 specific to NAT64 network planning. 146 In regards to IPv4/IPv6 translation, [RFC6144] has described a 147 framework of enabling networks to make interworking possible between 148 IPv4-only and IPv6-only networks. Three scenarios are described, "An 149 IPv6 Network to the IPv4 Internet", "The IPv6 Internet to an IPv4 150 Network" and "An IPv6 Network to an IPv4 Network" where a NAT64 151 function is relevant. The scenario of "The IPv6 Internet to the IPv4 152 Internet" seems to be the ideal case for inter-network translation 153 technology. This document has focused on the three cases and further 154 categorized different NAT64 location and use case. The principle 155 distinction of location is if the NAT64 is located in a NAT64-CGN 156 (Carrier Grade NATs) or NAT64-CE (Customer Edges). NAT64-CGN 157 corresponds to the scenario "IPv6 Network to IPv4 Internet". The 158 NAT64-CE location roughly corresponds to the "IPv6 Internet to IPv4 159 Network" and "IPv6 Network to IPv4 Network" scenarios. Based on 160 different NAT64 modes, different considerations have been described 161 for ISPs to facilitate NAT64 deployments. 163 2. Terminology 165 The terms of NAT-CGN/CE are understood to be a topological 166 distinction indicating different features employed in a NAT64 167 deployment. 169 NAT64-CGN: A NAT64-CGN (Carrier Grade NATs) is placed in an ISP 170 network and managed by an administrative entity, e.g. operator. 171 From an administrator view, a NAT64-CGN usually forwards outbound 172 traffic into an IPv4 network. IPv6 only subscribers leverage the 173 NAT64-CGN to be served by existing IPv4 internet services. The 174 ISP as an administrative entity takes full control on the IPv6 175 side, but has limited or no control on the IPv4 side. ISP's 176 should attempt to accommodate the behavior of IPv4 networks and 177 services. 179 NAT64-CE: A NAT64-CE (Customer Edges) is placed at the edge of 180 customer network, e.g. a network operated by an Enterprise or 181 Consumer. A NAT64-CE makes IPv4 services accessible for the IPv6 182 only users. An upstream entity and ISP usually operates an IPv4 183 and potentially IPv6 network respectively. IPv6 access is the 184 common infrastructure behind the NAT64-CE. 186 3. NAT64-CGN Deployment Experiences 188 A NAT64-CGN deployment scenario is depicted in Figure 1 190 ----------- 191 ---------- // \\ 192 // \\ / \ 193 / +----+ \ 194 | |XLAT| | 195 | An IPv6 +----+ The IPv4 | 196 | Network +----+ Internet | XLAT: IPv6/IPv4 197 | |DNS | | Translator 198 \ +----+ / DNS: DNS64 199 \\ // \ / 200 --------- \\ // 201 ----------- 202 ====> 204 Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet 206 3.1. NAT64-CGN Networking 208 The NAT64-CGN use case is employed to connect IPv6-only users to the 209 IPv4 Internet. The NAT64 gateway performs protocol translation from 210 an IPv6 packet header to an IPv4 packet header and vice versa 211 according to the Stateful NAT64 [RFC6146]. Address translation maps 212 IPv6 addresses to IPv4 addresses and vice versa for return traffic. 214 All connections to the IPv4 Internet from IPv6-only clients must 215 traverse the NAT64-CGN. It is advantageous from the vantage-point of 216 troubleshooting and traffic engineering to carry the IPv6 traffic 217 natively for as long as possible within an access network and 218 translates only at or near the network egress. 220 In mobile networks, various possibilities can be envisaged in which 221 to deploy the NAT64 function. Whichever option is selected, the 222 NAT64 function will be deployed beyond the GGSN (Gateway GPRS Support 223 Node) or PDN-GW (Public Data Network-Gateway), i.e. first IP node in 224 currently deployed mobile architectures. 226 In a given implementation, NAT64 functionality can be provided by 227 either a dedicated GW device or an multifunction gateway with 228 integrated NAT64 functionality. In standalone NAT64, NAT64-CGN is 229 placed to the side of a BNG or CR. An embedded NAT64 deployment 230 would be integrated with an existing GW. Capacities of an existing 231 GW can be potentially limited by the inserted functionality. In a 232 mobile context, the NAT64 function can be co-located with GGSN/PDN-GW 233 or it can be embedded in an existing FW/NAT44 already deployed in 234 support of IPv4 NAT or, the function can be collocated on a router. 235 Whatever the solution retained for the co-location option, impact on 236 existing services and legal obligations have to be assessed. 238 3.2. High Availability Considerations 240 High Availability (HA) is a major requirement for every service and 241 network service. 243 Two mechanisms are typically used to achieve high availability, i.e. 244 cold-standby and hot-standby. Cold-standby systems have synchronized 245 configuration and mechanism to failover traffic between the hot and 246 cold systems such as VRRP [RFC5798] . Unlike hot-standby, cold- 247 standby does not synchronize NAT64 session state. This makes cold- 248 standby less resource intensive and generally simpler, but it 249 requires clients to re-establish sessions when a fail-over occurs. 250 Hot-standby has all the features of cold-standby but must also 251 synchronize the binding information base (BIB). Given that short 252 lived sessions account for most of the bindings, hot-standby does not 253 offer much benefit for those sessions. Consideration should be given 254 to the importance (or lack thereof) of maintaining bindings for long 255 lived sessions across failovers. 257 3.3. Traceability 259 Traceablility is required in many cases to identify an attacker or a 260 host that launches malicious attacks and/or for various other 261 purposes, such as accounting requirements. NAT64 devices are 262 required to log events like creation and deletion of translations and 263 information about the occupied resources. There are two different 264 demands for traceability,i.e. online or offline. 266 o Regarding the Online requirements, XFF (X-Forwarded-For) 267 [I-D.ietf-appsawg-http-forwarded]would be a candidate, it appends 268 IPv6 address of subscribers to HTTP headers which is passed on to 269 WEB servers, and the querier server can lookup radius servers for 270 the target subscribers based on IPv6 addresses included in XFF 271 HTTP headers. X-Forwarded-For is specific to HTTP, requires the 272 use of an application aware gateway, cannot in general be applied 273 to requests made over HTTPs and cannot be assumed to be preserved 274 end-to-end as it may be overwritten by other application-aware 275 proxies such as load balancers. 277 o Some potential solutions to online traceability are explore in 278 [I-D.ietf-intarea-nat-reveal-analysis]. 280 o A NAT64-CGN could also deliver NAT64 sessions (BIB and STE) to a 281 Radius server by extension of the radius protocol. Such an 282 extension is an alternative solution for online traceability, 283 particularly high performance would be required on Radius servers 284 on order to achieve this. 286 o For off-line traceability, syslog might be a good choice. 287 [RFC6269] indicates address sharing solutions generally need to 288 record and store information for specific periods of time. A 289 stateful NAT64 is supposed to manage one mapping per session. A 290 large volume of logs poses a challenge for storage and processing. 291 In order to mitigate the issue, 292 [I-D.donley-behave-deterministic-cgn]proposed to pre-allocated a 293 group of ports for each specific IPv6 host. A trade-off among 294 address multiplexing efficiency, port randomization 295 security[RFC6056] and logging storage compression should be 296 considered during the planning. A hybrid mode combining 297 deterministic and dynamic port assignment was recommended 298 regarding the uncertainty of user traffic. 300 3.4. Quality of Experience 302 NAT64 is providing a translation capability between IPv6 and IPv4 303 end-nodes. In order to provide the reachability between two IP 304 address families, NAT64-CGN has to implement appropriate ALGs where 305 address translation is not itself sufficient and security mechanisms 306 do not render it infeasible. e.g. FTP-ALG[RFC6384], RSTP-ALG, H.323- 307 ALG,etc. It should be noted that ALGs may impact the performance on 308 a NAT64 box to some extent. ISPs as well as content providers might 309 choose to avoid situations where the imposition of an ALG might be 310 required. At the same time, it is also important to remind customers 311 that IPv6 end-to-end usage does not require ALG imposition and 312 therefore results in a better overall user experience. 314 The service experience should be optimized around stateful NAT 315 processing. Session status normally is managed by a static life- 316 cycle. In some cases, NAT resource maybe significantly consumed by 317 largely inactive users. The NAT translator and other customers would 318 suffer from service degradation due to port consummation by other 319 subscribers using the same NAT64 device. A flexible NAT session 320 control is desirable to resolve the issues. PCP[I-D.ietf-pcp-base] 321 could be a candidate to provide such capability. A NAT64-CGN should 322 integrate with a PCP server, to allocate available IPv4 address/Port 323 resources. Resources could be assigned to PCP clients through PCP 324 MAP/PEER mode. Such an ability should also be considered to upgrade 325 user experiences, e.g. assigning different sizes of port ranges for 326 different subscribers. Such a mechanism is also helpful to minimize 327 terminal battery consumption reducing the number of keepalive 328 messages to be sent by terminal devices. 330 3.5. Load Balancer 332 Load balancers are an essential tool to avoid the issue of single 333 points of failure and add additional scale. It is potentially 334 important to employ load-balancing considering that deployment of 335 multiple NAT64 devices. Load balancers are required to achieve some 336 service continuity and scale for customers. 337 [I-D.zhang-behave-nat64-load-balancing] discusses several ways of 338 achieving NAT64 load balancing, including anycast based policy and 339 prefix64 selection based policy, either implemented via 340 DNS64[RFC6147] or Prefix64 assignments. Since DNS64 is normally co- 341 located with NAT64 in some scenarios, it could be leveraged to 342 perform the load balance. For traffic which does not require a DNS 343 resolution, prefix64 assignment based 344 on[I-D.ietf-behave-nat64-learn-analysis] could be adopted. 346 3.6. MTU Consideration 348 IPv6 requires that every link in the internet have an MTU of 1280 349 octets or greater[RFC2460]. However, in case of NAT64 translation 350 deployments, some IPv4 MTU constrained link will be used in some 351 communication path and originating IPv6 nodes may therefore receive 352 an ICMP Packet Too Big message, reporting a Next-Hop MTU less than 353 1280. The result would be that IPv6 allows packets to contain a 354 fragmentation header, without the packet being fragmented into 355 multiple pieces. [I-D.ietf-6man-ipv6-atomic-fragments] discusses how 356 this situation could be exploited by an attacker to perform 357 fragmentation-based attacks, and also proposes an improved handling 358 of such packets. It required enhancements on protocol level, which 359 might imply potential upgrade/modifications on behaviors to deployed 360 nodes. Another approach that potentially avoids this issue is to 361 configure IPv4 MTU>=1260. It would forbid the occurrence of 362 PTB<1280. However, such an operational consideration is hard to 363 universally apply to the legacy "IPv4 Internet". 365 4. NAT64-CE Deployment Experiences 367 The NAT64-CE Scenario is depicted in Figure 2 368 -------- 369 // \\ ---------- 370 / \ // \\ 371 / +----+ \ 372 | |XLAT| | 373 | The IPv6 +----+ An IPv4 | 374 | Internet +----+ Network | XLAT: IPv4/IPv6 375 | /Network |DNS | | Translator 376 \ +----+ / DNS: DNS64 377 \ / \\ // 378 \\ // ---------- 379 -------- 380 ====> 382 Figure 2: NAT64-CE Scenario: IPv6 Internet/Network to IPv4 Network 384 4.1. NAT64-CE Networking 386 Content providers would like to use IPv6 to serve customers since it 387 allows for the definition of new services without having to integrate 388 consideration of IPv4 NAT and address limitations of IPv4 networks, 389 but they have to provide some IPv4 service continuity to their 390 customers. In some cases, customers outside the network will have 391 IPv6-only access provided by early adopters before the internal 392 network. The deployment requirements could be resolved by subsiding 393 NAT64 to a customer edge. [I-D.ietf-v6ops-icp-guidance] has 394 described the cases, in which an HTTP proxy can readily be configured 395 to handle incoming connections over IPv6 and to proxy them to a 396 server over IPv4. Those cases are sure to exist for the time being. 397 An administrator of the IPv4 network needs to be cautious and aware 398 of the operational issues this may cause, since the native IPv6 is 399 always more desirable than transition solution. 401 One potential challenge in the scenario is NAT64-CE facing IPv6 402 Internet, in which a significant number of IPv6 users may initiate 403 connections. When increasingly numerous users in IPv6 Internet 404 access an IPv4 network, scalability concerns(e.g. additional latency, 405 a single point of failure, IPv4 pool exhaustion, etc) are apt to be 406 applied. For a given off-the-shelf NAT64-CE, those challenges should 407 be seriously assessed. Potential issues should be properly 408 identified. 410 For operators who seek a clear precedent for operating reliable IPv6- 411 only services, it should be well noted that the usage is problematic 412 at several aspects. In some sense, it's not recommended. 414 4.2. Anti-DDoS/SYN Flood 416 For every incoming new connection from the IPv6 Internet, the 417 NAT64-CE creates state and maps that connection to an internally- 418 facing IPv4 address and port. An attacker can consume the resources 419 of the NAT64-CE device by sending an excessive number of connection 420 attempts. Without a DDOS limitation mechanism, the NAT64 is exposed 421 to attacks from the IPv6 Internet. With service provisioning, 422 attacks have the potential could also deteriorate service quality. 423 One consideration in internet content providers is place a L3 load 424 balancer with capable of line rate DDOS defense, such as the 425 employment of SYN PROXY-COOKIE. Security domain division is 426 necessary in this case. Load Balancers could not only serve for 427 optimization of traffic distribution, but also serve as a DOS 428 mitigation device 430 4.3. User Behavior Analysis 432 IP addresses are usually used as input to geo-location services. The 433 use of address sharing will prevent these systems from resolving the 434 location of a host based on IP address alone. Applications that 435 assume such geographic information may not work as intended. The 436 possible solutions listed at section 3.3 intended to bridge the gap. 437 However, the analysis reveals those solutions can't be a optimal 438 substitution to solve the problem of host identification, in 439 particular it does not today mitigate problems with source 440 identification through translation. That makes NAT64-CE usage 441 becoming a unappealing approach, if customers require source address 442 tracking. 444 For the operators, who already deployed NAT64-CE approach, the source 445 address of the request is obscured without the source address mapping 446 information previously obtained. It's superior to present mapping 447 information directly to applications. Some application layer proxies 448 e.g. XFF (X-Forwarded-For) , can convey this information in-band. 449 Another approach is to ask application coordinating the information 450 with NAT logging. But that is not sufficient, since the applications 451 itself wants to know the original source address from an application 452 message bus. The logging information may be used by administrators 453 offline to inspect use behavior and preference analysis, and accurate 454 advertisement delivery. 456 4.4. DNS Resolving 458 In the case of NAT64-CE, it is recommended to follow the 459 recommendations in [RFC6144]. There is no need for the DNS to 460 synthesize AAAA from A records, since static AAAA records can be 461 registered in the authoritative DNS for a given domain to represent 462 these IPv4-only hosts. How to design the FQDN for the IPv6 service 463 is out-of-scope of this document. 465 4.5. Load Balancer 467 Load balancing on NAT64-CE has a couple of considerations. If 468 dictated by scale or availability requirements traffic should be 469 balanced among multiple NAT64-CE devices. One point to be noted is 470 that synthetic AAAA records may be added directly in authoritative 471 DNS. load balancing based on DNS64 synthetic resource records may not 472 work in those cases. Secondly, NAT64-CE could also serve as the load 473 balancer for IPv4 backend servers. There are also some ways of load 474 balance for the cases, where load balancer is placed in front of 475 NAT64(s). 477 4.6. MTU Consideration 479 As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4 480 network are strongly recommended to set to more than 1260. Since a 481 CE IPv4 network is normally operated by a particular administrative 482 entity, it should take steps to prevent the risk of fragmentation 483 discussed in [I-D.ietf-6man-ipv6-atomic-fragments]. 485 5. Security Considerations 487 This document presents the deployment experiences of NAT64 in CGN and 488 CE scenario, some security considerations are described ib detail 489 regarding to specific NAT64 mode in section 2 and 3. In general, RFC 490 6146[RFC6146] provides TCP-tracking, address-dependent filtering 491 mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also 492 could adopt uRPF and black/white-list to enhance the security by 493 specifying access policies. for example, NAT64-CGN should forbid 494 establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or 495 Loose mode) check does not pass or whose source IPv6 address is 496 associated to black-lists. 498 6. IANA Considerations 500 This memo includes no request to IANA. 502 7. Acknowledgements 504 The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, 505 Fred Baker, Hui Deng, Lee Howard and Iljitsch van Beijnum for their 506 helpful comments. Many thanks to Wesley George and Satoru Matsushima 507 for their reviews. 509 The authors especially thank Joel Jaeggli for his efforts and 510 contributions on editing which substantially improves the legibility 511 of the document. 513 8. Additional Author List 515 The following are extended authors who contributed to the effort: 517 Qiong Sun 518 China Telecom 519 Room 708, No.118, Xizhimennei Street 520 Beijing 100035 521 P.R.China 522 Phone: +86-10-58552936 523 Email: sunqiong@ctbri.com.cn 525 QiBo Niu 526 ZTE 527 50,RuanJian Road. 528 YuHua District, 529 Nan Jing 210012 530 P.R.China 531 Email: niu.qibo@zte.com.cn 533 9. References 535 9.1. Normative References 537 [I-D.ietf-pcp-base] 538 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 539 Selkirk, "Port Control Protocol (PCP)", 540 draft-ietf-pcp-base-26 (work in progress), June 2012. 542 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 543 (IPv6) Specification", RFC 2460, December 1998. 545 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 546 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 548 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 549 NAT64: Network Address and Protocol Translation from IPv6 550 Clients to IPv4 Servers", RFC 6146, April 2011. 552 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 553 Beijnum, "DNS64: DNS Extensions for Network Address 554 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 555 April 2011. 557 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 558 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 560 9.2. Informative References 562 [I-D.donley-behave-deterministic-cgn] 563 Donley, C., Grundemann, C., Sarawat, V., and K. 564 Sundaresan, "Deterministic Address Mapping to Reduce 565 Logging in Carrier Grade NAT Deployments", 566 draft-donley-behave-deterministic-cgn-04 (work in 567 progress), July 2012. 569 [I-D.ietf-6man-ipv6-atomic-fragments] 570 Gont, F., "Processing of IPv6 "atomic" fragments", 571 draft-ietf-6man-ipv6-atomic-fragments-00 (work in 572 progress), February 2012. 574 [I-D.ietf-appsawg-http-forwarded] 575 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 576 draft-ietf-appsawg-http-forwarded-06 (work in progress), 577 July 2012. 579 [I-D.ietf-behave-nat64-learn-analysis] 580 Korhonen, J. and T. Savolainen, "Analysis of solution 581 proposals for hosts to learn NAT64 prefix", 582 draft-ietf-behave-nat64-learn-analysis-03 (work in 583 progress), March 2012. 585 [I-D.ietf-intarea-nat-reveal-analysis] 586 Boucadair, M., Touch, J., Levis, P., and R. Penno, 587 "Analysis of Solution Candidates to Reveal a Host 588 Identifier (HOST_ID) in Shared Address Deployments", 589 draft-ietf-intarea-nat-reveal-analysis-02 (work in 590 progress), April 2012. 592 [I-D.ietf-v6ops-464xlat] 593 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 594 Combination of Stateful and Stateless Translation", 595 draft-ietf-v6ops-464xlat-06 (work in progress), 596 August 2012. 598 [I-D.ietf-v6ops-icp-guidance] 599 Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 600 Content and Application Service Providers", 601 draft-ietf-v6ops-icp-guidance-02 (work in progress), 602 July 2012. 604 [I-D.zhang-behave-nat64-load-balancing] 605 Zhang, D., Xu, X., and M. Boucadair, "Considerations on 606 NAT64 Load-Balancing", 607 draft-zhang-behave-nat64-load-balancing-03 (work in 608 progress), July 2011. 610 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 611 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 613 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 614 Protocol Port Randomization", BCP 156, RFC 6056, 615 January 2011. 617 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 618 IPv4/IPv6 Translation", RFC 6144, April 2011. 620 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 621 Roberts, "Issues with IP Address Sharing", RFC 6269, 622 June 2011. 624 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 625 Network", RFC 6586, April 2012. 627 Authors' Addresses 629 Gang Chen 630 China Mobile 631 53A,Xibianmennei Ave., 632 Xuanwu District, 633 Beijing 100053 634 China 636 Email: phdgang@gmail.com 638 Zhen Cao 639 China Mobile 640 53A,Xibianmennei Ave., 641 Xuanwu District, 642 Beijing 100053 643 China 645 Email: caozhen@chinamobile.com 646 Cameron Byrne 647 T-Mobile USA 648 Bellevue 649 Washington 98105 650 USA 652 Email: cameron.byrne@t-mobile.com 654 Chongfeng Xie 655 China Telecom 656 Room 708 No.118, Xizhimenneidajie 657 Beijing 100035 658 P.R.China 660 Email: xiechf@ctbri.com.cn 662 David Binet 663 France Telecom 664 Rennes 665 35000 666 France 668 Email: david.binet@orange.com