--- 1/draft-ietf-v6ops-nat64-experience-04.txt 2013-12-09 14:46:51.347773871 -0800 +++ 2/draft-ietf-v6ops-nat64-experience-05.txt 2013-12-09 14:46:51.395775230 -0800 @@ -1,22 +1,22 @@ Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile -Expires: April 17, 2014 C. Xie +Expires: June 12, 2014 C. Xie China Telecom D. Binet France Telecom-Orange - October 14, 2013 + December 9, 2013 - NAT64 Operational Experiences - draft-ietf-v6ops-nat64-experience-04 + NAT64 Operational Experience + draft-ietf-v6ops-nat64-experience-05 Abstract This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64 Carrier Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) are considered in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the @@ -25,68 +25,68 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on April 17, 2014. + This Internet-Draft will expire on June 12, 2014. Copyright Notice Copyright (c) 2013 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 - 3. NAT64 Networking Experiences . . . . . . . . . . . . . . . . 4 + 3. NAT64 Networking Experience . . . . . . . . . . . . . . . . . 4 3.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 3.1.1. NAT64-CGN Usages . . . . . . . . . . . . . . . . . . 4 3.1.2. DNS64 Deployment . . . . . . . . . . . . . . . . . . 4 - 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 4 + 3.1.3. NAT64 Placement . . . . . . . . . . . . . . . . . . . 5 3.1.4. Co-existence of NAT64 and NAT44 . . . . . . . . . . . 5 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 - 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8 + 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 - 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 10 + 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 - 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 - 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 - 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 12 - 9. Security Considerations . . . . . . . . . . . . . . . . . . . 13 - 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 - 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 14 - 12. Additional Author List . . . . . . . . . . . . . . . . . . . 14 - 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 - 13.1. Normative References . . . . . . . . . . . . . . . . . . 15 - 13.2. Informative References . . . . . . . . . . . . . . . . . 16 - Appendix A. Testing Results of Application Behavior . . . . . . 18 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 19 + 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 12 + 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 13 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 14 + 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 + 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 + 12. Additional Author List . . . . . . . . . . . . . . . . . . . 15 + 13. References . . . . . . . . . . . . . . . . . . . . . . . . . 15 + 13.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 13.2. Informative References . . . . . . . . . . . . . . . . . 17 + Appendix A. Testing Results of Application Behavior . . . . . . 19 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 20 1. Introduction IPv6 is the only sustainable solution for numbering nodes on Internet due to the IPv4 depletion. Network operators have to deploy IPv6-only networks in order to meet the needs of the expanding internet without available IPv4 addresses. Single stack IPv6 network deployment can simplify network's provisioning. Some justifications have been described in 464xlat @@ -121,35 +121,36 @@ In regards to IPv4/IPv6 translation, [RFC6144] has described a framework of enabling networks to make interworking possible between IPv4 and IPv6 networks. This document has further categorized different NAT64 function locations and use cases. The principle distinction of location is if the NAT64 is located in a Carrier Grade NAT or server Front End. The terms of NAT-CGN/FE are understood to be a topological distinction indicating different features employed in a NAT64 deployment. - NAT64-CGN: A NAT64-CGN is placed in an ISP network. IPv6 - subscribers leverage the NAT64-CGN to access existing IPv4 - internet services. The ISP as an administrative entity takes full - control on the IPv6 side, but has limited or no control on the - IPv4 side. NAT64-CGN may have to consider the IPv4 Internet - environment and services to make appropriate configurations. + NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP + network. IPv6 subscribers leverage the NAT64-CGN to access + existing IPv4 internet services. The ISP as an administrative + entity takes full control on the IPv6 side, but has limited or no + control on the IPv4 side. NAT64-CGN may have to consider the IPv4 + Internet environment and services to make appropriate + configurations. - NAT64-FE: A NAT64-FE is generally a device with NAT64 functionality - in a content provider or data center network. It could be for - example a traffic load balancer or a firewall. The operator of - the NAT64-FE has full control over the IPv4 network within the - data center, but only limited influence or control over the - external IPv6 network. + NAT64 server Front End (NAT64-FE): A NAT64-FE is generally a device + with NAT64 functionality in a content provider or data center + network. It could be for example a traffic load balancer or a + firewall. The operator of the NAT64-FE has full control over the + IPv4 network within the data center, but only limited influence or + control over the external IPv6 network. -3. NAT64 Networking Experiences +3. NAT64 Networking Experience 3.1. NAT64-CGN Consideration 3.1.1. NAT64-CGN Usages Fixed network operators and mobile operators may locate NAT64 in access networks or in mobile core networks. It can be built into various devices, including routers, gateways or firewalls in order to connect IPv6 users to the IPv4 Internet. With regard to the numbers of users and the shortage of public IPv4 addresses, stateful @@ -161,40 +162,43 @@ [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope with IPv4 shortage. 3.1.2. DNS64 Deployment DNS64[RFC6147] is recommended for use in combination with stateful NAT64, and will likely be an essential part of an IPv6 single-stack network that couples to the IPv4 Internet. 464xlat[RFC6877] is proposed to enable access of IPv4 only applications or applications that call IPv4 literal addresses. Using DNS64 will help 464xlat to - automatically discover NAT64 prefix through - [I-D.ietf-behave-nat64-discovery-heuristic]. Berkeley Internet Name - Daemon (BIND) software supports the function. It's important to note - that DNS64 generates the synthetic AAAA reply when services only - register A records. Operators should not expect to access IPv4 parts - of a dual-stack server using NAT64/DNS64. The traffic is forwarded - on IPv6 paths if dual-stack servers are targeted. IPv6 traffic may - be routed not going through NAT64. Only the traffic going to - IPv4-only service would traverse NAT64. In some sense, it encourages - IPv6 transmission and restrains NAT uses compared to NAT44(if used), - on which all traffic flows have to be traversed and translated. In - some cases, NAT64-CGN may serve double roles, i.e. a translator and - IPv6 forwarder. Some failure cases may be occurred once NAT64 serves - a IPv6 gateway while is configured only with IPv4 on WAN links. We - tested on Top100 websites (referring to [Alexa] statistics) in such - condition. 43% of websites are failed to be connected since those - websites have both AAAA and A records. Therefore, it's recommended - to enable NAT64 WAN links with dual-stack connections in such case. + automatically discover NAT64 prefix through [RFC7050]. Berkeley + Internet Name Daemon (BIND) software supports the function. It's + important to note that DNS64 generates the synthetic AAAA reply when + services only register A records. Operators should not expect to + access IPv4 parts of a dual-stack server using NAT64/DNS64. The + traffic is forwarded on IPv6 paths if dual-stack servers are + targeted. IPv6 traffic may be routed not going through NAT64. Only + the traffic going to IPv4-only service would traverse NAT64. In some + sense, it encourages IPv6 transmission and restrains NAT uses + compared to NAT44(if used), on which all traffic flows have to be + traversed and translated. In some cases, NAT64-CGN may serve double + roles, i.e. a translator and IPv6 forwarder. In mobile networks, + NAT64 is likely deployed as the default gateway serving for all the + IPv6 traffic. The traffic heading to a dual-stack server is only + forwarded on the NAT64. Therefore, both IPv6 and IPv4 are suggested + to be configured on the Internet faced interfaces of NAT64. We + tested on Top100 websites (referring to [Alexa] statistics). 43% of + websites are connected and forwarded on the NAT64 since those + websites have both AAAA and A records. With expansion of IPv6 + supports, the translation process on NAT64 will likely be faded. 3.1.3. NAT64 Placement + All connections to IPv4 services from IPv6-only clients must traverse the NAT64-CGN. It can be advantageous from the vantage-point of troubleshooting and traffic engineering to carry the IPv6 traffic natively for as long as possible within an access network and translate packets only at or near the network egress. NAT64 can be considered as a feature of the Autonomous System (AS) border in fixed networks. And, it is likely to be deployed in an IP node beyond the Gateway GPRS Support Node (GGSN) or Public Data Network- Gateway (PDN-GW) in mobile networks or directly in the gateway itself in some situations. This allows consistent attribution and traceability @@ -226,25 +230,31 @@ IPv6 or IPv6 translated to IPv4 via NAT64/DNS64. Conversely, Happy Eyeballs[RFC6555] will direct some IP flows across IPv4 paths. The selection of IPv4/IPv6 paths may depend on particular implementation choices or settings on a host-by-host basis, and may differ from an operator's deterministic scheme. Our tests verified that hosts may find themselves switching between IPv4 and IPv6 paths as they access identical service, but at different times [I-D.kaliwoda-sunset4-dual-ipv6-coexist]. Since the topology on each path is different, it may cause unstable user experiences and some degradation of Quality of Experience (QoE) when fallback to the other - protocol is not powerful enough for example. It's also difficult for - operators to debug the issue and make optimal resource usages on both - NAT44 and NAT64. It's desirable to find the solutions that will - allow introducing IPv6/IPv4 translation service to IPv6-only hosts - while keeping dual-stack hosts unaffected and IPv4 service unchanged. + protocol is not powerful enough. It's also difficult for operators + to find a solution to make a stable network with optimal resource + utilization. In general, it's desirable to figure out the solution + that will introduce IPv6/IPv4 translation service to IPv6-only hosts + connecting to IPv4 servers while making sure dual-stack hosts to have + at least one address family accessible via native service if it's + possible. With the end-to-end native IPv6 environment is available, + hosts should be upgraded aggressively to migrate to IPv6-only. There + is an ongoing effort to detect host connectivity and propose new + DHCPv6 option[I-D.wing-dhc-dns-reconfigure] to convey appropriate + configuration information to the hosts. 3.2. NAT64-FE Consideration Some Internet Content Providers (ICPs) may locate NAT64 in front of an Internet Data Center (IDC), for example co-located with load balancing function. Load balancers are employed to connect different IP family domains, meanwhile distribute workloads across multiple domains or internal servers actually. In some cases, IPv4 addresses exhaustion may not be a problem in some IDC's networks. IPv6 support for some applications may require some investments and workloads so @@ -280,24 +290,25 @@ always more desirable than transition solutions. [RFC6144] recommends that AAAA records of load-balancers or application servers can be directly registered in the authoritative DNS servers requiring to populate these servers with corresponding AAAA records. In this case, there is no need to deploy DNS64 servers. Those AAAA records can be some native IPv6 addresses or some IPv4-converted IPv6 addresses[RFC6052]. The type of IPv6 address does not give the possibility to nodes to get any information about NAT64 presence on communication path and the possibility to - prefer IPv4 path or the IPv6 path in dual-stack networks. Using an - independent sub domain e.g. ipv6exp.xxx.xxx may help to identify - experimental ipv6 services to users. How to design the FQDN for the - IPv6 service is out-of-scope of this document. + prefer IPv4 path or the IPv6 path in dual-stack networks. For the + testing purpose, operators could use an independent sub domain e.g. + ipv6exp.xxx.xxx to identify experimental ipv6 services to users. How + to design the FQDN for the IPv6 service is out-of-scope of this + document. 4. High Availability 4.1. Redundancy Design High Availability (HA) is a major requirement for every service and network services. The deployment of redundancy mechanism is an essential approach to avoid single-point failure and significantly increase the network reliability. It's not only useful to stateful NAT64 cases, but also to stateless NAT64 gateways. @@ -327,34 +338,39 @@ devices. Those NAT64s make a warm backup of each other. o Hot standby must synchronize the BIBs between the primary NAT64 and backup. When the primary NAT64 fails, backup NAT64 would take over and maintain the state of all existing sessions. The internal hosts don't have to re-connect the external hosts. The handover time has been extremely reduced. Thanks to Bidirectional Forwarding Detection (BFD) [RFC5880] combining with VRRP, a delay of only 35ms for 30 million sessions handover was observed during testing. In some sense, it could guarantee the session continuity - for every service. In order to timely transmit states - information, operators may have to deploy extra transport links - between primary NAT64 and distant backup. + for every service. In order to timely transmit session states, + operators may have to deploy extra transport links between primary + NAT64 and distant backup. The scale of synchronization data + instance is depending on the particular deployment. For example, + If a NAT64-CGN is served for 200,000 users, the average amount of + 800, 000 sessions per second is roughly estimated for new created + and expired sessions. A 10Gbps transport link should be used for + the sync data transmission. In general, cold-standby and warm-standby is simpler and less resource intensive, but it requires clients to re-establish sessions when a fail-over occurs. Hot standby doubles resource's consumption to synchronize the states, but it achieve seamless handover. The consideration of redundancy mode for stateless NAT64 is simple, because it doesn't have to consider time consuming for states maintenance. The warm standby is sufficient for stateless NAT64. In - regards to stateful NAT64, it maybe useful to investigate performance - tolerance of applications and the traffic characteristics in a - particular network. Some testing results are shown in the + regards to stateful NAT64, it may be useful to investigate + performance tolerance of applications and the traffic characteristics + in a particular network. Some testing results are shown in the Appendix A. Our statistics in a mobile network shown that almost 91.21% of amount of traffic is accounted by browsing services. Those services don't require session continuity. The handover time of warm standby is qualified to the delay tolerance. Hot-standby does not offer much benefit for those sessions on this point. In a fixed network, HTTP streaming, p2p and online games would be the major traffic[Cisco-VNI]. Consideration should be given to the importance of maintaining bindings for those sessions across failover. @@ -374,22 +390,21 @@ may make more sense to stateful NAT64s for the sake of single-point failure avoidance. Since the NAT64-CGN and NAT64-FE have distinct facilities, the following lists the considerations for each case. o NAT64-CGN equipment doesn't implement load balancer functions on a board card. Therefore, the gateways have to resort to DNS64 or internal host's behavior. Once DNS64 is deployed, the load balancing can be performed by synthesizing AAAA response with different IPv6 prefixes. For the applications not requiring DNS resolver, internal hosts could learn multiple IPv6 prefixes - through the approaches defined - in[I-D.ietf-behave-nat64-discovery-heuristic] and then select one + through the approaches defined in[RFC7050] and then select one based on a given prefix selection policy. o A dedicated Load Balancer could be deployed at front of a NAT64-FE farm. Load Balancer uses proxy mode to redirect the flows to the appropriate NAT64 instance. Stateful NAT64s require a deterministic pattern to arrange the traffic in order to ensure outbound/inbound flows traverse the identical NAT64. Therefore, static scheduling algorithms, for example source-address based policy, is preferred. A dynamic algorithm, for example Round- Robin, may have impacts on applications seeking session @@ -404,65 +419,68 @@ record the NAT64 log information for specific periods of time. In our lab testing, the log information from 200,000 subscribers have been collected from a stateful NAT64 gateway for 60 days. Syslog[RFC5424] has been adopted to transmit log message from NAT64 to a log station. Each log message contains transport protocol, source IPv6 address:port, translated IPv4 address: port and timestamp. It takes almost 125 bytes long in ASCII format. It has been verified that the volume of recorded information reach up to 42.5 terabytes in the raw format and 29.07 terabytes in a compact format. Operators have to build up dedicated transport links, - storage system and servers for the purpose. There are also several - implementations to mitigate the issue. For example, stateful NAT64 - could configure with bulk port allocation method. Once a subscriber - creates the first session, a number of ports are pre-allocated. A - bulk allocation message is logged indicating this allocation. - Subsequent session creations will use one of the pre-allocated port - and hence does not require logging. The log volume in this case may - be only one thousandth of dynamic port allocation. Some - implementations may adopt static port-range allocations - [I-D.donley-behave-deterministic-cgn] which eliminates the need for - per-subscriber logging. As a side effect, the IPv4 multiplexing - efficiency is decreased regarding to those methods. For example, the - utilization ratio of public IPv4 address is dropped approximately to - 75% when NAT64 gateway is configured with bulk port allocation (The - lab testing allocates each subscriber with 400 ports). In addition, - port-range based allocation should also consider port randomization - described in [RFC6056] . A trade-off among address multiplexing - efficiency, logging storage compression and port allocation - complexity should be considered. More discussions could be found in + storage system and servers for the purpose. + + There are also several implementations to mitigate the issue. For + example, stateful NAT64 could configure with bulk port allocation + method. Once a subscriber creates the first session, a number of + ports are pre-allocated. A bulk allocation message is logged + indicating this allocation. Subsequent session creations will use + one of the pre-allocated port and hence does not require logging. + The log volume in this case may be only one thousandth of dynamic + port allocation. Some implementations may adopt static port-range + allocations [I-D.donley-behave-deterministic-cgn] which eliminates + the need for per-subscriber logging. As a side effect, the IPv4 + multiplexing efficiency is decreased regarding to those methods. For + example, the utilization ratio of public IPv4 address is dropped + approximately to 75% when NAT64 gateway is configured with bulk port + allocation (The lab testing allocates each subscriber with 400 + ports). In addition, port-range based allocation should also + consider port randomization described in [RFC6056] . A trade-off + among address multiplexing efficiency, logging storage compression + and port allocation complexity should be considered. More + discussions could be found in [I-D.chen-sunset4-cgn-port-allocation].Basically, the decision depends on usable IPv4 resource and investments of log systems. 5.2. Geo-location IP addresses are usually used as inputs to geo-location services. The use of address sharing will prevent these systems from resolving the location of a host based on IP address alone. Applications that assume such geographic information may not work as intended. The possible solutions listed in [RFC6967] are intended to bridge the gap. However, those solutions can only provide a sub-optimal substitution to solve the problem of host identification, in particular it may not today solve problems with source identification through translation. The following lists current practices to mitigate the issue. o Operators who adopt NAT64-FE may leverage the application layer proxies, e.g. X-Forwarded-For (XFF) [I-D.ietf-appsawg-http-forwarded], to convey the IPv6 source address in HTTP headers. Those messages would be passed on to - web-servers. The queried server can lookup Radius servers for the - target subscribers based on IPv6 addresses included in XFF HTTP - headers. XFF is the de facto standard which has been integrated - in most Load Balancers. Therefore, it may be superior to use in a - NAT-FE environment. In the downsides, XFF is specific to HTTP. - It restricts the usages so that the solution can't be applied to + web-servers. The log parsing tools are required to be able to + support IPv6 and may lookup Radius servers for the target + subscribers based on IPv6 addresses included in XFF HTTP headers. + XFF is the de facto standard which has been integrated in most + Load Balancers. Therefore, it may be superior to use in a NAT-FE + environment. In the downsides, XFF is specific to HTTP. It + restricts the usages so that the solution can't be applied to requests made over HTTPs. This makes geo-location problematic for HTTPs based services. o The NAT64-CGN equipment may not implement XFF. Geo-location based on shared IPv4 address is rather inaccurate in that case. Operators could subdivide the outside IPv4 address pool so an IPv6 address can be translated depending on their geographical locations. As consequence, location information can be identified from a certain IPv4 address range. [RFC6967] also enumerates several options to reveal the host identifier. Each solution @@ -486,20 +505,58 @@ ALG[RFC6384]. NAT64-FEs may have functional richness on Load Balancer, for example HTTP-ALG, HTTPs-ALG, RTSP-ALG and SMTP-ALG have been supported. It should be noted that ALGs may impact the performance on a NAT64 box to some extent. ISPs as well as content providers might choose to avoid situations where the imposition of an ALG might be required. At the same time, it is also important to remind customers and application developers that IPv6 end-to-end usage does not require ALG imposition and therefore results in a better overall user experience. + The service reachability is also subject to the IPv6 support in the + client side. We tested several kinds of applications as shown in the + below table to verify the IPv6 supports. + + Table 1: The tested applications + +----------------+----------------------------------------------------+ + | APPs | Results and Found Issues | + +----------------+----------------------------------------------------+ + | Webservices |Mostly pass, some failure cases due to IPv4 Literals| + +----------------+----------------------------------------------------+ + |Instance Message|Mostly fail, softwares don't support IPv6 | + +----------------+----------------------------------------------------+ + | Games |Mostly pass for web-based games and mostly fail for | + | |standalone games due to software supports | + +----------------+----------------------------------------------------+ + | P2P |Mostly fail, tracker is unable to support IPv6 peer | + | |or some software can't use IPv6 connections | + +----------------+----------------------------------------------------+ + | FTP | Pass | + +----------------+----------------------------------------------------+ + | Email | Pass | + +----------------+----------------------------------------------------+ + | VoIP | Fail, due to the lack of SIP-ALG support on NAT64 | + +----------------+----------------------------------------------------+ + | VPN | Fail, due to incapability of IPsec verification | + +----------------+----------------------------------------------------+ + + The experiences of some applications are still align with [RFC6586]. + In addition, we tested several P2P softwares including BitTorrent, + Thunder, PPS TV and eMule. Some failures happened because local + tracker servers don't setup with IPv6 extension patch or software + can't support IPv6. For VoIP services, we mainly tested Voice over + LTE services[IR.92], which is the major solution for voice in the + fourth generation communication ages. NAT64 is testified with some + issues of SIP-ALG supports. In regard to the widespread applications + of VoLTE in the near future, SIP-ALG is of great value to be + implemented on NAT64-CGN. + 6.2. Resource Reservation Session status normally is managed by a static timer. For example, the value of the "established connection idle-timeout" for TCP sessions must not be less than 2 hours 4 minutes[RFC5382] and 5 minutes for UDP sessions[RFC4787]. In some cases, NAT resource maybe significantly consumed by largely inactive users. The NAT translator and other customers would suffer from service degradation due to port consummation by other subscribers using the same NAT64 device. A flexible NAT session control is desirable to resolve the issues. @@ -576,24 +633,25 @@ only assigned with an IPv6 address and connected to NAT64-CGN, when connect to an IPv4 service, it would receive AAAA record generated by the DNS64 with the ULA prefix. A Global Unicast Address (GUA) will be selected as the source address to the ULA destination address. When the host has both IPv4 and IPv6 address, it would initiate both A and AAAA record lookup, then both original A record and DNS64-generated AAAA record would be received. A host, which is compliant with [RFC6724], will never prefer ULA over IPv4. An IPv4 path will be always selected. It may be undesirable because the NAT64-CGN will never be used. Operators may consider to add - additional site-specific rows to the default table to steer traffic - flows going through NAT64-CGN. However, it involves significant - costs to change terminal's behavior. Therefore, operators are not - suggested to configure ULAs on a NAT64-CGN. + additional site-specific rows into the default policy table for host + address selection in order to steer traffic flows going through + NAT64-CGN. However, it involves significant costs to change + terminal's behavior. Therefore, operators are not suggested to + configure ULAs on a NAT64-CGN. ULAs can't work when hosts transit the Internet to connect with NAT64. Therefore, ULAs are inapplicable to the case of NAT64-FE. 9. Security Considerations his document presents the deployment experiences of NAT64 in CGN and FE scenarios. In general, RFC 6146[RFC6146] provides TCP-tracking, address-dependent filtering mechanisms to protect NAT64 from Distributed Denial of Service (DDoS). In NAT64-CGN cases, operators @@ -614,26 +672,26 @@ only serve for optimization of traffic distribution, but also prevent service from quality deterioration due to security attacks. 10. IANA Considerations This memo includes no request to IANA. 11. Acknowledgements The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, - Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum, Philip - Matthews, Randy Bush, Mikael Abrahamsson, Lorenzo Colitti and Sheng - Jiang for their helpful comments. + Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy + Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, + Tim Chown and Gert Doering for their helpful comments. - Many thanks to Wesley George and Satoru Matsushima for their detailed - reviews. + Many thanks to Wesley George, Lee Howard and Satoru Matsushima for + their detailed reviews. The authors especially thank Joel Jaeggli and Ray Hunter for his efforts and contributions on editing which substantially improves the legibility of the document. Thanks to Cameron Byrne who was an active co-author of some earlier versions of this draft. 12. Additional Author List @@ -656,25 +714,24 @@ Email: niu.qibo@zte.com.cn 13. References 13.1. Normative References [I-D.ietf-appsawg-http-forwarded] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", draft-ietf-appsawg-http-forwarded-10 (work in progress), October 2012. - [I-D.ietf-behave-nat64-discovery-heuristic] - Savolainen, T., Korhonen, J., and D. Wing, "Discovery of - the IPv6 Prefix Used for IPv6 Address Synthesis", draft- - ietf-behave-nat64-discovery-heuristic-17 (work in - progress), April 2013. + [I-D.wing-dhc-dns-reconfigure] + Patil, P., Boucadair, M., Wing, D., and T. Reddy, "DHCPv6 + Dynamic Reconfiguration", draft-wing-dhc-dns- + reconfigure-02 (work in progress), September 2013. [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 2460, December 1998. [RFC3704] Baker, F. and P. Savola, "Ingress Filtering for Multihomed Networks", BCP 84, RFC 3704, March 2004. [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast Addresses", RFC 4193, October 2005. @@ -727,20 +784,24 @@ "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. [RFC6887] Wing, D., Cheshire, S., Boucadair, M., Penno, R., and P. Selkirk, "Port Control Protocol (PCP)", RFC 6887, April 2013. [RFC6946] Gont, F., "Processing of IPv6 "Atomic" Fragments", RFC 6946, May 2013. + [RFC7050] Savolainen, T., Korhonen, J., and D. Wing, "Discovery of + the IPv6 Prefix Used for IPv6 Address Synthesis", RFC + 7050, November 2013. + 13.2. Informative References [Alexa] Alexa, "http://www.alexa.com/topsites", April 2013. [Cisco-VNI] Cisco, "Cisco Visual Networking Index: Forecast and Methodology, 2012-2017, http://ciscovni.com/forecast-widget/index.html", May 2013. [I-D.anderson-siit-dc] @@ -764,50 +825,51 @@ Logging in Carrier Grade NAT Deployments", draft-donley- behave-deterministic-cgn-06 (work in progress), July 2013. [I-D.ietf-softwire-4rd] Despres, R., Jiang, S., Penno, R., Lee, Y., Chen, G., and M. Chen, "IPv4 Residual Deployment via IPv6 - a Stateless Solution (4rd)", draft-ietf-softwire-4rd-07 (work in progress), October 2013. [I-D.ietf-softwire-map-deployment] - Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, + Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, "Mapping of Address and Port (MAP) - Deployment - Considerations", draft-ietf-softwire-map-deployment-02 - (work in progress), July 2013. + Considerations", draft-ietf-softwire-map-deployment-03 + (work in progress), October 2013. [I-D.ietf-softwire-map-t] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and T. Murakami, "Mapping of Address and Port using Translation (MAP-T)", draft-ietf-softwire-map-t-04 (work in progress), September 2013. [I-D.ietf-softwire-stateless-4v6-motivation] Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., Borges, I., and G. Chen, "Motivations for Carrier-side Stateless IPv4 over IPv6 Migration Solutions", draft-ietf- softwire-stateless-4v6-motivation-05 (work in progress), November 2012. [I-D.ietf-v6ops-ula-usage-recommendations] Liu, B., Jiang, S., and C. Byrne, "Recommendations of Using Unique Local Addresses", draft-ietf-v6ops-ula-usage- - recommendations-00 (work in progress), May 2013. + recommendations-01 (work in progress), October 2013. [I-D.kaliwoda-sunset4-dual-ipv6-coexist] Kaliwoda, A. and D. Binet, "Co-existence of both dual- stack and IPv6-only hosts", draft-kaliwoda-sunset4-dual- ipv6-coexist-01 (work in progress), October 2012. - [RFC3484] Draves, R., "Default Address Selection for Internet - Protocol version 6 (IPv6)", RFC 3484, February 2003. + [IR.92] Global System for Mobile Communications Association + (GSMA), , "IMS Profile for Voice and SMS Version 7.0", + March 2013. [RFC6036] Carpenter, B. and S. Jiang, "Emerging Service Provider Scenarios for IPv6 Deployment", RFC 6036, October 2010. [RFC6056] Larsen, M. and F. Gont, "Recommendations for Transport- Protocol Port Randomization", BCP 156, RFC 6056, January 2011. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. @@ -834,33 +896,32 @@ [RFC6883] Carpenter, B. and S. Jiang, "IPv6 Guidance for Internet Content Providers and Application Service Providers", RFC 6883, March 2013. [RFC6967] Boucadair, M., Touch, J., Levis, P., and R. Penno, "Analysis of Potential Solutions for Revealing a Host Identifier (HOST_ID) in Shared Address Deployments", RFC 6967, June 2013. Appendix A. Testing Results of Application Behavior - We test several application behaviors in a lab environment to evaluate the impact when a primary NAT64 is out of service. In this testing, participants are asked to connect a IPv6-only WiFi network using laptops, tablets or mobile phones. NAT64 is deployed as the gateway to connect Internet service. The tested applications are shown in the below table. Cold standby, warm standby and hot standby - are taken truns to be tested. The partipants may experience service + are taken turn to be tested. The participants may experience service interruption due to the NAT64 handover. Different interruption intervals are tested to gauge application behaviors. The results are illuminated as below. - Table 1: The acceptable delay of applications + Table 2: The acceptable delay of applications +----------------+------------------------+-------------------------+ | APPs | Acceptable Interrupt | Session Continuity | | | Recovery | | +----------------+------------------------+-------------------------+ | Web Browse |As maximum as 6s | No | +----------------+------------------------+-------------------------+ |Http streaming |As maximum as 10s(cache)| Yes | +----------------+------------------------+-------------------------+ | Gaming | 200ms~400ms | Yes | +----------------+------------------------+-------------------------+