Internet Engineering Task Force G. Chen Internet-Draft Z. Cao Intended status: Informational China Mobile Expires: January 10, 2014 C. Xie China Telecom D. Binet France Telecom-Orange July 09, 2013 NAT64 Operational Experiences draft-ietf-v6ops-nat64-experience-02 Abstract This document summarizes NAT64 function deployment scenarios and operational experience. Both NAT64-CGN (NAT64 Carrier Grade NATs) and NAT64-FE (NAT64 server Front End) are considered in this document. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. 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 January 10, 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 Chen, et al. Expires January 10, 2014 [Page 1] Internet-Draft NAT64 Experiences July 2013 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.1. NAT64-CGN Consideration . . . . . . . . . . . . . . . . . 4 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 5 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 6 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 6 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 8 5. Source Address Transparency . . . . . . . . . . . . . . . . . 9 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 5.2. Geo-location . . . . . . . . . . . . . . . . . . . . . . 10 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 11 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 12 8. Security Considerations . . . . . . . . . . . . . . . . . . . 13 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 13 11. Additional Author List . . . . . . . . . . . . . . . . . . . 14 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 14 12.1. Normative References . . . . . . . . . . . . . . . . . . 14 12.2. Informative References . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 18 1. Introduction Now that IANA's global IPv4 address pool has been exhausted, IPv6 is the only sustainable solution for numbering nodes on Internet. Network operators have to deploy IPv6-only networks in order to meet the needs of the expanding internet without available IPv4 addresses. As IPv6 deployment continues, IPv6 networks and hosts will need to coexist with IPv4 numbered resources. The Internet will include nodes that are dual-stack, nodes that remain IPv4-only, and nodes that can be deployed as IPv6-only nodes. Single stack IPv6 network deployment can simplify the network provisioning. Some justifications have been described in 464xlat [RFC6877]. As an example, IPv6-only connectivity confers some benefits to mobile operators. In such mobile context, it enables the use of a single IPv6 PDP(Packet Data Protocol) context or EPS (Evolved Packet System) bearer if Long Term Evolution (LTE) network Chen, et al. Expires January 10, 2014 [Page 2] Internet-Draft NAT64 Experiences July 2013 is considered, which eliminates significant network costs caused by doubling the number of PDP contexts in some cases and the need of IPv4 addresses to be assigned to customers. In broadband networks overall, it can allow for the scaling of edge-network growth decoupled from IPv4 numbering limitations. In a transition scenario, some existing networks are likely to be IPv4-only configured for quite a long time. Allowing for interconnection between IPv4-only nodes and IPv6-only nodes is a critical capability for service continuity. Widespread dual-stack deployments have not materialized at the anticipated rate over the last 10 years, one possible conclusion being that legacy networks will not make the jump quickly. A translation mechanism based on a NAT64[RFC6146] [RFC6145]function is likely to be a key element of the Internet for IPv6-IPv4 interoperability. [RFC6036] reported at least 30% of operators plan to run some kind of translator (presumably NAT64/DNS64). Advice on NAT64 deployment and operation is therefore of some importance. [RFC6586] documented the implications for IPv6 only networks. This document intends to be specific to NAT64 network planning. 2. Terminology 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 NAT64-CGN (Carrier Grade NATs) or NAT64-FE (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 (Carrier Grade NATs) 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 (server Front End) is generally a device with NAT64 functionalities 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. Chen, et al. Expires January 10, 2014 [Page 3] Internet-Draft NAT64 Experiences July 2013 3. NAT64 Networking Experiences 3.1. NAT64-CGN Consideration 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 NAT64[RFC6146] is more adapted to perform some maximal sharing of public IPv4 addresses. The usage of stateless NAT64 can be seen with better transparency features [I-D.ietf-softwire-stateless-4v6-motivation], while it has to be coordinated with A+P[RFC6346] processes as specified in [I-D.ietf-softwire-map-t]and [I-D.ietf-softwire-4rd] in order to cope with IPv4 shortage. 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. And, it 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. NAT64 would forwards all the traffic on IPv6 paths if dual-stack servers are targeted. In some sense, it encourages IPv6 transmission and restrains NAT uses compared to NAT44(if used), on which all traffic flows have to traverse. Therefore, NAT64 may serve double roles in some cases, i.e. a translator and IPv6 forwarder. Some failure cases may occur once NAT64 serves a IPv6 gateway but 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. To be reliable, it's recommended to enable NAT64 WAN links with dual-stack connections in the deployment. 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 AS (Autonomous System) border in fixed networks. And, it is likely to be deployed in an IP node beyond the GGSN (Gateway GPRS Support Node) or PDN-GW (Public Data Network- Gateway) in mobile networks or directly in the gateway itself in some situations. This allows consistent attribution and traceability Chen, et al. Expires January 10, 2014 [Page 4] Internet-Draft NAT64 Experiences July 2013 within the service provider network. It has been observed that the process of correlating log information is problematic from multiple- vendor's equipments due to inconsistent formats of log records. Placing NAT64 in a centralized location may reduce diversity of log format and simplify the network provisioning. Moreover, since NAT64 is only targeted at serving traffic flows from IPv6 to IPv4-only services, the user traffic volume should not be as high as in a NAT44 scenario, and therefore, the gateway's capacity in such location may not be as much of a concern or a hurdle to deployment. On the other hand, the placement in a centralized way would require more strict high availability (HA) design. It would also make geo-location based on IPv4 addresses rather inaccurate as it is currently the case for NAT44 CGN already deployed in ISP networks. More considerations or workarounds on HA and traceability could be found at Section4 and Section5 . NAT64 could likely co-exist with NAT44 in a dual-stack network mostly because IPv4 private addresses are allocated to customers. The coexistence has already appeared in mobile networks, in which dual stack mobile phones normally initiate some dual-stack PDN/PDP Type[RFC6459] to query both IPv4/IPv6 address and IPv4 allocated addresses are very often private ones. [RFC6724] always prioritizes IPv6 connections regardless of whether the end-to-end path is native 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. 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 Chen, et al. Expires January 10, 2014 [Page 5] Internet-Draft NAT64 Experiences July 2013 IPv6 support may not be a priority. The use of NAT64 may be served to support widespread IPv6 adoption on the Internet while maintaining IPv4-only applications access. Different strategy has been described in [RFC6883]referred to as "inside out" and "outside in". An IDC operator may implement the following practices in the NAT64-FE networking. o Some ICPs who already have satisfactory operational experiences would adopt single stack IPv6 operations to build up their data center network, servers and applications since it allows new services delivery without having to integrate consideration of IPv4 NAT and address limitations of IPv4 networks. Stateless NAT64[RFC6145]is used to provide services for IPv4-only subscribers. [I-D.anderson-siit-dc]has provided further descriptions and guidelines. o ICPs who attempt to offer customers IPv6 support in their application farms at an early stage may likely run some proxies, which are configured to handle incoming IPv6 flows and proxy them to IPv4 back-end systems. Many load balancers have already integrated some proxy functionalities. IPv4 addresses configured in the proxy can be multiplexed like a stateful NAT64 performs. A similar challenge exists once increasingly numerous users in IPv6 Internet access an IPv4 network. High loads on load-balancers may be apt to cause additional latency, IPv4 pool exhaustion, etc. Therefore, this approach is only reasonable at an early stage. ICPs may learn from the experiences and move on to dual-stack or IPv6 single stack in a further stage, since the native IPv6 is 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. 4. High Availability 4.1. Redundancy Design Chen, et al. Expires January 10, 2014 [Page 6] Internet-Draft NAT64 Experiences July 2013 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. Three redundancy modes are mainly used hereafter: cold standby, warm standby and hot standby. o Cold standby can't replicate the NAT64 states from the primary equipment to the backup. Administrators switch on the backup NAT64 only if the primary NAT64 fails. As the results, all the existing established sessions will be disconnected. The internal hosts are required to re-establish sessions to the external hosts. Since the backup NAT64 is manually configured to switch over to active NAT64, it may have unpredictable impacts to the ongoing services. Normally, the handover would take several minutes so as to wait for the whole process of NAT64 bootstrap loader. o Warm standby is a flavor of the cold standby mode. Backup NAT64 would keep running once the primary NAT64 is working. This makes warm standby less time consuming during the traffic failover. Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a solution to enable automatic handover in the warm standby. It was tested that the handover takes as maximum as 1 minute if the backup NAT64 needs to take over routing and re-construct the Binding Information Base (BIB) for 30 million sessions. In deployment phase, operators could balance loads on distinct NAT64s 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. 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 Chen, et al. Expires January 10, 2014 [Page 7] Internet-Draft NAT64 Experiences July 2013 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. The following table is trying to evaluate user experience from a lab testing. Table 1: 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 | +----------------+------------------------+-------------------------+ | P2P | 10~16s | Yes | +----------------+------------------------+-------------------------+ |Instant Message |1 minute | Yes | +----------------+------------------------+-------------------------+ |Mail |30 seconds | No | +----------------+------------------------+-------------------------+ |Downloading |1 minutes | No | +----------------+------------------------+-------------------------+ 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 failovers. Operators may also consider the Average Revenue Per User (ARPU) factors to deploy suitable redundancy mode. Warm standby may still be adopted to cover most services while hot standby could be used to upgrade Quality of Experience (QoE) using DNS64 with different synthetic responses for limited traffic. Further considerations are discussed at Section 6. 4.2. Load Balancing Load balancing is used to accompany redundancy design so that better scalability and resiliency could be achieved. Stateless NAT64s allow asymmetric routing while anycast-based solutions are recommended in [I-D.ietf-softwire-map-deployment]. The deployment of load balancing Chen, et al. Expires January 10, 2014 [Page 8] Internet-Draft NAT64 Experiences July 2013 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 equipments don'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. With the absence of DNS64, internal hosts could learn multiple IPv6 prefixes through the approaches defined in[I-D.ietf-behave-nat64-discovery-heuristic] 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 continuity, which described in the Table 1. 5. Source Address Transparency 5.1. Traceability Traceability is required in many cases such as identifying malicious attacks sources and accounting requirements. Operators are asked to 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 dynamically assign a port range to each subscriber or perform static port-range allocations as [I-D.donley-behave-deterministic-cgn] proposed. Those methods can change log granularity from per-session to per-customer. The recorded log volume can be reduced to 40.6 gigabytes accordingly. However, the IPv4 multiplexing efficiency is also decreased regarding to those methods. For example, the utilization ratio of public IPv4 Chen, et al. Expires January 10, 2014 [Page 9] Internet-Draft NAT64 Experiences July 2013 address is dropped approximately to 75% when sized 400 ports range allocated to each device according to our statistics. 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. XFF (X-Forwarded-For) [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 requests made over HTTPs. This makes geo-location problematic for HTTPs based services. Chen, et al. Expires January 10, 2014 [Page 10] Internet-Draft NAT64 Experiences July 2013 o The NAT64-CGN equipments may not implement XFF. Geo-location based on shared IPv4 address is rather inaccurate in that case. It's desirable to offer geo-location system more information, for example port number to retrieve the internal IPv6 address, which has meaning in global scale. We have investigated to deliver NAT64 BIBs and Session Table Entrys (STEs) to a Radius server[I-D.chen-behave-nat64-radius-extension], since current geo- location systems rely on a Radius database to inspect location information, for example the information provided in [RFC5580]. Those methods could convey original source address through same message bus. Another approach is to ask NAT64-CGN providing application aware gateway to insert IPv6 source addresses. However, that may introduce complexity and performance degradation. 6. Quality of Experience 6.1. Service Reachability NAT64 is providing a translation capability between IPv6 and IPv4 end-nodes. In order to provide the reachability between two IP address families, NAT64-CGN has to implement appropriate application aware functions, i.e. Application Layer Gateway(ALG), where address translation is not itself sufficient and security mechanisms do not render it infeasible. Most NAT64-CGNs mainly provide FTP- 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. 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. PCP[RFC6887] could be a candidate to provide such capability. A NAT64-CGN should integrate with a PCP server, to allocate available IPv4 address/port resources. Resources could be assigned to PCP Chen, et al. Expires January 10, 2014 [Page 11] Internet-Draft NAT64 Experiences July 2013 clients through PCP MAP/PEER mode. Such ability can be considered to upgrade user experiences, for example assigning different sizes of port ranges for different subscribers. Those mechanisms are also helpful to minimize terminal battery consumption and reduce the number of keep-alive messages to be sent by mobile terminal devices. Subscribers can also benefit from network reliability. It has been discussed that hot-standby offers satisfactory experience once outage of primary NAT64 is occurred. Operators may rightly be concerned about the considerable investment required for NAT64 equipment relative to low ARPU income. For example, transport links may cost much, because primary NAT64 and backup are normally located at different locations, separated by a relatively large distance. Additional maintenance has to be spent to ensure the connectivity quality. However, that may be necessary to some applications, which are delay-sensitive and seek session continuity, for example on-line games and live-streaming. Operators may be able to get added-values from those services by offering first-class services. It can be pre- configured on the gateway to hot-standby modes depending on subscriber's profile. The rest of other sessions can be covered by cold/warm standby. 7. MTU Considerations IPv6 requires that every link in the internet have an Maximum Transmission Unit (MTU) of 1280 octets or greater[RFC2460]. However, in case of NAT64 translation deployment, some IPv4 MTU constrained link will be used in some communication path and originating IPv6 nodes may therefore receive an ICMP Packet Too Big (PTB) message, reporting a Next-Hop MTU less than 1280 bytes. The result would be that IPv6 allows packets to contain a fragmentation header, without the packet being fragmented into multiple pieces. A NAT64 would receive IPv6 packets with fragmentation header in which "M" flag equal to 0 and "Fragment Offset" equal to 0. Those packets likely impact other fragments already queued with the same set of {IPv6 Source Address, IPv6 Destination Address, Fragment Identification}. If the NAT64 box is compliant with [RFC5722], there is risk that all the fragments have to be dropped. [RFC6946] discusses how this situation could be exploited by an attacker to perform fragmentation-based attacks, and also proposes an improved handling of such packets. It required enhancements on NAT64 gateway implementations to isolate packet's processing. NAT64 should follow the recommendation and take steps to prevent the risks of fragmentation. Another approach that potentially avoids this issue is to configure IPv4 MTU more than 1260 bytes. It would forbid the occurrence of PTB Chen, et al. Expires January 10, 2014 [Page 12] Internet-Draft NAT64 Experiences July 2013 smaller than 1280 bytes. Such an operational consideration is hard to universally apply to the legacy "IPv4 Internet" NAT64-CGN bridged. However, it's a feasible approach in NAT64-FE cases, since a IPv4 network NAT64-FE connected is rather well-organized and operated by a IDC operator or content provider. Therefore, the MTU of IPv4 network in NAT64-FE case are strongly recommended to set to more than 1260 bytes. 8. Security Considerations This 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 also could adopt unicast Reverse Path Forwarding (uRPF)[RFC3704] and black/white-list to enhance the security by specifying access policies. For example, NAT64-CGN should forbid establish NAT64 BIB for incoming IPv6 packets if uRPF in Strict or Loose mode check does not pass or whose source IPv6 address is associated to black-lists. The stateful NAT64-FE creates state and maps that connection to an internally-facing IPv4 address and port. An attacker can consume the resources of the NAT64-FE device by sending an excessive number of connection attempts. Without a DDoS limitation mechanism, the NAT64-FE is exposed to attacks. Load Balancer is recommended to enable the capabilities of line rate DDOS defense, such as the employment of SYN PROXY-COOKIE. Security domain division is necessary as well in this case. Therefore, Load Balancers could not only serve for optimization of traffic distribution, but also prevent service from quality deterioration due to security attacks. 9. IANA Considerations This memo includes no request to IANA. 10. Acknowledgements The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, Fred Baker, Hui Deng, Lee Howard, Iljitsch van Beijnum, Philip Matthews and Randy Bush for their helpful comments. Many thanks to Wesley George and Satoru Matsushima for their 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. Chen, et al. Expires January 10, 2014 [Page 13] Internet-Draft NAT64 Experiences July 2013 Thanks to Cameron Byrne who was an active co-author of some earlier versions of this draft. 11. Additional Author List The following are extended authors who contributed to the effort: Qiong Sun China Telecom Room 708, No.118, Xizhimennei Street Beijing 100035 P.R.China Phone: +86-10-58552936 Email: sunqiong@ctbri.com.cn QiBo Niu ZTE 50,RuanJian Road. YuHua District, Nan Jing 210012 P.R.China Email: niu.qibo@zte.com.cn 12. References 12.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. [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. Chen, et al. Expires January 10, 2014 [Page 14] Internet-Draft NAT64 Experiences July 2013 [RFC4787] Audet, F. and C. Jennings, "Network Address Translation (NAT) Behavioral Requirements for Unicast UDP", BCP 127, RFC 4787, January 2007. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, RFC 5382, October 2008. [RFC5424] Gerhards, R., "The Syslog Protocol", RFC 5424, March 2009. [RFC5580] Tschofenig, H., Adrangi, F., Jones, M., Lior, A., and B. Aboba, "Carrying Location Objects in RADIUS and Diameter", RFC 5580, August 2009. [RFC5722] Krishnan, S., "Handling of Overlapping IPv6 Fragments", RFC 5722, December 2009. [RFC5798] Nadas, S., "Virtual Router Redundancy Protocol (VRRP) Version 3 for IPv4 and IPv6", RFC 5798, March 2010. [RFC5880] Katz, D. and D. Ward, "Bidirectional Forwarding Detection (BFD)", RFC 5880, June 2010. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with Dual-Stack Hosts", RFC 6555, April 2012. [RFC6724] Thaler, D., Draves, R., Matsumoto, A., and T. Chown, "Default Address Selection for Internet Protocol Version 6 (IPv6)", RFC 6724, September 2012. Chen, et al. Expires January 10, 2014 [Page 15] Internet-Draft NAT64 Experiences July 2013 [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. 12.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] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data Centre Environments", draft-anderson-siit-dc-00 (work in progress), November 2012. [I-D.chen-behave-nat64-radius-extension] Chen, G. and D. Binet, "Radius Attributes for Stateful NAT64", draft-chen-behave-nat64-radius-extension-00 (work in progress), July 2013. [I-D.chen-sunset4-cgn-port-allocation] Chen, G., "Analysis of NAT64 Port Allocation Method", draft-chen-sunset4-cgn-port-allocation-01 (work in progress), February 2013. [I-D.donley-behave-deterministic-cgn] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., and O. Vautrin, "Deterministic Address Mapping to Reduce Logging in Carrier Grade NAT Deployments", draft-donley- behave-deterministic-cgn-05 (work in progress), January 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-05 (work in progress), April 2013. [I-D.ietf-softwire-map-deployment] Chen, et al. Expires January 10, 2014 [Page 16] Internet-Draft NAT64 Experiences July 2013 Sun, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, "Mapping of Address and Port (MAP) - Deployment Considerations", draft-ietf-softwire-map-deployment-01 (work in progress), February 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-02 (work in progress), July 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.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. [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. [RFC6269] Ford, M., Boucadair, M., Durand, A., Levis, P., and P. Roberts, "Issues with IP Address Sharing", RFC 6269, June 2011. [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the IPv4 Address Shortage", RFC 6346, August 2011. [RFC6459] Korhonen, J., Soininen, J., Patil, B., Savolainen, T., Bajko, G., and K. Iisakkila, "IPv6 in 3rd Generation Partnership Project (3GPP) Evolved Packet System (EPS)", RFC 6459, January 2012. [RFC6586] Arkko, J. and A. Keranen, "Experiences from an IPv6-Only Network", RFC 6586, April 2012. Chen, et al. Expires January 10, 2014 [Page 17] Internet-Draft NAT64 Experiences July 2013 [RFC6877] Mawatari, M., Kawashima, M., and C. Byrne, "464XLAT: Combination of Stateful and Stateless Translation", RFC 6877, April 2013. [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. Authors' Addresses Gang Chen China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: phdgang@gmail.com Zhen Cao China Mobile 53A,Xibianmennei Ave., Xuanwu District, Beijing 100053 China Email: caozhen@chinamobile.com Chongfeng Xie China Telecom Room 708 No.118, Xizhimenneidajie Beijing 100035 P.R.China Email: xiechf@ctbri.com.cn Chen, et al. Expires January 10, 2014 [Page 18] Internet-Draft NAT64 Experiences July 2013 David Binet France Telecom-Orange Rennes 35000 France Email: david.binet@orange.com Chen, et al. Expires January 10, 2014 [Page 19]