idnits 2.17.1 draft-chen-v6ops-nat64-experience-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: ---------------------------------------------------------------------------- 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 (July 30, 2012) is 4278 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 561, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-appsawg-http-forwarded' is defined on line 573, 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-05 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 1 error (**), 0 flaws (~~), 10 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: January 31, 2013 C. Byrne 6 T-Mobile USA 7 C. Xie 8 China Telecom 9 D. Binet 10 France Telecom 11 July 30, 2012 13 NAT64 Operational Experiences 14 draft-chen-v6ops-nat64-experience-03 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 Edge). 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 January 31, 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 Nat) or NAT64-CE (Customer Edge). 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 Nat) 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 Edge) 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-stanby 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, e.g. enterprise-GW. Those cases are sure 394 to exist for the time being. An administrator of the IPv4 network 395 needs to be cautious and aware of the operational issues this may 396 cause, since the native IPv6 is always more desirable than transition 397 solution. 399 One potential challenge in the scenario is NAT64-CE facing IPv6 400 Internet, in which a significant number of IPv6 users may initiate 401 connections. When increasingly numerous users in IPv6 Internet 402 access an IPv4 network, scalability concerns(e.g. additional latency, 403 a single point of failure, IPv4 pool exhaustion, etc) are apt to be 404 applied. For a given off-the-shelf NAT64-CE, those challenges should 405 be seriously assessed. Potential issues should be properly 406 identified. In order to mitigate the issues, it is suggested such 407 usage should be restrained to a relative small-scale. 409 For operators who seek a clear precedent for operating reliable IPv6- 410 only services, it should be well noted that the usage is problematic 411 at several aspects. In some sense, it's not recommended. 413 4.2. Anti-DDoS/SYN Flood 415 For every incoming new connection from the IPv6 Internet, the 416 NAT64-CE creates state and maps that connection to an internally- 417 facing IPv4 address and port. An attacker can consume the resources 418 of the NAT64-CE device by sending an excessive number of connection 419 attempts. Without a DDOS limitation mechanism, the NAT64 is exposed 420 to attacks from the IPv6 Internet. With service provisioning, 421 attacks have the potential could also deteriorate service quality. 422 One consideration in internet content providers is place a L3 load 423 balancer with capable of line rate DDOS defense, such as the 424 employment of SYN PROXY-COOKIE. Security domain division is 425 necessary in this case. Load Balancers could not only serve for 426 optimization of traffic distribution, but also serve as a DOS 427 mitigation device 429 4.3. User Behavior Analysis 431 IP addresses are usually used as input to geo-location services. The 432 use of address sharing will prevent these systems from resolving the 433 location of a host based on IP address alone. Applications that 434 assume such geographic information may not work as intended. The 435 possible solutions listed at section 3.3 intended to bridge the gap. 436 However, the analysis reveals those solutions can't be a optimal 437 substitution to solve the problem of host identification, in 438 particular it does not today mitigate problems with source 439 identification through translation. That makes NAT64-CE usage 440 becoming a unappealing approach, if customers require source address 441 tracking. 443 For the operators, who already deployed NAT64-CE approach, the source 444 address of the request is obscured without the source address mapping 445 information previously obtained. It's superior to present mapping 446 information directly to applications. Some application layer proxies 447 e.g. XFF (X-Forwarded-For) , can convey this information in-band. 448 Another approach is to ask application coordinating the information 449 with NAT logging. But that is not sufficient, since the applications 450 itself wants to know the original source address from an application 451 message bus. The logging information may be used by administrators 452 offline to inspect use behavior and preference analysis, and accurate 453 advertisement delivery. 455 4.4. DNS Resolving 457 In the case of NAT64-CE, it is recommended to follow the 458 recommendations in [RFC6144]. There is no need for the DNS to 459 synthesize AAAA from A records, since static AAAA records can be 460 registered in the authoritative DNS for a given domain to represent 461 these IPv4-only hosts. How to design the FQDN for the IPv6 service 462 is out-of-scope of this document. 464 4.5. Load Balancer 466 Load balancing on NAT64-CE has a couple of considerations. If 467 dictated by scale or availability requirements traffic should be 468 balanced among multiple NAT64-CE devices. One point to be noted is 469 that synthetic AAAA records may be added directly in authoritative 470 DNS. load balancing based on DNS64 synthetic resource records may not 471 work in those cases. Secondly, NAT64-CE could also serve as the load 472 balancer for IPv4 backend servers. There are also some ways of load 473 balance for the cases, where load balancer is placed in front of 474 NAT64(s). 476 4.6. MTU Consideration 478 As compared to the MTU consideration in NAT64-CGN, the MTU of IPv4 479 network are strongly recommended to set to more than 1260. Since a 480 CE IPv4 network is normally operated by a particular administrative 481 entity, it should take steps to prevent the risk of fragmentation 482 discussed in [I-D.ietf-6man-ipv6-atomic-fragments]. 484 5. Security Considerations 486 This document presents the deployment experiences of NAT64 in CGN and 487 CE scenario, some security considerations are described ib detail 488 regarding to specific NAT64 mode in section 2 and 3. In general, RFC 489 6146[RFC6146] provides TCP-tracking, address-dependent filtering 490 mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, ISP also 491 could adopt uRPF and black/white-list to enhance the security by 492 specifying access policies. for example, NAT64-CGN should forbid 493 establish NAT64 BIB for incoming IPv6 packets if URPF (Strict or 494 Loose mode) check does not pass or whose source IPv6 address is 495 associated to black-lists. 497 6. IANA Considerations 499 This memo includes no request to IANA. 501 7. Acknowledgements 503 The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, 504 Fred Baker, Lee Howard and Iljitsch van Beijnum for their helpful 505 comments. Many thanks to Wesley George and Satoru Matsushima for 506 their reviews. 508 The authors especially thank Joel Jaeggli for his efforts and 509 contributions on editing which substantially improves the legibility 510 of the document. 512 8. Additional Author List 514 The following are extended authors who contributed to the effort: 516 Qiong Sun 517 China Telecom 518 Room 708, No.118, Xizhimennei Street 519 Beijing 100035 520 P.R.China 521 Phone: +86-10-58552936 522 Email: sunqiong@ctbri.com.cn 524 QiBo Niu 525 ZTE 526 50,RuanJian Road. 527 YuHua District, 528 Nan Jing 210012 529 P.R.China 530 Email: niu.qibo@zte.com.cn 532 9. References 534 9.1. Normative References 536 [I-D.ietf-pcp-base] 537 Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 538 Selkirk, "Port Control Protocol (PCP)", 539 draft-ietf-pcp-base-26 (work in progress), June 2012. 541 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 542 (IPv6) Specification", RFC 2460, December 1998. 544 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 545 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 547 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 548 NAT64: Network Address and Protocol Translation from IPv6 549 Clients to IPv4 Servers", RFC 6146, April 2011. 551 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 552 Beijnum, "DNS64: DNS Extensions for Network Address 553 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 554 April 2011. 556 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 557 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 559 9.2. Informative References 561 [I-D.donley-behave-deterministic-cgn] 562 Donley, C., Grundemann, C., Sarawat, V., and K. 563 Sundaresan, "Deterministic Address Mapping to Reduce 564 Logging in Carrier Grade NAT Deployments", 565 draft-donley-behave-deterministic-cgn-04 (work in 566 progress), July 2012. 568 [I-D.ietf-6man-ipv6-atomic-fragments] 569 Gont, F., "Processing of IPv6 "atomic" fragments", 570 draft-ietf-6man-ipv6-atomic-fragments-00 (work in 571 progress), February 2012. 573 [I-D.ietf-appsawg-http-forwarded] 574 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 575 draft-ietf-appsawg-http-forwarded-06 (work in progress), 576 July 2012. 578 [I-D.ietf-behave-nat64-learn-analysis] 579 Korhonen, J. and T. Savolainen, "Analysis of solution 580 proposals for hosts to learn NAT64 prefix", 581 draft-ietf-behave-nat64-learn-analysis-03 (work in 582 progress), March 2012. 584 [I-D.ietf-intarea-nat-reveal-analysis] 585 Boucadair, M., Touch, J., Levis, P., and R. Penno, 586 "Analysis of Solution Candidates to Reveal a Host 587 Identifier (HOST_ID) in Shared Address Deployments", 588 draft-ietf-intarea-nat-reveal-analysis-02 (work in 589 progress), April 2012. 591 [I-D.ietf-v6ops-464xlat] 592 Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 593 Combination of Stateful and Stateless Translation", 594 draft-ietf-v6ops-464xlat-05 (work in progress), July 2012. 596 [I-D.zhang-behave-nat64-load-balancing] 597 Zhang, D., Xu, X., and M. Boucadair, "Considerations on 598 NAT64 Load-Balancing", 599 draft-zhang-behave-nat64-load-balancing-03 (work in 600 progress), July 2011. 602 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 603 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 605 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 606 Protocol Port Randomization", BCP 156, RFC 6056, 607 January 2011. 609 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 610 IPv4/IPv6 Translation", RFC 6144, April 2011. 612 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 613 Roberts, "Issues with IP Address Sharing", RFC 6269, 614 June 2011. 616 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 617 Network", RFC 6586, April 2012. 619 Authors' Addresses 621 Gang Chen 622 China Mobile 623 53A,Xibianmennei Ave., 624 Xuanwu District, 625 Beijing 100053 626 China 628 Email: phdgang@gmail.com 630 Zhen Cao 631 China Mobile 632 53A,Xibianmennei Ave., 633 Xuanwu District, 634 Beijing 100053 635 China 637 Email: caozhen@chinamobile.com 638 Cameron Byrne 639 T-Mobile USA 640 Bellevue 641 Washington 98105 642 USA 644 Email: cameron.byrne@t-mobile.com 646 Chongfeng Xie 647 China Telecom 648 Room 708 No.118, Xizhimenneidajie 649 Beijing 100035 650 P.R.China 652 Email: xiechf@ctbri.com.cn 654 David Binet 655 France Telecom 656 Rennes 657 35000 658 France 660 Email: david.binet@orange.com