idnits 2.17.1 draft-chen-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 (March 12, 2012) is 4399 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.petersson-forwarded-for' is defined on line 446, but no explicit reference was found in the text == Outdated reference: A later version (-29) exists of draft-ietf-pcp-base-23 ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). 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: September 13, 2012 C. Byrne 6 T-Mobile USA 7 Q. Niu 8 ZTE 9 March 12, 2012 11 NAT64 Operational Experiences 12 draft-chen-v6ops-nat64-experience-01 14 Abstract 16 This document summarizes some stateful NAT64 deployment scenarios and 17 operational experiences for NAT64-CGN and NAT64-CE. 19 Status of this Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on September 13, 2012. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 This document may contain material from IETF Documents or IETF 52 Contributions published or made publicly available before November 53 10, 2008. The person(s) controlling the copyright in some of this 54 material may not have granted the IETF Trust the right to allow 55 modifications of such material outside the IETF Standards Process. 56 Without obtaining an adequate license from the person(s) controlling 57 the copyright in such materials, this document may not be modified 58 outside the IETF Standards Process, and derivative works of it may 59 not be created outside the IETF Standards Process, except to format 60 it for publication as an RFC or to translate it into languages other 61 than English. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 2. NAT64-CGN Deployment Experiences . . . . . . . . . . . . . . . 3 67 2.1. NAT64-CGN Networking . . . . . . . . . . . . . . . . . . . 4 68 2.2. High Availability Consideration . . . . . . . . . . . . . 5 69 2.3. Traceability and Lawful Interception . . . . . . . . . . . 5 70 2.4. Quality of Experience . . . . . . . . . . . . . . . . . . 6 71 2.5. Load Balance . . . . . . . . . . . . . . . . . . . . . . . 6 72 2.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 6 73 3. NAT64-CE Deployment Experiences . . . . . . . . . . . . . . . 7 74 3.1. NAT64-CE Networking . . . . . . . . . . . . . . . . . . . 7 75 3.2. Anti-DDoS/SYN Flood . . . . . . . . . . . . . . . . . . . 8 76 3.3. User Behavior Analysis . . . . . . . . . . . . . . . . . . 8 77 3.4. DNS Resolving . . . . . . . . . . . . . . . . . . . . . . 8 78 3.5. Load Balance . . . . . . . . . . . . . . . . . . . . . . . 9 79 3.6. MTU Consideration . . . . . . . . . . . . . . . . . . . . 9 80 4. Security Considerations . . . . . . . . . . . . . . . . . . . 9 81 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 9 82 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 9 83 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 84 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 85 7.2. Informative References . . . . . . . . . . . . . . . . . . 10 86 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 88 1. Introduction 90 With fast developments of global Internet, the demands for IP 91 addresses are rapidly increasing. IANA announced that the global 92 IPv4 address pool has been exhausted on February 3, 2011. IPv6 is 93 the only sustainable solution for numbering nodes on the Internet. 94 Network operators have to accelerate the process of deploying IPv6 95 networks in order to meet the numbering needs of expanding internet 96 without available IPv4 addresses. 98 As IPv6 deployments progress, IPv6 will coexist with IPv4. The 99 Internet will include nodes that are IPv4-only, IPv6-only, and nodes 100 that are dual-stack with IPv4 and IPv6. The interconnection between 101 IPv4-only nodes and IPv6-only nodes is a critical capability. Given 102 that widespread dual-stack deployments have not materialized over the 103 last 10 years for which the approach has been prescribed prior to 104 IPv4 exhaust, it is obvious that NAT64[RFC6146] will be a key element 105 of the going-forward internet infrastructure. 107 Regarding the IPv4/IPv6 translation, RFC6144[RFC6144] has described a 108 framework enabling networks to have IPv4 and IPv6 coexist. There are 109 three common NAT64 deployment scenarios "An IPv6 Network to the IPv4 110 Internet", "The IPv6 Internet to an IPv4 Network" and "An IPv6 111 Network to an IPv4 Network". Since the scenario of "The IPv6 112 Internet to the IPv4 Internet" seems the ideal case for in-network 113 translation technology, this document has focused on the three cases 114 and categorized different NAT64 usages as NAT64-CGN and NAT64-CE. 115 Therein, NAT64-CGN are corresponding to the scenario "IPv6 Network to 116 IPv4 Internet". NAT64-CE is for "IPv6 Internet to IPv4 Network" and 117 "IPv6 Network to IPv4 Network" respectively. Based on different 118 NAT64 modes, different considerations have been elaborated for ISPs 119 to facilitate NAT64 deployments. 121 The purpose of this document is to summarize deployment experience of 122 server operators and content providers regarding NAT64. The reader 123 of this document can get the information for their possible 124 deployment of NAT64 in future. Whether the audiences take the 125 experience as their deployment guidance is up to them, not the 126 purpose of this document. 128 2. NAT64-CGN Deployment Experiences 130 The NAT64-CGN Scenario is depicted in Figure 1 131 ----------- 132 ---------- // \\ 133 // \\ / \ 134 / +----+ \ 135 | |XLAT| | 136 | An IPv6 +----+ The IPv4 | 137 | Network +----+ Internet | XLAT: IPv6/IPv4 138 | |DNS | | Translator 139 \ +----+ / DNS: DNS64 140 \\ // \ / 141 --------- \\ // 142 ----------- 143 ====> 145 Figure 1: NAT64-CGN Scenario: IPv6 Network to IPv4 Internet 147 2.1. NAT64-CGN Networking 149 NAT64-CGN case is focusing on connecting IPv6-only users with IPv4 150 Internet. NAT64 performs protocol translation from an IPv6 packet 151 header to an IPv4 packet header and vice versa is performed according 152 to the the Stateful NAT64 [RFC6146]. Address translation maps IPv6 153 addresses to IPv4 addresses and vice versa. 155 Given that all IPv4 connections to the IPv4 Internet from IPv6-only 156 clients must traverse the NAT64, the NAT64 should be located close to 157 the IPv4 peering points to reduce unnecessary backhaul costs and 158 latency. It is advantageous for troubleshooting and traffic 159 engineering to maintain the IPv6 traffic native for as long as 160 possible within an access network and only translate at the network 161 border. 163 Coming to a real practice in broadband access network, NAT64 164 functionalities could be located on BNG or core router depending on 165 scale of IPv6-enable network. From implementation views, NAT64 166 functionalities could be served by either a dedicated GW or an 167 existing GW integrated with NAT64 functionality. In standalone 168 NAT64, NAT64-CGN is placed in a side of BNG or CR. The deployment 169 has few impacts to a given network, which results in a low OPEX. On 170 the other side, an embedded NAT64 is integrated with existing GW, it 171 requires relative lower investment, i.e. lower CAPEX. However, 172 capacities of existing GW would be restricted by the inserted 173 functionality. It likely requires a new round of network planning, 174 which would cause high OPEX. 176 The different deployment modes would correspond to specific use 177 cases, in which ISP should consider different perspectives, e.g. 179 traffic model, investment, network evolution, etc. 181 2.2. High Availability Consideration 183 High Availability (HA) is a major requirement for every service and 184 network service. 186 In general, there are two mechanisms to achieve high reliability, 187 i.e. cold-standby and hot-standby. Cold-standby has synchronized 188 configuration and mechanism to failover traffic between the hot and 189 cold systems such as VRRP [RFC5798] . Unlike hot-standby, cold- 190 standby does not synchronize NAT64 session state. This makes cold- 191 stanby less resource intensive and generally simpler, but it requires 192 clients to re-establish sessions when a fail-over occurs. Hot-stanby 193 has all the features of cold-standby but must also synchronize the 194 binding information base (BIB). Considering the most common Internet 195 traffic type is short lived sessions, hot-standby does not offer much 196 benefit unless long lived sessions are common and the cost is 197 justified. 199 2.3. Traceability and Lawful Interception 201 Traceability and Lawful Interception(LI) are required in many cases 202 to identify an attacker or a host that was used to launch malicious 203 attacks and/or for various other purposes of accounting. 205 In order to facilitate traceability, NAT64 devices are required to 206 log events like creation and deletion of translations and information 207 about the occupied resources. There are two different demands for 208 traceability,i.e. online or offline. Regarding the Online 209 requierements, XFF (X-Forwarded-For) 210 [I-D.petersson-forwarded-for]would be a candidate, it appends IPv6 211 address of subscribers to HTTP headers which is passed on to WEB 212 servers, and the querier server can lookup radius servers for the 213 target subscribers based on IPv6 addresses included in XFF HTTP 214 headers. NAT64-CGN could also deliver NAT64 session (BIB and STE) to 215 Radius server by some extent of radius protocol extension. That is 216 an alternative solution for online traceability, but high performance 217 is required on Radius servers . For off-line traceability, syslog 218 might be a good choice. 220 Lawful intercept[RFC3924] is normally part of the access network, in 221 which an optical splitter is used to bypass all traffic for 222 subsequent filtering process. It's not the requirement for NAT64. 223 However, operators may expect to serve as interception access point 224 (IAP) avoiding installation of additional LI system. It's low-cost 225 and fast-deployed. It's an alternative solution for LI even if that 226 may not a major case in current practices. 228 2.4. Quality of Experience 230 While NAT64 is bridge between the IPv6 and IPv4, it is important that 231 the NAT64-CGN have the appropriet ALGs to support customers, e.g. 232 FTP-ALG[RFC6384], RSTP-ALG, H.323-ALG,etc. At the same time, it is 233 also important to remind customers that IPv6 end-to-end does not 234 required ALGs and therefore that provides the best experience. 236 The service experiences also should be optimized in context of 237 stateful NAT64, which has some common issues regarding NAT process. 238 To be specific, session status normally is managed by a static 239 lifetime cycle. In some cases, NAT resource maybe suffered from 240 significant inactive users. A flexible NAT session control is 241 desirable to resolve the issues. PCP[I-D.ietf-pcp-base] could be a 242 candidate to provide such capability. In the case, NAT64-CGN should 243 integrate with PCP server, depending on which available IPv4 address/ 244 Port could be assigned to PCP client through PCP MAP/PEER mode. Such 245 abilities should also be considered to upgrade user experiences, e.g. 246 assigning different sizes of port ranges for different subscribers. 248 2.5. Load Balance 250 Load balance is an essential ability to avoid the issue of single 251 point of failure and add the feature of linear scalability. When 252 there are multiple NAT64 CGN deployed, it is important to achieve 253 load balancing between these different devices. 254 [I-D.zhang-behave-nat64-load-balancing] discusses several ways of 255 achieving NAT64 load balancing, including anycast based policy and 256 prefix64 selection based policy, either implemented via DNS64 or 257 Prefix64 assignments. 259 2.6. MTU Consideration 261 IPv6 requires that every link in the internet have an MTU of 1280 262 octets or greater[RFC2460]. However, the coexistence with IPv4 link 263 may let originating IPv6 node to receive an ICMP Packet Too Big 264 message reporting a Next-Hop MTU less than 1280. That would result 265 the IPv6 allows packets to contain a fragment header, without the 266 packet being actually fragmented into multiple pieces. 267 [I-D.gont-6man-ipv6-atomic-fragments] discusses how this could 268 situation could be exploited by an attacker to perform fragmentation- 269 based attacks, and also proposes an improved handling of such 270 packets. It required enhancements on protocol level, which might 271 imply potential upgrations/modifications on behaviors to deployed 272 nodes. Another candidate approach avoding this issue is to configure 273 IPv4 MTU>=1260 from operational perspectives. It would forbid the 274 occurrence of PTB<1280. However, such operational consideration is 275 hardly applied to a wild "IPv4 Internet". In this case, these issues 276 are eliminated from operational aspects. 278 3. NAT64-CE Deployment Experiences 280 The NAT64-CE Scenario is depicted in Figure 2 281 -------- 282 // \\ ---------- 283 / \ // \\ 284 / +----+ \ 285 | |XLAT| | 286 | The IPv6 +----+ An IPv4 | 287 | Internet +----+ Network | XLAT: IPv4/IPv6 288 | /Network |DNS | | Translator 289 \ +----+ / DNS: DNS64 290 \ / \\ // 291 \\ // ---------- 292 -------- 293 ====> 295 Figure 2: NAT64-CE Scenario: IPv6 Internet/Network to IPv4 Network 297 3.1. NAT64-CE Networking 299 More and more contents providers would like to use IPv6 to serve 300 customers since it allows for the definition of new services without 301 having to backward integrate into the NATs and address limitations of 302 IPv4 networks. Cloud computing is growing, which requires millions 303 of public addresses. IPv6 could provide a good opportunity to meet 304 the deployment requirements by subsiding the location to a customer 305 edge, e.g. Enterprise-GW. On the other side, residential facilities 306 is always going out of ISP control. It's hard to guarantee 307 positioned network device or installed applications are IPv6-capable. 308 Thereby, NAT64 on CPE could easily help homenet become IPv6- 309 reachable. This scenario appears in ISP network quite popular. As 310 the instances, visitors go through distant network to take care of 311 family affairs, like monitoring house security via residential 312 camera, manipulating household appliances remotely prior to comeback 313 home. 315 One big challenge for NAT64-CE is IPv6 space always much bigger than 316 IPv4 space. When increasingly numerous users in IPv6 Internet access 317 an IPv4 network, there will be not enough IPv4 addresses and/or ports 318 to serve the mapping. One potential solution is to distribute 319 NAT64-CE at separated CE domain. Each domain could reuse the IPv4 320 address defined in RFC1918 [RFC1918], which would expand IPv4 spaces 321 by increasing reuse ratio of IPv4 address. 323 Note: considering this challenge of NAT64, it is suggested that 324 NAT64-CE is only deployed and used in the scenario for small scale 325 content providers and residential network where the incoming 326 connections from the IPv6 Internet is not too many to destroy the 327 NAT64 functionalities. 329 3.2. Anti-DDoS/SYN Flood 331 For every incoming new connection from the IPv6 Internet, the 332 NAT64-CE creates state and maps that connection to an internally- 333 facing IPv4 address and port. An attacker can consume the resources 334 of the NAT64-CE device by sending an excessive number of connection 335 attempts. Without Anti-DDoS mechanism, the NAT64 is exposed to 336 attacks from the IPv6 Internet which will greatly influence the user 337 experience. Essentially, there are strong demands to have thorough 338 security mechanism to prevent malicious invasion in NAT64-CE 339 scenario. With service provisioning, potential safety hazard could 340 also deteriorate service quality. for example, DDoS will severely 341 degrade web performance. Security domain division is necessary in 342 this case, especially for NAT64-CE in enterprise network. One 343 practices in some ICP is place a L3 load balancer with capable of 10G 344 line rate DDoS defense, like SYN Flood with SYN PROXY-COOKIE. Load 345 Balancer could not only serve for optimization of traffic 346 distribution, but also take filtering helping enhanment of security. 348 3.3. User Behavior Analysis 350 The mapping information on the NAT64-CE is valuable for those who 351 deploy it. Owners or operators of NAT64-CE could use the mapping and 352 logging information for use behavior and preference analysis, and 353 acurate advertisement delivery. Different ways of achieving user 354 analysis may be applied. The NAT64-CE owner can either synchronize 355 the mapping information with its local analysis engine or deploy 356 delicated address mapping rules on the CE so that the orginal address 357 information could be kept. 359 3.4. DNS Resolving 361 In the case of NAT64-CE, it is recommended to follow the 362 recommendations in [RFC6144]. There is no need for the DNS to 363 synthesize AAAA from A records, since static AAAA records can be 364 registered in the regular DNS to represent these IPv4-only hosts. 365 How to design the FQDN for the IPv6 service is out-of-scope of this 366 document. 368 3.5. Load Balance 370 Load balance on NAT64-CE was twofold. First off, traffic should be 371 balanced among multiple NAT64-CE devices, which has identical 372 requirement with NAT64-CGN. One point should be noticed that a 373 synthetic AAAA records may be added directly in authoritative DNS. 374 The load balance based on DNS64 may not work in that cases. 375 Secondly, NAT64-CE could also serve traffic distribution for IPv4 376 backend servers. There are also some ways of load balance for the 377 cases , where the user placed NAT66 before the NAT64 so that the load 378 balancer can be implemented at the NAT66 for any user preference 379 policies. 381 3.6. MTU Consideration 383 As compared to the MTU consideration in NAT64-CGN, MTU of IPv4 384 network are strongly recommeded to set more than 1260. Since a IPv4 385 network normally operated by a particular entity, it could take 386 advantages of administrative ways to easily get rid of fragmentation 387 risks discussed in [I-D.gont-6man-ipv6-atomic-fragments]. 389 4. Security Considerations 391 This document only presents the deployment experiences of NAT64 in 392 CGN and CE scenario, some security considerations have been 393 considerated regarding to specific NAT64 mode in section 2 and 3. In 394 general, RFC 6146[RFC6146] provides TCP-tracking, Endpoint-dependent 395 filtering mechanisms to protect NAT64 from DDOS. In NAT64-CGN cases, 396 ISP also could adopt uRPF and black/white-list to enhance the 397 security by specifying access policies. for example, NAT64-CGN should 398 forbid establish NAT64 BIB for incoming IPv6 packets if URPF (Strict 399 or Loose mode) check does not pass or whose source IPv6 address is 400 associated to black-lists. 402 5. IANA Considerations 404 This memo includes no request to IANA. 406 6. Acknowledgements 408 The authors would like to thank Dan Wing, Remi Despres, Jari Arkko 409 and Fred Baker for their helpful comments. 411 7. References 412 7.1. Normative References 414 [I-D.ietf-pcp-base] 415 Cheshire, S., Boucadair, M., Selkirk, P., Wing, D., and R. 416 Penno, "Port Control Protocol (PCP)", 417 draft-ietf-pcp-base-23 (work in progress), February 2012. 419 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 420 E. Lear, "Address Allocation for Private Internets", 421 BCP 5, RFC 1918, February 1996. 423 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 424 (IPv6) Specification", RFC 2460, December 1998. 426 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 427 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 429 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 430 IPv4/IPv6 Translation", RFC 6144, April 2011. 432 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 433 NAT64: Network Address and Protocol Translation from IPv6 434 Clients to IPv4 Servers", RFC 6146, April 2011. 436 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 437 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 439 7.2. Informative References 441 [I-D.gont-6man-ipv6-atomic-fragments] 442 Gont, F., "Processing of IPv6 "atomic" fragments", 443 draft-gont-6man-ipv6-atomic-fragments-00 (work in 444 progress), December 2011. 446 [I-D.petersson-forwarded-for] 447 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 448 draft-petersson-forwarded-for-02 (work in progress), 449 November 2011. 451 [I-D.zhang-behave-nat64-load-balancing] 452 Zhang, D., Xu, X., and M. Boucadair, "Considerations on 453 NAT64 Load-Balancing", 454 draft-zhang-behave-nat64-load-balancing-03 (work in 455 progress), July 2011. 457 [RFC3924] Baker, F., Foster, B., and C. Sharp, "Cisco Architecture 458 for Lawful Intercept in IP Networks", RFC 3924, 459 October 2004. 461 Authors' Addresses 463 Gang Chen 464 China Mobile 465 53A,Xibianmennei Ave., 466 Xuanwu District, 467 Beijing 100053 468 China 470 Email: phdgang@gmail.com 472 Zhen Cao 473 China Mobile 474 53A,Xibianmennei Ave., 475 Xuanwu District, 476 Beijing 100053 477 China 479 Email: caozhen@chinamobile.com 481 Cameron Byrne 482 T-Mobile USA 483 Bellevue 484 Washington 98105 485 USA 487 Email: cameron.byrne@t-mobile.com 489 QiBo Niu 490 ZTE 491 50,RuanJian Road. 492 YuHua District, 493 Nan Jing 210012 494 China 496 Email: niu.qibo@zte.com