diff options
Diffstat (limited to 'doc/rfc/rfc7269.txt')
| -rw-r--r-- | doc/rfc/rfc7269.txt | 1235 |
1 files changed, 1235 insertions, 0 deletions
diff --git a/doc/rfc/rfc7269.txt b/doc/rfc/rfc7269.txt new file mode 100644 index 0000000..b6557e6 --- /dev/null +++ b/doc/rfc/rfc7269.txt @@ -0,0 +1,1235 @@ + + + + + + +Internet Engineering Task Force (IETF) G. Chen +Request for Comments: 7269 Z. Cao +Category: Informational China Mobile +ISSN: 2070-1721 C. Xie + China Telecom + D. Binet + France Telecom-Orange + June 2014 + + + NAT64 Deployment Options and Experience + +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 document is not an Internet Standards Track specification; it is + published for informational purposes. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Not all documents + approved by the IESG are a candidate for any level of Internet + Standard; see Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc7269. + +Copyright Notice + + Copyright (c) 2014 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. + + + +Chen, et al. Informational [Page 1] + +RFC 7269 NAT64 Experience June 2014 + + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2 + 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 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 . . . . . . . . . . . . . . . . . . . 5 + 3.1.4. Coexistence of NAT64 and NAT44 . . . . . . . . . . . 5 + 3.2. NAT64-FE Consideration . . . . . . . . . . . . . . . . . 6 + 4. High Availability . . . . . . . . . . . . . . . . . . . . . . 7 + 4.1. Redundancy Design . . . . . . . . . . . . . . . . . . . . 7 + 4.2. Load Balancing . . . . . . . . . . . . . . . . . . . . . 9 + 5. Source-Address Transparency . . . . . . . . . . . . . . . . . 9 + 5.1. Traceability . . . . . . . . . . . . . . . . . . . . . . 9 + 5.2. Geolocation . . . . . . . . . . . . . . . . . . . . . . . 10 + 6. Quality of Experience . . . . . . . . . . . . . . . . . . . . 11 + 6.1. Service Reachability . . . . . . . . . . . . . . . . . . 11 + 6.2. Resource Reservation . . . . . . . . . . . . . . . . . . 13 + 7. MTU Considerations . . . . . . . . . . . . . . . . . . . . . 13 + 8. ULA Usages . . . . . . . . . . . . . . . . . . . . . . . . . 14 + 9. Security Considerations . . . . . . . . . . . . . . . . . . . 15 + 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 15 + 11. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12. References . . . . . . . . . . . . . . . . . . . . . . . . . 16 + 12.1. Normative References . . . . . . . . . . . . . . . . . . 16 + 12.2. Informative References . . . . . . . . . . . . . . . . . 18 + Appendix A. Test Results for Application Behavior . . . . . . . 21 + +1. Introduction + + IPv6 is the only sustainable solution for numbering nodes on the + 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 + provisioning; some justification was provided in 464XLAT [RFC6877]. + IPv6-only connectivity confers some benefits to mobile operators as + an example. In the mobile context, IPv6-only usage enables the use + of a single IPv6 Packet Data Protocol (PDP) context or Evolved Packet + System (EPS) bearer on Long Term Evolution (LTE) networks. This + eliminates significant network costs (caused by employing two PDP + contexts in some cases) and the need for IPv4 addresses to be + assigned to customers. In broadband networks overall, it can allow + for the scaling of edge-network growth to be decoupled from IPv4 + numbering limitations. + + + +Chen, et al. Informational [Page 2] + +RFC 7269 NAT64 Experience June 2014 + + + In transition scenarios, some existing networks are likely to be IPv4 + only for quite a long time. IPv6 networks and IPv6-only hosts will + need to coexist with IPv4 numbered resources. 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. The Internet will include nodes that + are dual stack, nodes that remain IPv4 only, and nodes that can be + deployed as IPv6-only nodes. A translation mechanism based on a + NAT64 function [RFC6145] [RFC6146] is likely to be a key element of + Internet connectivity for IPv6-IPv4 interoperability. + + [RFC6036] reports at least 30% of operators plan to run some kind of + translator (presumably NAT64/DNS64). Advice on NAT64 deployment and + operations are therefore of some importance. [RFC6586] documents the + implications for IPv6-only networks. This document intends to be + specific to NAT64 network planning. + +2. Terminology + + Regarding IPv4/IPv6 translation, [RFC6144] has described a framework + for enabling networks to make interworking possible between IPv4 and + IPv6 networks. Two operation modes (i.e., stateful translation and + stateless translation) have been described in Section 3.2 of + [RFC6144]. This document describes the usage of those two operation + modes and has further categorized different NAT64 functions, + locations, and use cases. The principal distinction of location is + whether the NAT64 is located in a Carrier-Grade NAT or server Front + End. The terms "NAT-CGN" and "NAT-FE" are understood to be a + topological distinction indicating different features employed in a + NAT64 deployment. + + NAT64 Carrier Grade NAT (NAT64-CGN): A NAT64-CGN is placed in an ISP + network. IPv6-enabled subscribers leverage the NAT64-CGN to + access existing IPv4 Internet services. The ISP as an + administrative entity takes full control of the IPv6 side, but it + has limited or no control on the IPv4 Internet side. NAT64-CGN + deployments may have to consider the IPv4 Internet environment and + services, and make appropriate configuration choices accordingly. + + 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 Internet IPv6 network. + + + + + + +Chen, et al. Informational [Page 3] + +RFC 7269 NAT64 Experience June 2014 + + +3. NAT64 Networking Experience + +3.1. NAT64-CGN Consideration + +3.1.1. NAT64-CGN Usages + + Fixed network operators and mobile operators may locate NAT64 + translators in access networks or in mobile core networks. NAT64 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 suited to maximize + sharing of public IPv4 addresses. The usage of stateless NAT64 can + provide better transparency features [MOTIVATION], but it has to be + coordinated with Address plus Port (A+P) processes [RFC6346] as + specified in [MAP-T] in order to deal with an IPv4 address shortage. + +3.1.2. DNS64 Deployment + + DNS64 [RFC6147] is recommended for use in combination with stateful + NAT64, and it will likely be an essential part of an IPv6 single- + stack network that couples to the IPv4 Internet. 464XLAT [RFC6877] + can enable access of IPv4-only applications or applications that call + IPv4 literal addresses. Using DNS64 will help 464XLAT to + automatically discover NAT64 prefixes through [RFC7050]. Berkeley + Internet Name Daemon (BIND) software supports that function. It's + important to note that DNS64 generates the synthetic AAAA reply when + services only provide 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 around rather than going + through NAT64. Only the traffic going to IPv4-only services would + traverse the NAT64 translator. In some sense, it encourages IPv6 + usage and limits NAT translation compared to employing NAT44, where + all traffic flows have to be translated. In some cases, NAT64-CGNs + may serve double roles, i.e., as a translator and IPv6 forwarder. In + mobile networks, NAT64 may be deployed as the default gateway serving + 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-facing interfaces of + NAT64. We tested on the top 100 websites (referring to [Alexa] + statistics). 43% of websites are connected and forwarded on NAT64 + since those websites have both AAAA and A records. With expansion of + IPv6 support, the translation process on NAT64 will likely become + less important over time. It should be noted that the DNS64-DNSSEC + interaction [RFC6147] may impact validation of Resource Records + retrieved from the DNS64 process. In particular, DNSSEC validation + + + + +Chen, et al. Informational [Page 4] + +RFC 7269 NAT64 Experience June 2014 + + + will fail when DNS64 synthesizes AAAA records where there is a DNS + query received with the "DNSSEC OK" (DO) bit set and the "Checking + Disabled" (CD) bit set. + +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 viewpoint 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 may be a + feature of the Autonomous System (AS) border in fixed networks. It + may be deployed in an IP node beyond the Gateway GPRS Support Node + (GGSN) or Packet Data Network Gateway (PDN-GW) in mobile networks or + directly as part of the gateway itself in some situations. This + allows consistent attribution and traceability within the service + provider network. It has been observed that the process of + correlating log information is problematic from multiple vendors' + equipment 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 a location may be less + of a concern or a hurdle to deployment. On the other hand, placement + in a centralized fashion would require more strict high-availability + (HA) design. It would also make geolocation based on IPv4 addresses + rather inaccurate as is currently the case for NAT44 CGNs already + deployed in ISP networks. More considerations or workarounds on HA + and traceability can be found in Sections 4 and 5. + +3.1.4. Coexistence of NAT64 and NAT44 + + NAT64 will likely coexist with NAT44 in a dual-stack network where + IPv4 private addresses are allocated to customers. The coexistence + has already been observed in mobile networks, in which dual-stack + mobile phones normally initiate some dual-stack PDN/PDP Type + [RFC6459] to query both IPv4/IPv6 addresses and IPv4-allocated + addresses (which 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, a "Happy Eyeballs" [RFC6555] algorithm 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 it 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 services, but at + different times [COEXIST]. Since the topology on each path is + + + +Chen, et al. Informational [Page 5] + +RFC 7269 NAT64 Experience June 2014 + + + potentially different, it may cause unstable user experience and some + degradation of Quality of Experience (QoE) when falling back to the + other protocol. 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 have at least one + address family accessible via native service if possible. With the + end-to-end native IPv6 environment available, hosts should be + upgraded aggressively to migrate in favor of IPv6 only. There are + ongoing efforts to detect host connectivity and propose a new DHCPv6 + option [CONN-STATUS] 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 a load- + balancing function. Load balancers are employed to connect different + IP family domains and distribute workloads across multiple domains or + internal servers. In some cases, IPv4 address exhaustion may not be + a problem in an IDC's internal network. IPv6 support for some + applications may require increased investment and workload, so IPv6 + support may not be a priority. NAT64 can be used to support + widespread IPv6 adoption on the Internet while maintaining access to + IPv4-only applications. + + Different strategies have been described in [RFC6883]; they are + referred to as "inside out" and "outside in". An IDC operator may + implement the following practices in the NAT64-FE networking + scenario. + + o Some ICPs who already have satisfactory operational experience + might adopt single-stack IPv6 operation in building data center + networks, servers, and applications, as it allows new services to + be delivered without having to consider IPv4 NAT or the address + limitations of IPv4 networks. Stateless NAT64 [RFC6145] can used + to provide services for IPv4-only customers. [SIIT] has provided + further descriptions and guidelines. + + o ICPs who attempt to offer customers IPv6 support in their + application farms at an early stage will likely run proxies, load + balancers, or translators that are configured to handle incoming + IPv6 flows and proxy them to IPv4 back-end systems. Many load + balancers integrate proxy functionality. IPv4 addresses + configured in the proxy may be multiplexed like a stateful NAT64 + translator. A similar challenge exists as more users with IPv6 + connectivity access IPv4 networks. High loads on load balancers + + + +Chen, et al. Informational [Page 6] + +RFC 7269 NAT64 Experience June 2014 + + + may be apt to cause additional latency, IPv4 pool exhaustion, etc. + Therefore, this approach is only reasonable at an early stage. + ICPs may employ dual stack or IPv6 single stack in a further + stage, since native IPv6 is frequently more desirable than any of + the transition solutions. + + [RFC6144] recommends that AAAA records of load balancers or + application servers can be directly registered in the authoritative + DNS servers. In this case, there is no need to deploy DNS64 name + servers. Those AAAA records can point to natively assigned IPv6 + addresses or IPv4-converted IPv6 addresses [RFC6052]. Hosts are not + aware of the NAT64 translator on the communication path. For testing + purposes, operators could employ an independent subdomain, e.g., + ipv6exp.example.com, to identify experimental IPv6 services to users. + How to design the Fully Qualified Domain Name (FQDN) for the IPv6 + service is outside the scope of this document. + +4. High Availability + +4.1. Redundancy Design + + High Availability (HA) is a major requirement for every service and + network service. Deploying redundancy mechanisms is essential to + avoiding failure and significantly increasing the network + reliability. It's useful not only to stateful NAT64 cases but also + to stateless NAT64 gateways. + + Three redundancy modes are mainly used: Cold Standby, Warm Standby, + and Hot Standby. + + o Cold Standby HA devices do not replicate the NAT64 states from the + primary equipment to the backup. Administrators switch on the + backup NAT64 only if the primary NAT64 fails. As a result, all + existing established sessions through a failed translator will be + disconnected. The translated flows will need to be recreated by + end systems. Since the backup NAT64 is manually configured to + switch over to active NAT64, it may have unpredictable impacts to + the ongoing services. + + 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. The + Virtual Router Redundancy Protocol (VRRP)[RFC5798] can be a + solution to enable automatic handover during Warm Standby. During + testing, the handover took a maximum of 1 minute if the backup + NAT64 had to take over routing and reconstruct the Binding + + + + + +Chen, et al. Informational [Page 7] + +RFC 7269 NAT64 Experience June 2014 + + + Information Bases (BIBs) for 30 million sessions. In the + deployment phase, operators could balance loads on distinct NAT64 + devices. Those NAT64 devices 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, the backup NAT64 takes + over and maintains the state of all existing sessions. The + internal hosts don't have to reconnect the external hosts. The + handover time is extremely reduced. During testing that employed + Bidirectional Forwarding Detection (BFD) [RFC5880] combined with + VRRP, a handover time of only 35 ms for 30 million sessions was + observed. Under ideal conditions, Hot Standby deployments could + guarantee the session continuity for every service. In order to + transmit session states in a timely manner, operators may have to + deploy extra transport links between the primary NAT64 and the + distant backup. The scale of synchronization of the data instance + depends on the particular deployment. For example, if a NAT64-CGN + serves 200,000 users, an average amount of 800,000 sessions per + second is a rough estimate of the newly created and expired + sessions. A physical 10 Gbit/s transport link may have to be + deployed for the sync data transmission considering the amount of + sync sessions at the peak and the capacity redundancy. + + In general, Cold Standby and Warm Standby are simpler and less + resource intensive, but they require clients to re-establish sessions + when a failover occurs. Hot Standby increases resource consumption + in order to synchronize state, but it potentially achieves seamless + handover. For stateless NAT64, considerations are simple because + state synchronization is unnecessary. Regarding stateful NAT64, it + may be useful to investigate the performance tolerance of + applications and the traffic characteristics in a particular network. + Some test results are shown in the Appendix A. + + Our statistics in a mobile network shown that almost 91.21% of + traffic is accounted by HTTP/HTTPS services. These services + generally don't require session continuity. Hot Standby does not + offer much benefit for those sessions on this point. In fixed + networks, HTTP streaming, P2P, and online games would be the major + traffic beneficiaries of Hot Standby replication [Cisco-VNI]. + Consideration should be given to the importance of maintaining + bindings for those sessions across failover. Operators may also + consider the Average Revenue Per User (ARPU) when deploying a + suitable redundancy mode. Warm Standby may still be adopted to cover + most services, while Hot Standby could be used to upgrade the Quality + of Experience (QoE) and using DNS64 to generate different synthetic + responses for limited traffic or destinations. Further + considerations are discussed at Section 6. + + + + +Chen, et al. Informational [Page 8] + +RFC 7269 NAT64 Experience June 2014 + + +4.2. Load Balancing + + Load balancing is used to accompany redundancy design so that better + scalability and resiliency can be achieved. Stateless NAT64s allow + asymmetric routing, while anycast-based solutions are recommended in + [MAP-DEPLOY]. The deployment of load balancing may make more sense + to stateful NAT64s for the sake of avoiding single-point failures. + Since the NAT64-CGN and NAT64-FE have distinct facilities, the + following lists the considerations for each case. + + o NAT64-CGN normally doesn't implement load-balancing functions; + they may be implemented in other dedicated equipment. Therefore, + the gateways have to resort to DNS64 or an internal host's + behavior. Once DNS64 is deployed, the load balancing can be + performed by synthesizing the AAAA response with different IPv6 + prefixes. For the applications not requiring a DNS resolver, + internal hosts could learn multiple IPv6 prefixes 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 the front of a + NAT64-FE farm. The load balancer could use 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, a source- + address-based policy, is preferred. A dynamic algorithm, for + example, Round-Robin, may have impacts on applications seeking + session continuity, which are described in Table 1. + +5. Source-Address Transparency + +5.1. Traceability + + Traceability is required in many cases, such as meeting accounting + requirements and identifying the sources of malicious attacks. + 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 was collected from a stateful NAT64 gateway for + 60 days. Syslog [RFC5424] has been adopted to transmit log messages + from NAT64 to a log station. Each log message contains the transport + protocol, source IPv6 address:port, translated IPv4 address:port, and + timestamp. It takes almost 125 bytes in ASCII format. It has been + verified that the rate of traffic flow is around 72,000 flows per + second, and the volume of recorded information reaches up to 42.5 + terabytes in the raw format. The volume is 29.07 terabytes in a + + + + + +Chen, et al. Informational [Page 9] + +RFC 7269 NAT64 Experience June 2014 + + + compact format. At scale, operators have to build up dedicated + transport links, storage systems, and servers for the purpose of + managing such logging. + + There are also several improvements that can be made to mitigate the + issue. For example, stateful NAT64 could be configured with the 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 ports and hence do not require logging. + The log volume in this case may be only one thousandth of that of + dynamic port allocation. Some implementations may adopt static port- + range allocations [DET-CGN] that eliminate the need for per- + subscriber logging. As a side effect of those methods, the IPv4 + multiplexing efficiency is decreased. For example, the utilization + ratio of public IPv4 addresses drops to approximately 75% when the + NAT64 gateway is configured with bulk port allocation. (The lab + testing allocates each subscriber with 400 ports.) In addition, + port-range-based allocation should consider port randomization as + described in [RFC6056]. The trade-off among address multiplexing + efficiency, logging storage compression, and port allocation + complexity should be considered. More discussions can be found in + [PORT-ALLOC]. The decision can balance usable IPv4 resources against + investments in log systems. + +5.2. Geolocation + + IP addresses are usually used as inputs to geolocation services. The + use of address sharing prevents 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 suboptimal + substitution to solve the problem of host identification; in + particular, it may not solve today's 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) [RFC7239], to convey the IPv6 + source address in HTTP headers. Those messages would be passed on + 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 that has been integrated in most load + balancers. Therefore, it may be superior to use in a NAT-FE + environment. On the downside, XFF is specific to HTTP. It + + + + +Chen, et al. Informational [Page 10] + +RFC 7269 NAT64 Experience June 2014 + + + restricts usage so that the solution can't be applied to requests + made over HTTPS. This makes geolocation problematic for HTTPS- + based services. + + o The NAT64-CGN equipment may not implement XFF. Geolocation based + on shared IPv4 addresses is rather inaccurate in that case. + Operators could subdivide the outside IPv4 address pool so an IPv6 + address can be translated depending on the IPv6 subscriber's + geographical locations. As a consequence, location information + can be identified from a certain IPv4 address range. [RFC6967] + also enumerates several options to reveal the host identifier. + Each solution likely has its own specific usage. For the + geolocation systems relying on a RADIUS database [RFC5580], we + have investigated delivering NAT64 BIBs and Session Table Entries + (STEs) to a RADIUS server [NAT64-RADIUS]. This method could + provide a geolocation system with an internal IPv6 address to + identify each user. It can be paired with [RFC5580] to convey the + original source address through the same message bus. + +6. Quality of Experience + +6.1. Service Reachability + + NAT64 is providing a translation capability between IPv6 and IPv4 end + nodes. In order to provide reachability between two IP address + families, NAT64-CGN has to implement appropriate application-aware + functions, i.e., Application Layer Gateways (ALGs), where address + translation is not sufficient and security mechanisms do not render + the functions infeasible. Most NAT64-CGNs mainly provide FTP-ALG + [RFC6384]. NAT64-FEs may have functional richness on the load + balancer; for example, HTTP-ALG, HTTPS-ALG, RTSP-ALG, and SMTP-ALG + have been supported. Those application protocols exchange IP address + and port parameters within a control session, for example, using the + "Via" field in a HTTP header, "Transport" field in an RTSP SETUP + message, or "Received:" header in a SMTP message. ALG functions will + detect those fields and make IP address translations. 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 support. The experiences of some + applications are still aligned with [RFC6586]. For example, we + tested P2P file sharing and streaming applications including eMule + + + +Chen, et al. Informational [Page 11] + +RFC 7269 NAT64 Experience June 2014 + + + v0.50a, Thunder v7.9, and PPS TV v3.2.0. It has been found there are + some software issues with the support of IPv6 at this time. The + application software would benefit from 464XLAT [RFC6877] until the + software adds IPv6 support. A SIP-based voice call has been tested + in the LTE mobile environment as specified in [IR.92]. The voice + call failed due to the lack of NAT64 traversal when an IPv6 SIP user + agent communicates with an IPv4 SIP user agent. In order to address + the failure, Interactive Connectivity Establishment (ICE) as + described in [RFC5245] is recommended to be supported for the SIP + IPv6 transition. [RFC6157] describes both signaling and the media- + layer process, which should be followed. In addition, it is worth + noting that ICE is not only useful for NAT traversal, but also for + firewall [RFC6092] traversal in a native IPv6 deployment. + + Different IPsec modes for VPN services have been tested, including + IPsec Authentication Header (AH) and IPsec Encapsulating Security + Payload (ESP). It has been shown that IPsec AH fails because the + destination host detects the IP header changes and invalidates the + packets. IPsec ESP failed in our testing because the NAT64 does not + translate IPsec ESP (i.e., protocol 50) packets. It has been + suggested that IPsec ESP would succeed if the IPsec client supports + NAT traversal in the Internet Key Exchange Protocol (IKE) [RFC3947] + and uses IPsec ESP over UDP [RFC3948]. + + Table 1: The Tested Applications + + +----------------+----------------------------------------------------+ + | Application | Results and Issues Found | + +----------------+----------------------------------------------------+ + | Web service | Mostly pass; some failures due to IPv4 literals | + +----------------+----------------------------------------------------+ + |Instant Message | Mostly fail; software can't support IPv6 | + +----------------+----------------------------------------------------+ + | Games | Mostly pass for web-based games; mostly fail for | + | | standalone games due to the lack of IPv6 support | + | | in software | + +----------------+----------------------------------------------------+ + | SIP VoIP | Fail, due to the lack of NAT64 traversal | + +----------------+----------------------------------------------------+ + | IPsec VPN | Fail; the translated IPsec packets are invalidated | + +----------------+----------------------------------------------------+ + |P2P file sharing| Mostly fail; software can't support IPv6, | + |and streaming | e.g., eMule, Thunder, and PPS TV | + +----------------+----------------------------------------------------+ + | FTP | Pass | + +----------------+----------------------------------------------------+ + | Email | Pass | + +----------------+----------------------------------------------------+ + + + +Chen, et al. Informational [Page 12] + +RFC 7269 NAT64 Experience June 2014 + + +6.2. Resource Reservation + + Session status normally is managed by a static timer. For example, + the value of the "established connection idle-timeout" must not be + less than 2 hours 4 minutes [RFC5382] for TCP sessions and 5 minutes + for UDP sessions [RFC4787]. In some cases, NAT resources may be + significantly consumed by largely inactive users. The NAT and other + customers would suffer from service degradation due to port + consumption by other subscribers using the same NAT64 device. A + flexible NAT session control is desirable to resolve these issues. + The Port Control Protocol (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 clients through PCP MAP/PEER mode. Doing so + might improve user experiences, for example, by 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 sent by mobile terminal devices. + + Subscribers can also benefit from network reliability. It has been + discussed that Hot Standby offers a satisfactory experience after + outage of the primary NAT64 has occurred. Operators may rightly be + concerned about the considerable investment required for NAT64 + equipment relative to low ARPU. For example, transport links may be + expensive, because the primary NAT64 and the backup are normally + located at different locations, separated by a relatively large + distance. Additional cost would be incurred to ensure the + connectivity quality. However, that may be necessary to applications + that are delay-sensitive and seek session continuity, for example, + online games and live streaming. Operators may be able to get added + value from those services by offering first-class services. The + service sessions can be pre-configured on the gateway to Hot Standby + mode depending on the subscriber's profile. The rest of the sessions + can be covered by Cold or Warm Standby. + +7. MTU Considerations + + IPv6 requires that every link in the Internet have a Maximum + Transmission Unit (MTU) of 1280 octets or greater [RFC2460]. + However, if NAT64 translation is deployed, some IPv4 MTU constrained + link will be used in a communication path and the 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 a fragmentation header in which the "M" + flag is set to 0 and the "Fragment Offset" is set to 0. Those + packets likely impact other fragments already queued with the same + + + +Chen, et al. Informational [Page 13] + +RFC 7269 NAT64 Experience June 2014 + + + set of {IPv6 Source Address, IPv6 Destination Address, Fragment + Identification}. If the NAT64 box is compliant with [RFC5722], there + is a risk that all the fragments will have to be dropped. + + [RFC6946] discusses how this situation could be exploited by an + attacker to perform fragmentation-based attacks and also proposes + improved handling of such packets. It requires enhancements on NAT64 + gateway implementations to isolate the processing of packets. NAT64 + devices should follow the recommendations and take steps to prevent + the risks of fragmentation. + + Another approach that potentially avoids this issue is to configure + the IPv4 MTU to more than 1260 bytes. This would prevent getting a + PTB message for an MTU smaller than 1280 bytes. Such an operational + consideration is hard to universally apply to the legacy "IPv4 + Internet" that is bridged by NAT64-CGNs. However, it's a feasible + approach in NAT64-FE cases, since an IPv4 network NAT64-FE is rather + well-organized and operated by an IDC operator or content provider. + Therefore, the MTU of an IPv4 network in NAT64-FE case is strongly + recommended to be set to more than 1260 bytes. + +8. ULA Usages + + Unique Local Addresses (ULAs) are defined in [RFC4193] to be + renumbered within a network site for local communications. Operators + may use ULAs as NAT64 prefixes to provide site-local IPv6 + connectivity. Those ULA prefixes are stripped when the packets go to + the IPv4 Internet; therefore, ULAs are only valid in the IPv6 site. + The use of ULAs could help in identifying the translation traffic. + [ULA-USAGE] provides further guidance on using ULAs. + + We configure ULAs as NAT64 prefixes on a NAT64-CGN. If a host is + assigned with only an IPv6 address and connected to a NAT64-CGN, when + it connects to an IPv4 service, it would receive a 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 addresses, it would + initiate both A and AAAA record lookup, then both the original A + record and DNS64-generated AAAA record would be received. A host + that is compliant with [RFC6724] will never prefer a ULA over an IPv4 + address. An IPv4 path will always be selected. It may be + undesirable because the NAT64-CGN will never be used. Operators may + consider adding additional site-specific rows into the default policy + table for host address selection in order to steer traffic flows + through the NAT64-CGN. However, it involves significant costs to + change a terminal's behavior. Therefore, it is not suggested that + operators configure ULAs on a NAT64-CGN. + + + + +Chen, et al. Informational [Page 14] + +RFC 7269 NAT64 Experience June 2014 + + + ULAs can't work when hosts transit the Internet to connect with + NAT64. Therefore, ULAs are not applicable to the case of NAT64-FE. + +9. 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 + could also adopt unicast Reverse Path Forwarding (uRPF) [RFC3704] and + blacklisting and whitelisting to enhance security by specifying + access policies. For example, NAT64-CGN should forbid establishing + NAT64 BIB for incoming IPv6 packets if they do not pass the uRPF + check in Strict or Loose mode or if their source IPv6 address is + blacklisted. + + 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. The load balancer is recommended to + enable the capabilities for line-rate DDOS defense, such as the + employment of SYN proxy/cookie. In this case, division of the + security domain is necessary as well. Therefore, load balancers + could not only optimize the traffic distribution but also prevent + service from quality deterioration due to security attacks. + + The DNS64 process will potentially interfere with the DNSSEC + functions [RFC4035], since the DNS response is modified and DNSSEC + intends to prevent such changes. More detailed discussions can be + found in [RFC6147]. + +10. Acknowledgements + + The authors would like to thank Jari Arkko, Dan Wing, Remi Despres, + Fred Baker, Hui Deng, Iljitsch van Beijnum, Philip Matthews, Randy + Bush, Mikael Abrahamsson, Lorenzo Colitti, Sheng Jiang, Nick Heatley, + Tim Chown, Gert Doering, and Simon Perreault for their helpful + comments. + + Many thanks to Wesley George, Lee Howard, and Satoru Matsushima for + their detailed reviews. + + The authors especially thank Joel Jaeggli and Ray Hunter for their + efforts and contributions on editing, which substantially improved + the readability of the document. + + + + + +Chen, et al. Informational [Page 15] + +RFC 7269 NAT64 Experience June 2014 + + + Thanks to Cameron Byrne who was an active coauthor of some earlier + draft versions of this document. + +11. Contributors + + The following individuals contributed extensively 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 + + [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. + + [RFC3947] Kivinen, T., Swander, B., Huttunen, A., and V. Volpe, + "Negotiation of NAT-Traversal in the IKE", RFC 3947, + January 2005. + + [RFC3948] Huttunen, A., Swander, B., Volpe, V., DiBurro, L., and M. + Stenberg, "UDP Encapsulation of IPsec ESP Packets", RFC + 3948, January 2005. + + [RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S. + Rose, "Protocol Modifications for the DNS Security + Extensions", RFC 4035, March 2005. + + [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast + Addresses", RFC 4193, October 2005. + + + + +Chen, et al. Informational [Page 16] + +RFC 7269 NAT64 Experience June 2014 + + + [RFC4787] Audet, F. and C. Jennings, "Network Address Translation + (NAT) Behavioral Requirements for Unicast UDP", BCP 127, + RFC 4787, January 2007. + + [RFC5245] Rosenberg, J., "Interactive Connectivity Establishment + (ICE): A Protocol for Network Address Translator (NAT) + Traversal for Offer/Answer Protocols", RFC 5245, April + 2010. + + [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. + + [RFC6157] Camarillo, G., El Malki, K., and V. Gurbani, "IPv6 + Transition in the Session Initiation Protocol (SIP)", RFC + 6157, April 2011. + + + + +Chen, et al. Informational [Page 17] + +RFC 7269 NAT64 Experience June 2014 + + + [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. + + [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. + + [RFC7239] Petersson, A. and M. Nilsson, "Forwarded HTTP Extension", + RFC 7239, June 2014. + +12.2. Informative References + + [Alexa] Alexa, "Top 500 Global Sites", April 2013, + <http://www.alexa.com/topsites>. + + [COEXIST] Kaliwoda, A. and D. Binet, "Co-existence of both dual- + stack and IPv6-only hosts", Work in Progress, October + 2012. + + [CONN-STATUS] + Patil, P., Boucadair, M., Wing, D., and T. Reddy, "IP + Connectivity Status Notifications for DHCPv6", Work in + Progress, February 2014. + + [Cisco-VNI] + Cisco, "Cisco VNI Global Mobile Data Traffic Forecast, + 2012-2018", February 2014, + <http://ciscovni.com/forecast-widget/index.html>. + + [DET-CGN] Donley, C., Grundemann, C., Sarawat, V., Sundaresan, K., + and O. Vautrin, "Deterministic Address Mapping to Reduce + Logging in Carrier Grade NAT Deployments", Work in + Progress, January 2014. + + + + +Chen, et al. Informational [Page 18] + +RFC 7269 NAT64 Experience June 2014 + + + [IR.92] Global System for Mobile Communications Association + (GSMA), "IMS Profile for Voice and SMS Version 7.0", March + 2013. + + [MAP-DEPLOY] + Qiong, Q., Chen, M., Chen, G., Tsou, T., and S. Perreault, + "Mapping of Address and Port (MAP) - Deployment + Considerations", Work in Progress, April 2014. + + [MAP-T] Li, X., Bao, C., Dec, W., Troan, O., Matsushima, S., and + T. Murakami, "Mapping of Address and Port using + Translation (MAP-T)", Work in Progress, February 2014. + + [MOTIVATION] + Boucadair, M., Matsushima, S., Lee, Y., Bonness, O., + Borges, I., and G. Chen, "Motivations for Carrier-side + Stateless IPv4 over IPv6 Migration Solutions", Work in + Progress, November 2012. + + [NAT64-RADIUS] + Chen, G. and D. Binet, "Radius Attributes for Stateful + NAT64", Work in Progress, July 2013. + + [PORT-ALLOC] + Chen, G., Tsou, T., Donley, C., and T. Taylor, "Analysis + of NAT64 Port Allocation Methods for Shared IPv4 + Addresses", Work in Progress, April 2014. + + [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. + + [RFC6092] Woodyatt, J., "Recommended Simple Security Capabilities in + Customer Premises Equipment (CPE) for Providing + Residential IPv6 Internet Service", RFC 6092, January + 2011. + + [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for + IPv4/IPv6 Translation", RFC 6144, April 2011. + + [RFC6346] Bush, R., "The Address plus Port (A+P) Approach to the + IPv4 Address Shortage", RFC 6346, August 2011. + + + + + + +Chen, et al. Informational [Page 19] + +RFC 7269 NAT64 Experience June 2014 + + + [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. + + [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. + + [SIIT] Anderson, T., "Stateless IP/ICMP Translation in IPv6 Data + Centre Environments", Work in Progress, November 2012. + + [ULA-USAGE] + Liu, B. and S. Jiang, "Recommendations of Using Unique + Local Addresses", Work in Progress, February 2014. + + + + + + + + + + + + + + + + + + + + + + + + +Chen, et al. Informational [Page 20] + +RFC 7269 NAT64 Experience June 2014 + + +Appendix A. Test Results for Application Behavior + + We tested several application behaviors in a lab environment to + evaluate the impact when a primary NAT64 is out of service. In this + testing, participants were asked to connect an IPv6-only WiFi network + using laptops, tablets, or mobile phones. NAT64 was deployed as the + gateway to provide Internet service. The tested applications are + shown in the table below. Cold Standby, Warm Standby, and Hot + Standby were each tested. The participants may have experienced + service interruption due to the NAT64 handover. Different + interruption intervals were tested to gauge application behaviors. + The results are shown below. + + Table 2: The Acceptable Delay of Applications + + +----------------+------------------------+-------------------------+ + | Application | Acceptable Interrupt | Session Continuity | + | | Recovery | | + +----------------+------------------------+-------------------------+ + | Web browsing | Maximum of 6 s | No | + +----------------+------------------------+-------------------------+ + | HTTP streaming | Maximum of 10 s (cache)| Yes | + +----------------+------------------------+-------------------------+ + | Games | 200-400 ms | Yes | + +----------------+------------------------+-------------------------+ + |P2P file sharing| 10-16 s | Yes | + |and streaming | | | + +----------------+------------------------+-------------------------+ + | Instant Message| 1 minute | Yes | + +----------------+------------------------+-------------------------+ + | Email | 30 s | No | + +----------------+------------------------+-------------------------+ + | Downloading | 1 minute | No | + +----------------+------------------------+-------------------------+ + + + + + + + + + + + + + + + + + +Chen, et al. Informational [Page 21] + +RFC 7269 NAT64 Experience June 2014 + + +Authors' Addresses + + Gang Chen + China Mobile + Xuanwumenxi Ave. No. 32 + Xuanwu District + Beijing 100053 + P.R. China + + EMail: chengang@chinamobile.com, phdgang@gmail.com + + Zhen Cao + China Mobile + Xuanwumenxi Ave. No. 32 + Xuanwu District + Beijing 100053 + P.R. China + + EMail: caozhen@chinamobile.com, zehn.cao@gmail.com + + + Chongfeng Xie + China Telecom + Room 708, No. 118, Xizhimennei Street + Beijing 100035 + P.R. China + + EMail: xiechf@ctbri.com.cn + + + David Binet + France Telecom-Orange + Rennes + 35000 + France + + EMail: david.binet@orange.com + + + + + + + + + + + + + + +Chen, et al. Informational [Page 22] + |