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