idnits 2.17.1 draft-ietf-v6ops-nat64-experience-02.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 : ---------------------------------------------------------------------------- == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 09, 2013) is 3943 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.anderson-siit-dc' is defined on line 718, but no explicit reference was found in the text == Unused Reference: 'RFC6269' is defined on line 780, but no explicit reference was found in the text == Unused Reference: 'RFC6883' is defined on line 799, 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) ** Obsolete normative reference: RFC 6555 (Obsoleted by RFC 8305) == Outdated reference: A later version (-05) exists of draft-chen-sunset4-cgn-port-allocation-01 == Outdated reference: A later version (-09) exists of draft-donley-behave-deterministic-cgn-05 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-4rd-05 == Outdated reference: A later version (-06) exists of draft-ietf-softwire-map-deployment-01 == Outdated reference: A later version (-08) exists of draft-ietf-softwire-map-t-02 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 3 errors (**), 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 10, 2014 C. Xie 6 China Telecom 7 D. Binet 8 France Telecom-Orange 9 July 09, 2013 11 NAT64 Operational Experiences 12 draft-ietf-v6ops-nat64-experience-02 14 Abstract 16 This document summarizes NAT64 function deployment scenarios and 17 operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) 18 and NAT64-FE (NAT64 server Front End) are considered in this 19 document. 21 Status of This Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on January 10, 2014. 38 Copyright Notice 40 Copyright (c) 2013 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 56 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 3. NAT64 Networking Experiences . . . . . . . . . . . . . . . . 4 58 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 59 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 5 60 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 6 61 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 6 62 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8 63 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 64 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 65 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 66 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 67 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 68 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 69 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 70 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 71 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 73 11. Additional Author List . . . . . . . . . . . . . . . . . . . 14 74 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 76 12.2. Informative References . . . . . . . . . . . . . . . . . 16 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 79 1. Introduction 81 Now that IANA's global IPv4 address pool has been exhausted, IPv6 is 82 the only sustainable solution for numbering nodes on Internet. 83 Network operators have to deploy IPv6-only networks in order to meet 84 the needs of the expanding internet without available IPv4 addresses. 86 As IPv6 deployment continues, IPv6 networks and hosts will need to 87 coexist with IPv4 numbered resources. The Internet will include 88 nodes that are dual-stack, nodes that remain IPv4-only, and nodes 89 that can be deployed as IPv6-only nodes. 91 Single stack IPv6 network deployment can simplify the network 92 provisioning. Some justifications have been described in 464xlat 93 [RFC6877]. As an example, IPv6-only connectivity confers some 94 benefits to mobile operators. In such mobile context, it enables the 95 use of a single IPv6 PDP(Packet Data Protocol) context or EPS 96 (Evolved Packet System) bearer if Long Term Evolution (LTE) network 97 is considered, which eliminates significant network costs caused by 98 doubling the number of PDP contexts in some cases and the need of 99 IPv4 addresses to be assigned to customers. In broadband networks 100 overall, it can allow for the scaling of edge-network growth 101 decoupled from IPv4 numbering limitations. 103 In a transition scenario, some existing networks are likely to be 104 IPv4-only configured for quite a long time. Allowing for 105 interconnection between IPv4-only nodes and IPv6-only nodes is a 106 critical capability for service continuity. Widespread dual-stack 107 deployments have not materialized at the anticipated rate over the 108 last 10 years, one possible conclusion being that legacy networks 109 will not make the jump quickly. A translation mechanism based on a 110 NAT64[RFC6146] [RFC6145]function is likely to be a key element of the 111 Internet for IPv6-IPv4 interoperability. 113 [RFC6036] reported at least 30% of operators plan to run some kind of 114 translator (presumably NAT64/DNS64). Advice on NAT64 deployment and 115 operation is therefore of some importance. [RFC6586] documented the 116 implications for IPv6 only networks. This document intends to be 117 specific to NAT64 network planning. 119 2. Terminology 121 In regards to IPv4/IPv6 translation, [RFC6144] has described a 122 framework of enabling networks to make interworking possible between 123 IPv4 and IPv6 networks. This document has further categorized 124 different NAT64 function locations and use cases. The principle 125 distinction of location is if the NAT64 is located in a NAT64-CGN 126 (Carrier Grade NATs) or NAT64-FE (server Front End). The terms of 127 NAT-CGN/FE are understood to be a topological distinction indicating 128 different features employed in a NAT64 deployment. 130 NAT64-CGN: A NAT64-CGN (Carrier Grade NATs) is placed in an ISP 131 network. IPv6 subscribers leverage the NAT64-CGN to access 132 existing IPv4 internet services. The ISP as an administrative 133 entity takes full control on the IPv6 side, but has limited or no 134 control on the IPv4 side. NAT64-CGN may have to consider the IPv4 135 Internet environment and services to make appropriate 136 configurations. 138 NAT64-FE: A NAT64-FE (server Front End) is generally a device with 139 NAT64 functionalities in a content provider or data center 140 network. It could be for example a traffic load balancer or a 141 firewall. The operator of the NAT64-FE has full control over the 142 IPv4 network within the data center, but only limited influence or 143 control over the external IPv6 network. 145 3. NAT64 Networking Experiences 147 3.1. NAT64-CGN Consideration 149 Fixed network operators and mobile operators may locate NAT64 in 150 access networks or in mobile core networks. It can be built into 151 various devices, including routers, gateways or firewalls in order to 152 connect IPv6 users to the IPv4 Internet. With regard to the numbers 153 of users and the shortage of public IPv4 addresses, stateful 154 NAT64[RFC6146] is more adapted to perform some maximal sharing of 155 public IPv4 addresses. The usage of stateless NAT64 can be seen with 156 better transparency features 157 [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be 158 coordinated with A+P[RFC6346] processes as specified in 159 [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope 160 with IPv4 shortage. 162 DNS64[RFC6147] is recommended for use in combination with stateful 163 NAT64, and will likely be an essential part of an IPv6 single-stack 164 network that couples to the IPv4 Internet. And, it will help 464xlat 165 to automatically discover NAT64 prefix through 166 [I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name 167 Daemon(BIND) software supports the function. It's important to note 168 that DNS64 generates the synthetic AAAA reply when services only 169 register A records. Operators should not expect to access IPv4 parts 170 of a dual-stack server using NAT64/DNS64. NAT64 would forwards all 171 the traffic on IPv6 paths if dual-stack servers are targeted. In 172 some sense, it encourages IPv6 transmission and restrains NAT uses 173 compared to NAT44(if used), on which all traffic flows have to 174 traverse. Therefore, NAT64 may serve double roles in some cases, 175 i.e. a translator and IPv6 forwarder. Some failure cases may occur 176 once NAT64 serves a IPv6 gateway but is configured only with IPv4 on 177 WAN links. We tested on Top100 websites (referring to [Alexa] 178 statistics) in such condition. 43% of websites are failed to be 179 connected since those websites have both AAAA and A records. To be 180 reliable, it's recommended to enable NAT64 WAN links with dual-stack 181 connections in the deployment. 183 All connections to IPv4 services from IPv6-only clients must traverse 184 the NAT64-CGN. It can be advantageous from the vantage-point of 185 troubleshooting and traffic engineering to carry the IPv6 traffic 186 natively for as long as possible within an access network and 187 translate packets only at or near the network egress. NAT64 can be 188 considered as a feature of the AS (Autonomous System) border in fixed 189 networks. And, it is likely to be deployed in an IP node beyond the 190 GGSN (Gateway GPRS Support Node) or PDN-GW (Public Data Network- 191 Gateway) in mobile networks or directly in the gateway itself in some 192 situations. This allows consistent attribution and traceability 193 within the service provider network. It has been observed that the 194 process of correlating log information is problematic from multiple- 195 vendor's equipments due to inconsistent formats of log records. 196 Placing NAT64 in a centralized location may reduce diversity of log 197 format and simplify the network provisioning. Moreover, since NAT64 198 is only targeted at serving traffic flows from IPv6 to IPv4-only 199 services, the user traffic volume should not be as high as in a NAT44 200 scenario, and therefore, the gateway's capacity in such location may 201 not be as much of a concern or a hurdle to deployment. On the other 202 hand, the placement in a centralized way would require more strict 203 high availability (HA) design. It would also make geo-location based 204 on IPv4 addresses rather inaccurate as it is currently the case for 205 NAT44 CGN already deployed in ISP networks. More considerations or 206 workarounds on HA and traceability could be found at Section4 and 207 Section5 . 209 NAT64 could likely co-exist with NAT44 in a dual-stack network mostly 210 because IPv4 private addresses are allocated to customers. The 211 coexistence has already appeared in mobile networks, in which dual 212 stack mobile phones normally initiate some dual-stack PDN/PDP 213 Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated 214 addresses are very often private ones. [RFC6724] always prioritizes 215 IPv6 connections regardless of whether the end-to-end path is native 216 IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy 217 Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The 218 selection of IPv4/IPv6 paths may depend on particular implementation 219 choices or settings on a host-by-host basis, and may differ from an 220 operator's deterministic scheme. Our tests verified that hosts may 221 find themselves switching between IPv4 and IPv6 paths as they access 222 identical service, but at different times 223 [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each 224 path is different, it may cause unstable user experiences and some 225 degradation of Quality of Experience (QoE) when fallback to the other 226 protocol is not powerful enough for example. It's also difficult for 227 operators to debug the issue and make optimal resource usages on both 228 NAT44 and NAT64. It's desirable to find the solutions that will 229 allow introducing IPv6/IPv4 translation service to IPv6-only hosts 230 while keeping dual-stack hosts unaffected and IPv4 service unchanged. 232 3.2. NAT64-FE Consideration 234 Some Internet Content Providers (ICPs) may locate NAT64 in front of 235 an Internet Data Center (IDC), for example co-located with load 236 balancing function. Load balancers are employed to connect different 237 IP family domains, meanwhile distribute workloads across multiple 238 domains or internal servers actually. In some cases, IPv4 addresses 239 exhaustion may not be a problem in some IDC's networks. IPv6 support 240 for some applications may require some investments and workloads so 241 IPv6 support may not be a priority. The use of NAT64 may be served 242 to support widespread IPv6 adoption on the Internet while maintaining 243 IPv4-only applications access. 245 Different strategy has been described in [RFC6883]referred to as 246 "inside out" and "outside in". An IDC operator may implement the 247 following practices in the NAT64-FE networking. 249 o Some ICPs who already have satisfactory operational experiences 250 would adopt single stack IPv6 operations to build up their data 251 center network, servers and applications since it allows new 252 services delivery without having to integrate consideration of 253 IPv4 NAT and address limitations of IPv4 networks. Stateless 254 NAT64[RFC6145]is used to provide services for IPv4-only 255 subscribers. [I-D.anderson-siit-dc]has provided further 256 descriptions and guidelines. 258 o ICPs who attempt to offer customers IPv6 support in their 259 application farms at an early stage may likely run some proxies, 260 which are configured to handle incoming IPv6 flows and proxy them 261 to IPv4 back-end systems. Many load balancers have already 262 integrated some proxy functionalities. IPv4 addresses configured 263 in the proxy can be multiplexed like a stateful NAT64 performs. A 264 similar challenge exists once increasingly numerous users in IPv6 265 Internet access an IPv4 network. High loads on load-balancers may 266 be apt to cause additional latency, IPv4 pool exhaustion, etc. 267 Therefore, this approach is only reasonable at an early stage. 268 ICPs may learn from the experiences and move on to dual-stack or 269 IPv6 single stack in a further stage, since the native IPv6 is 270 always more desirable than transition solutions. 272 [RFC6144] recommends that AAAA records of load-balancers or 273 application servers can be directly registered in the authoritative 274 DNS servers requiring to populate these servers with corresponding 275 AAAA records. In this case, there is no need to deploy DNS64 276 servers. Those AAAA records can be some native IPv6 addresses or 277 some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 278 address does not give the possibility to nodes to get any information 279 about NAT64 presence on communication path and the possibility to 280 prefer IPv4 path or the IPv6 path in dual-stack networks. Using an 281 independent sub domain e.g. ipv6exp.xxx.xxx may help to identify 282 experimental ipv6 services to users. How to design the FQDN for the 283 IPv6 service is out-of-scope of this document. 285 4. High Availability 287 4.1. Redundancy Design 288 High Availability (HA) is a major requirement for every service and 289 network services. The deployment of redundancy mechanism is an 290 essential approach to avoid single-point failure and significantly 291 increase the network reliability. It's not only useful to stateful 292 NAT64 cases, but also to stateless NAT64 gateways. 294 Three redundancy modes are mainly used hereafter: cold standby, warm 295 standby and hot standby. 297 o Cold standby can't replicate the NAT64 states from the primary 298 equipment to the backup. Administrators switch on the backup 299 NAT64 only if the primary NAT64 fails. As the results, all the 300 existing established sessions will be disconnected. The internal 301 hosts are required to re-establish sessions to the external hosts. 302 Since the backup NAT64 is manually configured to switch over to 303 active NAT64, it may have unpredictable impacts to the ongoing 304 services. Normally, the handover would take several minutes so as 305 to wait for the whole process of NAT64 bootstrap loader. 307 o Warm standby is a flavor of the cold standby mode. Backup NAT64 308 would keep running once the primary NAT64 is working. This makes 309 warm standby less time consuming during the traffic failover. 310 Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a 311 solution to enable automatic handover in the warm standby. It was 312 tested that the handover takes as maximum as 1 minute if the 313 backup NAT64 needs to take over routing and re-construct the 314 Binding Information Base (BIB) for 30 million sessions. In 315 deployment phase, operators could balance loads on distinct NAT64s 316 devices. Those NAT64s make a warm backup of each other. 318 o Hot standby must synchronize the BIBs between the primary NAT64 319 and backup. When the primary NAT64 fails, backup NAT64 would take 320 over and maintain the state of all existing sessions. The 321 internal hosts don't have to re-connect the external hosts. The 322 handover time has been extremely reduced. Thanks to Bidirectional 323 Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay 324 of only 35ms for 30 million sessions handover was observed during 325 testing. In some sense, it could guarantee the session continuity 326 for every service. In order to timely transmit states 327 information, operators may have to deploy extra transport links 328 between primary NAT64 and distant backup. 330 In general, cold-standby and warm-standby is simpler and less 331 resource intensive, but it requires clients to re-establish sessions 332 when a fail-over occurs. Hot standby doubles resource's consumption 333 to synchronize the states, but it achieve seamless handover. The 334 consideration of redundancy mode for stateless NAT64 is simple, 335 because it doesn't have to consider time consuming for states 336 maintenance. The warm standby is sufficient for stateless NAT64. In 337 regards to stateful NAT64, it maybe useful to investigate performance 338 tolerance of applications and the traffic characteristics in a 339 particular network. The following table is trying to evaluate user 340 experience from a lab testing. 342 Table 1: The acceptable delay of applications 343 +----------------+------------------------+-------------------------+ 344 | APPs | Acceptable Interrupt | Session Continuity | 345 | | Recovery | | 346 +----------------+------------------------+-------------------------+ 347 | Web Browse |As maximum as 6s | No | 348 +----------------+------------------------+-------------------------+ 349 |Http streaming |As maximum as 10s(cache)| Yes | 350 +----------------+------------------------+-------------------------+ 351 | Gaming | 200ms~400ms | Yes | 352 +----------------+------------------------+-------------------------+ 353 | P2P | 10~16s | Yes | 354 +----------------+------------------------+-------------------------+ 355 |Instant Message |1 minute | Yes | 356 +----------------+------------------------+-------------------------+ 357 |Mail |30 seconds | No | 358 +----------------+------------------------+-------------------------+ 359 |Downloading |1 minutes | No | 360 +----------------+------------------------+-------------------------+ 362 Our statistics in a mobile network shown that almost 91.21% of amount 363 of traffic is accounted by browsing services. Those services don't 364 require session continuity. The handover time of warm standby is 365 qualified to the delay tolerance. Hot-standby does not offer much 366 benefit for those sessions on this point. In a fixed network, HTTP 367 streaming, p2p and online games would be the major 368 traffic[Cisco-VNI]. Consideration should be given to the importance 369 of maintaining bindings for those sessions across failovers. 370 Operators may also consider the Average Revenue Per User (ARPU) 371 factors to deploy suitable redundancy mode. Warm standby may still 372 be adopted to cover most services while hot standby could be used to 373 upgrade Quality of Experience (QoE) using DNS64 with different 374 synthetic responses for limited traffic. Further considerations are 375 discussed at Section 6. 377 4.2. Load Balancing 379 Load balancing is used to accompany redundancy design so that better 380 scalability and resiliency could be achieved. Stateless NAT64s allow 381 asymmetric routing while anycast-based solutions are recommended in 382 [I-D.ietf-softwire-map-deployment]. The deployment of load balancing 383 may make more sense to stateful NAT64s for the sake of single-point 384 failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct 385 facilities, the following lists the considerations for each case. 387 o NAT64-CGN equipments don't implement load balancer functions on a 388 board card. Therefore, the gateways have to resort to DNS64 or 389 internal host's behavior. Once DNS64 is deployed, the load 390 balancing can be performed by synthesizing AAAA response with 391 different IPv6 prefixes. With the absence of DNS64, internal 392 hosts could learn multiple IPv6 prefixes through the approaches 393 defined in[I-D.ietf-behave-nat64-discovery-heuristic] and then 394 select one based on a given prefix selection policy. 396 o A dedicated Load Balancer could be deployed at front of a NAT64-FE 397 farm. Load Balancer uses proxy mode to redirect the flows to the 398 appropriate NAT64 instance. Stateful NAT64s require a 399 deterministic pattern to arrange the traffic in order to ensure 400 outbound/inbound flows traverse the identical NAT64. Therefore, 401 static scheduling algorithms, for example source-address based 402 policy, is preferred. A dynamic algorithm, for example Round- 403 Robin, may have impacts on applications seeking session 404 continuity, which described in the Table 1. 406 5. Source Address Transparency 408 5.1. Traceability 410 Traceability is required in many cases such as identifying malicious 411 attacks sources and accounting requirements. Operators are asked to 412 record the NAT64 log information for specific periods of time. In 413 our lab testing, the log information from 200,000 subscribers have 414 been collected from a stateful NAT64 gateway for 60 days. 415 Syslog[RFC5424] has been adopted to transmit log message from NAT64 416 to a log station. Each log message contains transport protocol, 417 source IPv6 address:port, translated IPv4 address: port and 418 timestamp. It takes almost 125 bytes long in ASCII format. It has 419 been verified that the volume of recorded information reach up to 420 42.5 terabytes in the raw format and 29.07 terabytes in a compact 421 format. Operators have to build up dedicated transport links, 422 storage system and servers for the purpose. There are also several 423 implementations to mitigate the issue. For example, stateful NAT64 424 could dynamically assign a port range to each subscriber or perform 425 static port-range allocations as 426 [I-D.donley-behave-deterministic-cgn] proposed. Those methods can 427 change log granularity from per-session to per-customer. The 428 recorded log volume can be reduced to 40.6 gigabytes accordingly. 429 However, the IPv4 multiplexing efficiency is also decreased regarding 430 to those methods. For example, the utilization ratio of public IPv4 431 address is dropped approximately to 75% when sized 400 ports range 432 allocated to each device according to our statistics. In addition, 433 port-range based allocation should also consider port randomization 434 described in [RFC6056] . A trade-off among address multiplexing 435 efficiency, logging storage compression and port allocation 436 complexity should be considered. More discussions could be found in 437 [I-D.chen-sunset4-cgn-port-allocation].Basically, the decision 438 depends on usable IPv4 resource and investments of log systems. 440 5.2. Geo-location 442 IP addresses are usually used as inputs to geo-location services. 443 The use of address sharing will prevent these systems from resolving 444 the location of a host based on IP address alone. Applications that 445 assume such geographic information may not work as intended. The 446 possible solutions listed in [RFC6967] are intended to bridge the 447 gap. However, those solutions can only provide a sub-optimal 448 substitution to solve the problem of host identification, in 449 particular it may not today solve problems with source identification 450 through translation. The following lists current practices to 451 mitigate the issue. 453 o Operators who adopt NAT64-FE may leverage the application layer 454 proxies, e.g. XFF (X-Forwarded-For) 455 [I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source 456 address in HTTP headers. Those messages would be passed on to 457 web-servers. The queried server can lookup Radius servers for the 458 target subscribers based on IPv6 addresses included in XFF HTTP 459 headers. XFF is the de facto standard which has been integrated 460 in most Load Balancers. Therefore, it may be superior to use in a 461 NAT-FE environment. In the downsides, XFF is specific to HTTP. 462 It restricts the usages so that the solution can't be applied to 463 requests made over HTTPs. This makes geo-location problematic for 464 HTTPs based services. 466 o The NAT64-CGN equipments may not implement XFF. Geo-location 467 based on shared IPv4 address is rather inaccurate in that case. 468 It's desirable to offer geo-location system more information, for 469 example port number to retrieve the internal IPv6 address, which 470 has meaning in global scale. We have investigated to deliver 471 NAT64 BIBs and Session Table Entrys (STEs) to a Radius 472 server[I-D.chen-behave-nat64-radius-extension], since current geo- 473 location systems rely on a Radius database to inspect location 474 information, for example the information provided in [RFC5580]. 475 Those methods could convey original source address through same 476 message bus. Another approach is to ask NAT64-CGN providing 477 application aware gateway to insert IPv6 source addresses. 478 However, that may introduce complexity and performance 479 degradation. 481 6. Quality of Experience 483 6.1. Service Reachability 485 NAT64 is providing a translation capability between IPv6 and IPv4 486 end-nodes. In order to provide the reachability between two IP 487 address families, NAT64-CGN has to implement appropriate application 488 aware functions, i.e. Application Layer Gateway(ALG), where address 489 translation is not itself sufficient and security mechanisms do not 490 render it infeasible. Most NAT64-CGNs mainly provide FTP- 491 ALG[RFC6384]. NAT64-FEs may have functional richness on Load 492 Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have 493 been supported. It should be noted that ALGs may impact the 494 performance on a NAT64 box to some extent. ISPs as well as content 495 providers might choose to avoid situations where the imposition of an 496 ALG might be required. At the same time, it is also important to 497 remind customers and application developers that IPv6 end-to-end 498 usage does not require ALG imposition and therefore results in a 499 better overall user experience. 501 6.2. Resource Reservation 503 Session status normally is managed by a static timer. For example, 504 the value of the "established connection idle-timeout" for TCP 505 sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 506 minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe 507 significantly consumed by largely inactive users. The NAT translator 508 and other customers would suffer from service degradation due to port 509 consummation by other subscribers using the same NAT64 device. A 510 flexible NAT session control is desirable to resolve the issues. 511 PCP[RFC6887] could be a candidate to provide such capability. A 512 NAT64-CGN should integrate with a PCP server, to allocate available 513 IPv4 address/port resources. Resources could be assigned to PCP 514 clients through PCP MAP/PEER mode. Such ability can be considered to 515 upgrade user experiences, for example assigning different sizes of 516 port ranges for different subscribers. Those mechanisms are also 517 helpful to minimize terminal battery consumption and reduce the 518 number of keep-alive messages to be sent by mobile terminal devices. 520 Subscribers can also benefit from network reliability. It has been 521 discussed that hot-standby offers satisfactory experience once outage 522 of primary NAT64 is occurred. Operators may rightly be concerned 523 about the considerable investment required for NAT64 equipment 524 relative to low ARPU income. For example, transport links may cost 525 much, because primary NAT64 and backup are normally located at 526 different locations, separated by a relatively large distance. 527 Additional maintenance has to be spent to ensure the connectivity 528 quality. However, that may be necessary to some applications, which 529 are delay-sensitive and seek session continuity, for example on-line 530 games and live-streaming. Operators may be able to get added-values 531 from those services by offering first-class services. It can be pre- 532 configured on the gateway to hot-standby modes depending on 533 subscriber's profile. The rest of other sessions can be covered by 534 cold/warm standby. 536 7. MTU Considerations 538 IPv6 requires that every link in the internet have an Maximum 539 Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However, 540 in case of NAT64 translation deployment, some IPv4 MTU constrained 541 link will be used in some communication path and originating IPv6 542 nodes may therefore receive an ICMP Packet Too Big (PTB) message, 543 reporting a Next-Hop MTU less than 1280 bytes. The result would be 544 that IPv6 allows packets to contain a fragmentation header, without 545 the packet being fragmented into multiple pieces. A NAT64 would 546 receive IPv6 packets with fragmentation header in which "M" flag 547 equal to 0 and "Fragment Offset" equal to 0. Those packets likely 548 impact other fragments already queued with the same set of {IPv6 549 Source Address, IPv6 Destination Address, Fragment Identification}. 550 If the NAT64 box is compliant with [RFC5722], there is risk that all 551 the fragments have to be dropped. 553 [RFC6946] discusses how this situation could be exploited by an 554 attacker to perform fragmentation-based attacks, and also proposes an 555 improved handling of such packets. It required enhancements on NAT64 556 gateway implementations to isolate packet's processing. NAT64 should 557 follow the recommendation and take steps to prevent the risks of 558 fragmentation. 560 Another approach that potentially avoids this issue is to configure 561 IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB 562 smaller than 1280 bytes. Such an operational consideration is hard 563 to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. 564 However, it's a feasible approach in NAT64-FE cases, since a IPv4 565 network NAT64-FE connected is rather well-organized and operated by a 566 IDC operator or content provider. Therefore, the MTU of IPv4 network 567 in NAT64-FE case are strongly recommended to set to more than 1260 568 bytes. 570 8. Security Considerations 572 This document presents the deployment experiences of NAT64 in CGN and 573 FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking, 574 address-dependent filtering mechanisms to protect NAT64 from 575 Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators 576 also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and 577 black/white-list to enhance the security by specifying access 578 policies. For example, NAT64-CGN should forbid establish NAT64 BIB 579 for incoming IPv6 packets if uRPF in Strict or Loose mode check does 580 not pass or whose source IPv6 address is associated to black-lists. 582 The stateful NAT64-FE creates state and maps that connection to an 583 internally-facing IPv4 address and port. An attacker can consume the 584 resources of the NAT64-FE device by sending an excessive number of 585 connection attempts. Without a DDoS limitation mechanism, the 586 NAT64-FE is exposed to attacks. Load Balancer is recommended to 587 enable the capabilities of line rate DDOS defense, such as the 588 employment of SYN PROXY-COOKIE. Security domain division is 589 necessary as well in this case. Therefore, Load Balancers could not 590 only serve for optimization of traffic distribution, but also prevent 591 service from quality deterioration due to security attacks. 593 9. IANA Considerations 595 This memo includes no request to IANA. 597 10. Acknowledgements 599 The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, 600 Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum, Philip 601 Matthews and Randy Bush for their helpful comments. 603 Many thanks to Wesley George and Satoru Matsushima for their reviews. 605 The authors especially thank Joel Jaeggli and Ray Hunter for his 606 efforts and contributions on editing which substantially improves the 607 legibility of the document. 609 Thanks to Cameron Byrne who was an active co-author of some earlier 610 versions of this draft. 612 11. Additional Author List 614 The following are extended authors who contributed to the effort: 616 Qiong Sun 617 China Telecom 618 Room 708, No.118, Xizhimennei Street 619 Beijing 100035 620 P.R.China 621 Phone: +86-10-58552936 622 Email: sunqiong@ctbri.com.cn 624 QiBo Niu 625 ZTE 626 50,RuanJian Road. 627 YuHua District, 628 Nan Jing 210012 629 P.R.China 630 Email: niu.qibo@zte.com.cn 632 12. References 634 12.1. Normative References 636 [I-D.ietf-appsawg-http-forwarded] 637 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 638 draft-ietf-appsawg-http-forwarded-10 (work in progress), 639 October 2012. 641 [I-D.ietf-behave-nat64-discovery-heuristic] 642 Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 643 the IPv6 Prefix Used for IPv6 Address Synthesis", draft- 644 ietf-behave-nat64-discovery-heuristic-17 (work in 645 progress), April 2013. 647 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 648 (IPv6) Specification", RFC 2460, December 1998. 650 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 651 Networks", BCP 84, RFC 3704, March 2004. 653 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 654 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 655 RFC 4787, January 2007. 657 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 658 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 659 RFC 5382, October 2008. 661 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 663 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 664 Aboba, "Carrying Location Objects in RADIUS and Diameter", 665 RFC 5580, August 2009. 667 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 668 RFC 5722, December 2009. 670 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 671 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 673 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 674 (BFD)", RFC 5880, June 2010. 676 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 677 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 678 October 2010. 680 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 681 Algorithm", RFC 6145, April 2011. 683 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 684 NAT64: Network Address and Protocol Translation from IPv6 685 Clients to IPv4 Servers", RFC 6146, April 2011. 687 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 688 Beijnum, "DNS64: DNS Extensions for Network Address 689 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 690 April 2011. 692 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 693 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 695 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 696 Dual-Stack Hosts", RFC 6555, April 2012. 698 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 699 "Default Address Selection for Internet Protocol Version 6 700 (IPv6)", RFC 6724, September 2012. 702 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 703 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 704 2013. 706 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 707 6946, May 2013. 709 12.2. Informative References 711 [Alexa] Alexa, "http://www.alexa.com/topsites", April 2013. 713 [Cisco-VNI] 714 Cisco, "Cisco Visual Networking Index: Forecast and 715 Methodology, 2012-2017, 716 http://ciscovni.com/forecast-widget/index.html", May 2013. 718 [I-D.anderson-siit-dc] 719 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 720 Centre Environments", draft-anderson-siit-dc-00 (work in 721 progress), November 2012. 723 [I-D.chen-behave-nat64-radius-extension] 724 Chen, G. and D. Binet, "Radius Attributes for Stateful 725 NAT64", draft-chen-behave-nat64-radius-extension-00 (work 726 in progress), July 2013. 728 [I-D.chen-sunset4-cgn-port-allocation] 729 Chen, G., "Analysis of NAT64 Port Allocation Method", 730 draft-chen-sunset4-cgn-port-allocation-01 (work in 731 progress), February 2013. 733 [I-D.donley-behave-deterministic-cgn] 734 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 735 and O. Vautrin, "Deterministic Address Mapping to Reduce 736 Logging in Carrier Grade NAT Deployments", draft-donley- 737 behave-deterministic-cgn-05 (work in progress), January 738 2013. 740 [I-D.ietf-softwire-4rd] 741 Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and 742 M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless 743 Solution (4rd)", draft-ietf-softwire-4rd-05 (work in 744 progress), April 2013. 746 [I-D.ietf-softwire-map-deployment] 747 Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, 748 "Mapping of Address and Port (MAP) - Deployment 749 Considerations", draft-ietf-softwire-map-deployment-01 750 (work in progress), February 2013. 752 [I-D.ietf-softwire-map-t] 753 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 754 T. Murakami, "Mapping of Address and Port using 755 Translation (MAP-T)", draft-ietf-softwire-map-t-02 (work 756 in progress), July 2013. 758 [I-D.ietf-softwire-stateless-4v6-motivation] 759 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 760 Borges, I., and G. Chen, "Motivations for Carrier-side 761 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 762 softwire-stateless-4v6-motivation-05 (work in progress), 763 November 2012. 765 [I-D.kaliwoda-sunset4-dual-ipv6-coexist] 766 Kaliwoda, A. and D. Binet, "Co-existence of both dual- 767 stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual- 768 ipv6-coexist-01 (work in progress), October 2012. 770 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 771 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 773 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 774 Protocol Port Randomization", BCP 156, RFC 6056, January 775 2011. 777 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 778 IPv4/IPv6 Translation", RFC 6144, April 2011. 780 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 781 Roberts, "Issues with IP Address Sharing", RFC 6269, June 782 2011. 784 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 785 IPv4 Address Shortage", RFC 6346, August 2011. 787 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 788 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 789 Partnership Project (3GPP) Evolved Packet System (EPS)", 790 RFC 6459, January 2012. 792 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 793 Network", RFC 6586, April 2012. 795 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 796 Combination of Stateful and Stateless Translation", RFC 797 6877, April 2013. 799 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 800 Content Providers and Application Service Providers", RFC 801 6883, March 2013. 803 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 804 "Analysis of Potential Solutions for Revealing a Host 805 Identifier (HOST_ID) in Shared Address Deployments", RFC 806 6967, June 2013. 808 Authors' Addresses 810 Gang Chen 811 China Mobile 812 53A,Xibianmennei Ave., 813 Xuanwu District, 814 Beijing 100053 815 China 817 Email: phdgang@gmail.com 819 Zhen Cao 820 China Mobile 821 53A,Xibianmennei Ave., 822 Xuanwu District, 823 Beijing 100053 824 China 826 Email: caozhen@chinamobile.com 828 Chongfeng Xie 829 China Telecom 830 Room 708 No.118, Xizhimenneidajie 831 Beijing 100035 832 P.R.China 834 Email: xiechf@ctbri.com.cn 835 David Binet 836 France Telecom-Orange 837 Rennes 838 35000 839 France 841 Email: david.binet@orange.com