idnits 2.17.1 draft-ietf-v6ops-nat64-experience-07.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 (December 23, 2013) is 3770 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC5245' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'I-D.anderson-siit-dc' is defined on line 838, but no explicit reference was found in the text == Unused Reference: 'RFC6269' is defined on line 912, but no explicit reference was found in the text == Unused Reference: 'RFC6883' is defined on line 931, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 5245 (Obsoleted by RFC 8445, RFC 8839) ** 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 (-06) exists of draft-ietf-softwire-map-deployment-03 == 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-01 -- Obsolete informational reference (is this intentional?): RFC 6036 (Obsoleted by RFC 9386) Summary: 4 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force G. Chen 3 Internet-Draft Z. Cao 4 Intended status: Informational China Mobile 5 Expires: June 26, 2014 C. Xie 6 China Telecom 7 D. Binet 8 France Telecom-Orange 9 December 23, 2013 11 NAT64 Operational Experience 12 draft-ietf-v6ops-nat64-experience-07 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 June 26, 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 Experience . . . . . . . . . . . . . . . . . 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 . . . . . . . . . . . . . . . . . . . 5 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 . . . . . . . . . . . . . . . . . . . . . 9 66 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 67 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 68 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 69 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 70 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 71 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 72 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 73 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 74 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 75 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 76 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 77 12. Additional Author List . . . . . . . . . . . . . . . . . . . 16 78 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 79 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 80 13.2. Informative References . . . . . . . . . . . . . . . . . 18 81 Appendix A. Testing Results of Application Behavior . . . . . . 20 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 21 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 networks 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 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP 132 network. IPv6 subscribers leverage the NAT64-CGN to access 133 existing IPv4 internet services. The ISP as an administrative 134 entity takes full control on the IPv6 side, but has limited or no 135 control on the IPv4 side. NAT64-CGN may have to consider the IPv4 136 Internet environment and services to make appropriate 137 configurations. 139 NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device 140 with NAT64 functionality in a content provider or data center 141 network. It could be for example a traffic load balancer or a 142 firewall. The operator of the NAT64-FE has full control over the 143 IPv4 network within the data center, but only limited influence or 144 control over the external IPv6 network. 146 3. NAT64 Networking Experience 148 3.1. NAT64-CGN Consideration 150 3.1.1. NAT64-CGN Usages 152 Fixed network operators and mobile operators may locate NAT64 in 153 access networks or in mobile core networks. It can be built into 154 various devices, including routers, gateways or firewalls in order to 155 connect IPv6 users to the IPv4 Internet. With regard to the numbers 156 of users and the shortage of public IPv4 addresses, stateful 157 NAT64[RFC6146] is more adapted to perform some maximal sharing of 158 public IPv4 addresses. The usage of stateless NAT64 can be seen with 159 better transparency features 160 [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be 161 coordinated with A+P[RFC6346] processes as specified in 162 [I-D.ietf-softwire-map-t] in order to cope 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 [RFC7050]. Berkeley 172 Internet Name Daemon (BIND) software supports the function. It's 173 important to note that DNS64 generates the synthetic AAAA reply when 174 services only register A records. Operators should not expect to 175 access IPv4 parts of a dual-stack server using NAT64/DNS64. The 176 traffic is forwarded on IPv6 paths if dual-stack servers are 177 targeted. IPv6 traffic may be routed not going through NAT64. Only 178 the traffic going to IPv4-only service would traverse NAT64. In some 179 sense, it encourages IPv6 transmission and restrains NAT uses 180 compared to NAT44(if used), on which all traffic flows have to be 181 traversed and translated. In some cases, NAT64-CGN may serve double 182 roles, i.e. a translator and IPv6 forwarder. In mobile networks, 183 NAT64 is likely deployed as the default gateway serving for all the 184 IPv6 traffic. The traffic heading to a dual-stack server is only 185 forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested 186 to be configured on the Internet faced interfaces of NAT64. We 187 tested on Top100 websites (referring to [Alexa] statistics). 43% of 188 websites are connected and forwarded on the NAT64 since those 189 websites have both AAAA and A records. With expansion of IPv6 190 supports, the translation process on NAT64 will likely be faded. 192 3.1.3. NAT64 Placement 194 All connections to IPv4 services from IPv6-only clients must traverse 195 the NAT64-CGN. It can be advantageous from the vantage-point of 196 troubleshooting and traffic engineering to carry the IPv6 traffic 197 natively for as long as possible within an access network and 198 translate packets only at or near the network egress. NAT64 can be 199 considered as a feature of the Autonomous System (AS) border in fixed 200 networks. And, it is likely to be deployed in an IP node beyond the 201 Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway 202 (PDN-GW) in mobile networks or directly in the gateway itself in some 203 situations. This allows consistent attribution and traceability 204 within the service provider network. It has been observed that the 205 process of correlating log information is problematic from multiple- 206 vendor's equipment due to inconsistent formats of log records. 207 Placing NAT64 in a centralized location may reduce diversity of log 208 format and simplify the network provisioning. Moreover, since NAT64 209 is only targeted at serving traffic flows from IPv6 to IPv4-only 210 services, the user traffic volume should not be as high as in a NAT44 211 scenario, and therefore, the gateway's capacity in such location may 212 not be as much of a concern or a hurdle to deployment. On the other 213 hand, the placement in a centralized way would require more strict 214 high availability (HA) design. It would also make geo-location based 215 on IPv4 addresses rather inaccurate as it is currently the case for 216 NAT44 CGN already deployed in ISP networks. More considerations or 217 workarounds on HA and traceability could be found at Section 4 and 218 Section 5. 220 3.1.4. Co-existence of NAT64 and NAT44 222 NAT64 could likely co-exist with NAT44 in a dual-stack network mostly 223 because IPv4 private addresses are allocated to customers. The 224 coexistence has already appeared in mobile networks, in which dual 225 stack mobile phones normally initiate some dual-stack PDN/PDP 226 Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated 227 addresses are very often private ones. [RFC6724] always prioritizes 228 IPv6 connections regardless of whether the end-to-end path is native 229 IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy 230 Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The 231 selection of IPv4/IPv6 paths may depend on particular implementation 232 choices or settings on a host-by-host basis, and may differ from an 233 operator's deterministic scheme. Our tests verified that hosts may 234 find themselves switching between IPv4 and IPv6 paths as they access 235 identical service, but at different times 236 [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each 237 path is different, it may cause unstable user experiences and some 238 degradation of Quality of Experience (QoE) when fallback to the other 239 protocol is not powerful enough. It's also difficult for operators 240 to find a solution to make a stable network with optimal resource 241 utilization. In general, it's desirable to figure out the solution 242 that will introduce IPv6/IPv4 translation service to IPv6-only hosts 243 connecting to IPv4 servers while making sure dual-stack hosts to have 244 at least one address family accessible via native service if it's 245 possible. With the end-to-end native IPv6 environment is available, 246 hosts should be upgraded aggressively to migrate to IPv6-only. There 247 is an ongoing effort to detect host connectivity and propose new 248 DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate 249 configuration information to the hosts. 251 3.2. NAT64-FE Consideration 253 Some Internet Content Providers (ICPs) may locate NAT64 in front of 254 an Internet Data Center (IDC), for example co-located with load 255 balancing function. Load balancers are employed to connect different 256 IP family domains, meanwhile distribute workloads across multiple 257 domains or internal servers actually. In some cases, IPv4 addresses 258 exhaustion may not be a problem in some IDC's networks. IPv6 support 259 for some applications may require some investments and workloads so 260 IPv6 support may not be a priority. The use of NAT64 may be served 261 to support widespread IPv6 adoption on the Internet while maintaining 262 IPv4-only applications access. 264 Different strategy has been described in [RFC6883]referred to as 265 "inside out" and "outside in". An IDC operator may implement the 266 following practices in the NAT64-FE networking. 268 o Some ICPs who already have satisfactory operational experiences 269 would adopt single stack IPv6 operations to build up their data 270 center network, servers and applications since it allows new 271 services delivery without having to integrate consideration of 272 IPv4 NAT and address limitations of IPv4 networks. Stateless 273 NAT64[RFC6145]is used to provide services for IPv4-only 274 subscribers. [I-D.anderson-siit-dc]has provided further 275 descriptions and guidelines. 277 o ICPs who attempt to offer customers IPv6 support in their 278 application farms at an early stage may likely run some proxies, 279 which are configured to handle incoming IPv6 flows and proxy them 280 to IPv4 back-end systems. Many load balancers have already 281 integrated some proxy functionality. IPv4 addresses configured in 282 the proxy can be multiplexed like a stateful NAT64 performs. A 283 similar challenge exists once increasingly numerous users in IPv6 284 Internet access an IPv4 network. High loads on load-balancers may 285 be apt to cause additional latency, IPv4 pool exhaustion, etc. 286 Therefore, this approach is only reasonable at an early stage. 287 ICPs may learn from the experiences and move on to dual-stack or 288 IPv6 single stack in a further stage, since the native IPv6 is 289 always more desirable than transition solutions. 291 [RFC6144] recommends that AAAA records of load-balancers or 292 application servers can be directly registered in the authoritative 293 DNS servers requiring to populate these servers with corresponding 294 AAAA records. In this case, there is no need to deploy DNS64 295 servers. Those AAAA records can be some native IPv6 addresses or 296 some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 297 address does not give the possibility to nodes to get any information 298 about NAT64 presence on communication path and the possibility to 299 prefer IPv4 path or the IPv6 path in dual-stack networks. For the 300 testing purpose, operators could use an independent sub domain e.g. 301 ipv6exp.xxx.xxx to identify experimental ipv6 services to users. How 302 to design the FQDN for the IPv6 service is out-of-scope of this 303 document. 305 4. High Availability 307 4.1. Redundancy Design 309 High Availability (HA) is a major requirement for every service and 310 network services. The deployment of redundancy mechanism is an 311 essential approach to avoid single-point failure and significantly 312 increase the network reliability. It's not only useful to stateful 313 NAT64 cases, but also to stateless NAT64 gateways. 315 Three redundancy modes are mainly used hereafter: cold standby, warm 316 standby and hot standby. 318 o Cold standby can't replicate the NAT64 states from the primary 319 equipment to the backup. Administrators switch on the backup 320 NAT64 only if the primary NAT64 fails. As the results, all the 321 existing established sessions will be disconnected. The internal 322 hosts are required to re-establish sessions to the external hosts. 323 Since the backup NAT64 is manually configured to switch over to 324 active NAT64, it may have unpredictable impacts to the ongoing 325 services. Normally, the handover would take several minutes so as 326 to wait for the whole process of NAT64 bootstrap loader. 328 o Warm standby is a flavor of the cold standby mode. Backup NAT64 329 would keep running once the primary NAT64 is working. This makes 330 warm standby less time consuming during the traffic failover. 331 Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a 332 solution to enable automatic handover in the warm standby. It was 333 tested that the handover takes as maximum as 1 minute if the 334 backup NAT64 needs to take over routing and re-construct the 335 Binding Information Bases (BIBs) for 30 million sessions. In 336 deployment phase, operators could balance loads on distinct NAT64s 337 devices. Those NAT64s make a warm backup of each other. 339 o Hot standby must synchronize the BIBs between the primary NAT64 340 and backup. When the primary NAT64 fails, backup NAT64 would take 341 over and maintain the state of all existing sessions. The 342 internal hosts don't have to re-connect the external hosts. The 343 handover time has been extremely reduced. Thanks to Bidirectional 344 Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay 345 of only 35ms for 30 million sessions handover was observed during 346 testing. In some sense, it could guarantee the session continuity 347 for every service. In order to timely transmit session states, 348 operators may have to deploy extra transport links between primary 349 NAT64 and distant backup. The scale of synchronization data 350 instance is depending on the particular deployment. For example, 351 If a NAT64-CGN is served for 200,000 users, the average amount of 352 800, 000 sessions per second is roughly estimated for new created 353 and expired sessions. A physical 10Gbps transport link may have 354 to be deployed for the sync data transmission considering the 355 amount of sync sessions at the peak and capacity redundancy 357 In general, cold-standby and warm-standby is simpler and less 358 resource intensive, but it requires clients to re-establish sessions 359 when a fail-over occurs. Hot standby increases resource's 360 consumption to synchronize the states, but it achieve seamless 361 handover. The consideration of redundancy mode for stateless NAT64 362 is simple, because state synchronization is unnecessary. In regards 363 to stateful NAT64, it may be useful to investigate performance 364 tolerance of applications and the traffic characteristics in a 365 particular network. Some testing results are shown in the 366 Appendix A. 368 Our statistics in a mobile network shown that almost 91.21% of amount 369 of traffic is accounted by browsing services. Those services don't 370 require session continuity. The handover time of warm standby is 371 qualified to the delay tolerance. Hot-standby does not offer much 372 benefit for those sessions on this point. In a fixed network, HTTP 373 streaming, p2p and online games would be the major 374 traffic[Cisco-VNI]. Consideration should be given to the importance 375 of maintaining bindings for those sessions across failover. 376 Operators may also consider the Average Revenue Per User (ARPU) 377 factors to deploy suitable redundancy mode. Warm standby may still 378 be adopted to cover most services while hot standby could be used to 379 upgrade Quality of Experience (QoE) using DNS64 with different 380 synthetic responses for limited traffic. Further considerations are 381 discussed at Section 6. 383 4.2. Load Balancing 385 Load balancing is used to accompany redundancy design so that better 386 scalability and resiliency could be achieved. Stateless NAT64s allow 387 asymmetric routing while anycast-based solutions are recommended in 388 [I-D.ietf-softwire-map-deployment]. The deployment of load balancing 389 may make more sense to stateful NAT64s for the sake of single-point 390 failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct 391 facilities, the following lists the considerations for each case. 393 o NAT64-CGN equipment doesn't implement load balancer functions on a 394 board card. Therefore, the gateways have to resort to DNS64 or 395 internal host's behavior. Once DNS64 is deployed, the load 396 balancing can be performed by synthesizing AAAA response with 397 different IPv6 prefixes. For the applications not requiring DNS 398 resolver, internal hosts could learn multiple IPv6 prefixes 399 through the approaches defined in[RFC7050] and then select one 400 based on a given prefix selection policy. 402 o A dedicated Load Balancer could be deployed at front of a NAT64-FE 403 farm. Load Balancer uses proxy mode to redirect the flows to the 404 appropriate NAT64 instance. Stateful NAT64s require a 405 deterministic pattern to arrange the traffic in order to ensure 406 outbound/inbound flows traverse the identical NAT64. Therefore, 407 static scheduling algorithms, for example source-address based 408 policy, is preferred. A dynamic algorithm, for example Round- 409 Robin, may have impacts on applications seeking session 410 continuity, which described in the Table 1. 412 5. Source Address Transparency 414 5.1. Traceability 416 Traceability is required in many cases such as identifying malicious 417 attacks sources and accounting requirements. Operators are asked to 418 record the NAT64 log information for specific periods of time. In 419 our lab testing, the log information from 200,000 subscribers have 420 been collected from a stateful NAT64 gateway for 60 days. 421 Syslog[RFC5424] has been adopted to transmit log message from NAT64 422 to a log station. Each log message contains transport protocol, 423 source IPv6 address:port, translated IPv4 address: port and 424 timestamp. It takes almost 125 bytes long in ASCII format. It has 425 been verified that the volume of recorded information reach up to 426 42.5 terabytes in the raw format and 29.07 terabytes in a compact 427 format. Operators have to build up dedicated transport links, 428 storage system and servers for the purpose. 430 There are also several implementations to mitigate the issue. For 431 example, stateful NAT64 could configure with bulk port allocation 432 method. Once a subscriber creates the first session, a number of 433 ports are pre-allocated. A bulk allocation message is logged 434 indicating this allocation. Subsequent session creations will use 435 one of the pre-allocated port and hence does not require logging. 436 The log volume in this case may be only one thousandth of dynamic 437 port allocation. Some implementations may adopt static port-range 438 allocations [I-D.donley-behave-deterministic-cgn] which eliminates 439 the need for per-subscriber logging. As a side effect, the IPv4 440 multiplexing efficiency is decreased regarding to those methods. For 441 example, the utilization ratio of public IPv4 address is dropped 442 approximately to 75% when NAT64 gateway is configured with bulk port 443 allocation (The lab testing allocates each subscriber with 400 444 ports). In addition, port-range based allocation should also 445 consider port randomization described in [RFC6056] . A trade-off 446 among address multiplexing efficiency, logging storage compression 447 and port allocation complexity should be considered. More 448 discussions could be found in 449 [I-D.chen-sunset4-cgn-port-allocation].Basically, the decision 450 depends on usable IPv4 resource and investments of log systems. 452 5.2. Geo-location 454 IP addresses are usually used as inputs to geo-location services. 455 The use of address sharing will prevent these systems from resolving 456 the location of a host based on IP address alone. Applications that 457 assume such geographic information may not work as intended. The 458 possible solutions listed in [RFC6967] are intended to bridge the 459 gap. However, those solutions can only provide a sub-optimal 460 substitution to solve the problem of host identification, in 461 particular it may not today solve problems with source identification 462 through translation. The following lists current practices to 463 mitigate the issue. 465 o Operators who adopt NAT64-FE may leverage the application layer 466 proxies, e.g. X-Forwarded-For (XFF) 467 [I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source 468 address in HTTP headers. Those messages would be passed on to 469 web-servers. The log parsing tools are required to be able to 470 support IPv6 and may lookup Radius servers for the target 471 subscribers based on IPv6 addresses included in XFF HTTP headers. 472 XFF is the de facto standard which has been integrated in most 473 Load Balancers. Therefore, it may be superior to use in a NAT-FE 474 environment. In the downsides, XFF is specific to HTTP. It 475 restricts the usages so that the solution can't be applied to 476 requests made over HTTPs. This makes geo-location problematic for 477 HTTPs based services. 479 o The NAT64-CGN equipment may not implement XFF. Geo-location based 480 on shared IPv4 address is rather inaccurate in that case. 481 Operators could subdivide the outside IPv4 address pool so an IPv6 482 address can be translated depending on their geographical 483 locations. As consequence, location information can be identified 484 from a certain IPv4 address range. [RFC6967] also enumerates 485 several options to reveal the host identifier. Each solution 486 likely has their-own specific usage. For the geo-location systems 487 relying on a Radius database[RFC5580], we have investigated to 488 deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius 489 server[I-D.chen-behave-nat64-radius-extension]. This method could 490 provide geo-location system with an internal IPv6 address to 491 identify each user. It can get along with [RFC5580] to convey 492 original source address through same message bus. 494 6. Quality of Experience 496 6.1. Service Reachability 498 NAT64 is providing a translation capability between IPv6 and IPv4 499 end-nodes. In order to provide the reachability between two IP 500 address families, NAT64-CGN has to implement appropriate application 501 aware functions, i.e. Application Layer Gateway (ALG), where address 502 translation is not itself sufficient and security mechanisms do not 503 render it infeasible. Most NAT64-CGNs mainly provide FTP- 504 ALG[RFC6384]. NAT64-FEs may have functional richness on Load 505 Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have 506 been supported. Those application protocols exchange IP address and 507 port parameters within control session, for example the "Via" filed 508 in a HTTP header, "Transport" field in a RTSP SETUP message and 509 "Received: " header in a SMTP message. ALG functions will detect 510 those fields and make IP address translations. It should be noted 511 that ALGs may impact the performance on a NAT64 box to some extent. 512 ISPs as well as content providers might choose to avoid situations 513 where the imposition of an ALG might be required. At the same time, 514 it is also important to remind customers and application developers 515 that IPv6 end-to-end usage does not require ALG imposition and 516 therefore results in a better overall user experience. 518 The service reachability is also subject to the IPv6 support in the 519 client side. We tested several kinds of applications as shown in the 520 below table to verify the IPv6 supports. The experiences of some 521 applications are still align with [RFC6586]. It has been found there 522 are some software issues to support IPv6 at this time. The software 523 could benefit from 464xlat[RFC6877] to be able to get IPv4 524 connectivity across an IPv6-only network without requiring software 525 upgrades. A SIP based voice call has been tested in LTE mobile 526 environment as specified in [IR.92]. The voice call is failed due to 527 the lack of NAT64 traversal when an IPv6 SIP user agent communicates 528 with an IPv4 SIP user agent. In order to address the failure, 529 Interactive Connectivity Establishment (ICE) described in [RFC5245]is 530 recommended to be supported for the SIP IPv6 transition. [RFC6157] 531 describes both signaling and media layer process, which should be 532 followed. In addition, it may be worth to notice that ICE is not 533 only useful for NAT traversal, but also firewall[RFC6092] traversal 534 in native IPv6 deployment. 536 Different IPsec modes for VPN services have been tested, including 537 IPsec-AH and IPsec-ESP. It has been testified IPsec-AH can't survive 538 since the destination host detects the IP header changes and 539 invalidate the packets. IPsec-ESP failed in our testing because the 540 NAT64 does not translate IPsec ESP (i.e. protocol 50) packets. It 541 has been suggested that IPsec ESP should succeed if the IPSec client 542 supports NAT-Traversal in the IKE[RFC3947] and uses IPsec ESP over 543 UDP[RFC3948]. 545 Table 1: The tested applications 546 +----------------+----------------------------------------------------+ 547 | APPs | Results and Found Issues |. 548 +----------------+----------------------------------------------------+ 549 | Webservice |Mostly pass, some failure cases due to IPv4 Literals| 550 +----------------+----------------------------------------------------+ 551 |Instant Message |Mostly fail, software can't support IPv6 | 552 +----------------+----------------------------------------------------+ 553 | Games |Mostly pass for web-based games; mostly fail for | 554 | |standalone games due to the lack of IPv6 support in | 555 | |software | 556 +----------------+----------------------------------------------------+ 557 | SIP-VoIP |Fail, due to the lack of NAT64 traversal | 558 +----------------+----------------------------------------------------+ 559 | IPsec-VPN |Fail, the translated IPsec packets are invalidated | 560 +----------------+----------------------------------------------------+ 561 |P2P streaming, |Mostly fail, software can't support IPv6, e.g. eMule| 562 |file sharing |Thunder and PPS TV | 563 +----------------+----------------------------------------------------+ 564 | FTP |Pass | 565 +----------------+----------------------------------------------------+ 566 | Email |Pass | 567 +----------------+----------------------------------------------------+ 569 6.2. Resource Reservation 571 Session status normally is managed by a static timer. For example, 572 the value of the "established connection idle-timeout" for TCP 573 sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 574 minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe 575 significantly consumed by largely inactive users. The NAT translator 576 and other customers would suffer from service degradation due to port 577 consummation by other subscribers using the same NAT64 device. A 578 flexible NAT session control is desirable to resolve the issues. 579 PCP[RFC6887] could be a candidate to provide such capability. A 580 NAT64-CGN should integrate with a PCP server, to allocate available 581 IPv4 address/port resources. Resources could be assigned to PCP 582 clients through PCP MAP/PEER mode. Such ability can be considered to 583 upgrade user experiences, for example assigning different sizes of 584 port ranges for different subscribers. Those mechanisms are also 585 helpful to minimize terminal battery consumption and reduce the 586 number of keep-alive messages to be sent by mobile terminal devices. 588 Subscribers can also benefit from network reliability. It has been 589 discussed that hot-standby offers satisfactory experience once outage 590 of primary NAT64 is occurred. Operators may rightly be concerned 591 about the considerable investment required for NAT64 equipment 592 relative to low ARPU income. For example, transport links may cost 593 much, because primary NAT64 and backup are normally located at 594 different locations, separated by a relatively large distance. 595 Additional maintenance has to be spent to ensure the connectivity 596 quality. However, that may be necessary to some applications, which 597 are delay-sensitive and seek session continuity, for example on-line 598 games and live-streaming. Operators may be able to get added-values 599 from those services by offering first-class services. It can be pre- 600 configured on the gateway to hot-standby modes depending on 601 subscriber's profile. The rest of other sessions can be covered by 602 cold/warm standby. 604 7. MTU Considerations 606 IPv6 requires that every link in the internet have an Maximum 607 Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However, 608 in case of NAT64 translation deployment, some IPv4 MTU constrained 609 link will be used in some communication path and originating IPv6 610 nodes may therefore receive an ICMP Packet Too Big (PTB) message, 611 reporting a Next-Hop MTU less than 1280 bytes. The result would be 612 that IPv6 allows packets to contain a fragmentation header, without 613 the packet being fragmented into multiple pieces. A NAT64 would 614 receive IPv6 packets with fragmentation header in which "M" flag 615 equal to 0 and "Fragment Offset" equal to 0. Those packets likely 616 impact other fragments already queued with the same set of {IPv6 617 Source Address, IPv6 Destination Address, Fragment Identification}. 618 If the NAT64 box is compliant with [RFC5722], there is risk that all 619 the fragments have to be dropped. 621 [RFC6946] discusses how this situation could be exploited by an 622 attacker to perform fragmentation-based attacks, and also proposes an 623 improved handling of such packets. It required enhancements on NAT64 624 gateway implementations to isolate packet's processing. NAT64 should 625 follow the recommendation and take steps to prevent the risks of 626 fragmentation. 628 Another approach that potentially avoids this issue is to configure 629 IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB 630 smaller than 1280 bytes. Such an operational consideration is hard 631 to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. 632 However, it's a feasible approach in NAT64-FE cases, since a IPv4 633 network NAT64-FE connected is rather well-organized and operated by a 634 IDC operator or content provider. Therefore, the MTU of IPv4 network 635 in NAT64-FE case are strongly recommended to set to more than 1260 636 bytes. 638 8. ULA Usages 640 Unique Local Addresses (ULAs) are defined in [RFC4193] to be 641 renumbered within a network site for local communications. Operators 642 may use ULAs as NAT64 prefixes to provide site-local IPv6 643 connectivity. Those ULA prefixes are stripped when the packets going 644 to the IPv4 Internet, therefore ULAs are only valid in the IPv6 site. 645 The use of ULAs could help in identifying the translation 646 traffic.[I-D.ietf-v6ops-ula-usage-recommendations] provides further 647 guidance for the ULAs usages. 649 We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is 650 only assigned with an IPv6 address and connected to NAT64-CGN, when 651 connect to an IPv4 service, it would receive AAAA record generated by 652 the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will 653 be selected as the source address to the ULA destination address. 654 When the host has both IPv4 and IPv6 address, it would initiate both 655 A and AAAA record lookup, then both original A record and 656 DNS64-generated AAAA record would be received. A host, which is 657 compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 658 path will be always selected. It may be undesirable because the 659 NAT64-CGN will never be used. Operators may consider to add 660 additional site-specific rows into the default policy table for host 661 address selection in order to steer traffic flows going through 662 NAT64-CGN. However, it involves significant costs to change 663 terminal's behavior. Therefore, operators are not suggested to 664 configure ULAs on a NAT64-CGN. 666 ULAs can't work when hosts transit the Internet to connect with 667 NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE. 669 9. Security Considerations 671 his document presents the deployment experiences of NAT64 in CGN and 672 FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking, 673 address-dependent filtering mechanisms to protect NAT64 from 674 Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators 675 also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and 676 black/white-list to enhance the security by specifying access 677 policies. For example, NAT64-CGN should forbid establish NAT64 BIB 678 for incoming IPv6 packets if uRPF in Strict or Loose mode check does 679 not pass or whose source IPv6 address is associated to black-lists. 681 The stateful NAT64-FE creates state and maps that connection to an 682 internally-facing IPv4 address and port. An attacker can consume the 683 resources of the NAT64-FE device by sending an excessive number of 684 connection attempts. Without a DDoS limitation mechanism, the 685 NAT64-FE is exposed to attacks. Load Balancer is recommended to 686 enable the capabilities of line rate DDOS defense, such as the 687 employment of SYN PROXY-COOKIE. Security domain division is 688 necessary as well in this case. Therefore, Load Balancers could not 689 only serve for optimization of traffic distribution, but also prevent 690 service from quality deterioration due to security attacks. 692 10. IANA Considerations 694 This memo includes no request to IANA. 696 11. Acknowledgements 698 The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, 699 Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy 700 Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, 701 Tim Chown, Gert Doering and Simon Perreault for their helpful 702 comments. 704 Many thanks to Wesley George, Lee Howard and Satoru Matsushima for 705 their detailed reviews. 707 The authors especially thank Joel Jaeggli and Ray Hunter for his 708 efforts and contributions on editing which substantially improves the 709 legibility of the document. 711 Thanks to Cameron Byrne who was an active co-author of some earlier 712 versions of this draft. 714 12. Additional Author List 716 The following are extended authors who contributed to the effort: 718 Qiong Sun 719 China Telecom 720 Room 708, No.118, Xizhimennei Street 721 Beijing 100035 722 P.R.China 723 Phone: +86-10-58552936 724 Email: sunqiong@ctbri.com.cn 726 QiBo Niu 727 ZTE 728 50,RuanJian Road. 729 YuHua District, 730 Nan Jing 210012 731 P.R.China 732 Email: niu.qibo@zte.com.cn 734 13. References 736 13.1. Normative References 738 [I-D.ietf-appsawg-http-forwarded] 739 Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", 740 draft-ietf-appsawg-http-forwarded-10 (work in progress), 741 October 2012. 743 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 744 (IPv6) Specification", RFC 2460, December 1998. 746 [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed 747 Networks", BCP 84, RFC 3704, March 2004. 749 [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, 750 "Negotiation of NAT-Traversal in the IKE", RFC 3947, 751 January 2005. 753 [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. 754 Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC 755 3948, January 2005. 757 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 758 Addresses", RFC 4193, October 2005. 760 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation 761 (NAT) Behavioral Requirements for Unicast UDP", BCP 127, 762 RFC 4787, January 2007. 764 [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment 765 (ICE): A Protocol for Network Address Translator (NAT) 766 Traversal for Offer/Answer Protocols", RFC 5245, April 767 2010. 769 [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. 770 Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, 771 RFC 5382, October 2008. 773 [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. 775 [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. 776 Aboba, "Carrying Location Objects in RADIUS and Diameter", 777 RFC 5580, August 2009. 779 [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", 780 RFC 5722, December 2009. 782 [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) 783 Version 3 for IPv4 and IPv6", RFC 5798, March 2010. 785 [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection 786 (BFD)", RFC 5880, June 2010. 788 [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. 789 Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, 790 October 2010. 792 [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation 793 Algorithm", RFC 6145, April 2011. 795 [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful 796 NAT64: Network Address and Protocol Translation from IPv6 797 Clients to IPv4 Servers", RFC 6146, April 2011. 799 [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van 800 Beijnum, "DNS64: DNS Extensions for Network Address 801 Translation from IPv6 Clients to IPv4 Servers", RFC 6147, 802 April 2011. 804 [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 805 Transition in the Session Initiation Protocol (SIP)", RFC 806 6157, April 2011. 808 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) 809 for IPv6-to-IPv4 Translation", RFC 6384, October 2011. 811 [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with 812 Dual-Stack Hosts", RFC 6555, April 2012. 814 [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, 815 "Default Address Selection for Internet Protocol Version 6 816 (IPv6)", RFC 6724, September 2012. 818 [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. 819 Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 820 2013. 822 [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 823 6946, May 2013. 825 [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of 826 the IPv6 Prefix Used for IPv6 Address Synthesis", RFC 827 7050, November 2013. 829 13.2. Informative References 831 [Alexa] Alexa, "http://www.alexa.com/topsites", April 2013. 833 [Cisco-VNI] 834 Cisco, "Cisco Visual Networking Index: Forecast and 835 Methodology, 2012-2017, 836 http://ciscovni.com/forecast-widget/index.html", May 2013. 838 [I-D.anderson-siit-dc] 839 Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data 840 Centre Environments", draft-anderson-siit-dc-00 (work in 841 progress), November 2012. 843 [I-D.chen-behave-nat64-radius-extension] 844 Chen, G. and D. Binet, "Radius Attributes for Stateful 845 NAT64", draft-chen-behave-nat64-radius-extension-00 (work 846 in progress), July 2013. 848 [I-D.chen-sunset4-cgn-port-allocation] 849 Chen, G., "Analysis of NAT64 Port Allocation Method", 850 draft-chen-sunset4-cgn-port-allocation-02 (work in 851 progress), July 2013. 853 [I-D.donley-behave-deterministic-cgn] 854 Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., 855 and O. Vautrin, "Deterministic Address Mapping to Reduce 856 Logging in Carrier Grade NAT Deployments", draft-donley- 857 behave-deterministic-cgn-06 (work in progress), July 2013. 859 [I-D.ietf-softwire-map-deployment] 860 Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, 861 "Mapping of Address and Port (MAP) - Deployment 862 Considerations", draft-ietf-softwire-map-deployment-03 863 (work in progress), October 2013. 865 [I-D.ietf-softwire-map-t] 866 Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and 867 T. Murakami, "Mapping of Address and Port using 868 Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work 869 in progress), September 2013. 871 [I-D.ietf-softwire-stateless-4v6-motivation] 872 Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., 873 Borges, I., and G. Chen, "Motivations for Carrier-side 874 Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- 875 softwire-stateless-4v6-motivation-05 (work in progress), 876 November 2012. 878 [I-D.ietf-v6ops-ula-usage-recommendations] 879 Liu, B., Jiang, S., and C. Byrne, "Recommendations of 880 Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- 881 recommendations-01 (work in progress), October 2013. 883 [I-D.kaliwoda-sunset4-dual-ipv6-coexist] 884 Kaliwoda, A. and D. Binet, "Co-existence of both dual- 885 stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual- 886 ipv6-coexist-01 (work in progress), October 2012. 888 [I-D.wing-dhc-dns-reconfigure] 889 Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6 890 Dynamic Reconfiguration", draft-wing-dhc-dns- 891 reconfigure-02 (work in progress), September 2013. 893 [IR.92] Global System for Mobile Communications Association 894 (GSMA), , "IMS Profile for Voice and SMS Version 7.0", 895 March 2013. 897 [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider 898 Scenarios for IPv6 Deployment", RFC 6036, October 2010. 900 [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- 901 Protocol Port Randomization", BCP 156, RFC 6056, January 902 2011. 904 [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in 905 Customer Premises Equipment (CPE) for Providing 906 Residential IPv6 Internet Service", RFC 6092, January 907 2011. 909 [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 910 IPv4/IPv6 Translation", RFC 6144, April 2011. 912 [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. 913 Roberts, "Issues with IP Address Sharing", RFC 6269, June 914 2011. 916 [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the 917 IPv4 Address Shortage", RFC 6346, August 2011. 919 [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., 920 Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation 921 Partnership Project (3GPP) Evolved Packet System (EPS)", 922 RFC 6459, January 2012. 924 [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only 925 Network", RFC 6586, April 2012. 927 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: 928 Combination of Stateful and Stateless Translation", RFC 929 6877, April 2013. 931 [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet 932 Content Providers and Application Service Providers", RFC 933 6883, March 2013. 935 [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, 936 "Analysis of Potential Solutions for Revealing a Host 937 Identifier (HOST_ID) in Shared Address Deployments", RFC 938 6967, June 2013. 940 Appendix A. Testing Results of Application Behavior 942 We test several application behaviors in a lab environment to 943 evaluate the impact when a primary NAT64 is out of service. In this 944 testing, participants are asked to connect a IPv6-only WiFi network 945 using laptops, tablets or mobile phones. NAT64 is deployed as the 946 gateway to connect Internet service. The tested applications are 947 shown in the below table. Cold standby, warm standby and hot standby 948 are taken turn to be tested. The participants may experience service 949 interruption due to the NAT64 handover. Different interruption 950 intervals are tested to gauge application behaviors. The results are 951 illuminated as below. 953 Table 2: The acceptable delay of applications 954 +----------------+------------------------+-------------------------+ 955 | APPs | Acceptable Interrupt | Session Continuity | 956 | | Recovery | | 957 +----------------+------------------------+-------------------------+ 958 | Web Browse |As maximum as 6s | No | 959 +----------------+------------------------+-------------------------+ 960 |Http streaming |As maximum as 10s(cache)| Yes | 961 +----------------+------------------------+-------------------------+ 962 | Gaming | 200ms~400ms | Yes | 963 +----------------+------------------------+-------------------------+ 964 |P2P streaming, | 10~16s | Yes | 965 |file sharing | | | 966 +----------------+------------------------+-------------------------+ 967 |Instant Message |1 minute | Yes | 968 +----------------+------------------------+-------------------------+ 969 |Mail |30 seconds | No | 970 +----------------+------------------------+-------------------------+ 971 |Downloading |1 minutes | No | 972 +----------------+------------------------+-------------------------+ 974 Authors' Addresses 976 Gang Chen 977 China Mobile 978 53A,Xibianmennei Ave., 979 Xuanwu District, 980 Beijing 100053 981 China 983 Email: phdgang@gmail.com 985 Zhen Cao 986 China Mobile 987 53A,Xibianmennei Ave., 988 Xuanwu District, 989 Beijing 100053 990 China 992 Email: caozhen@chinamobile.com 993 Chongfeng Xie 994 China Telecom 995 Room 708 No.118, Xizhimenneidajie 996 Beijing 100035 997 P.R.China 999 Email: xiechf@ctbri.com.cn 1001 David Binet 1002 France Telecom-Orange 1003 Rennes 1004 35000 1005 France 1007 Email: david.binet@orange.com