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