RFC 7269
NAT64 Deployment Options and Experience
RFC 7269 🎀 NAT64 Deployment Options and Experience
Okay bestie, this is the title block 💖
- Series: Internet Engineering Task Force (IETF)
- Request for Comments: 7269
- Authors: G. Chen, Z. Cao (both China Mobile), C. Xie (China Telecom), and D. Binet (France Telecom-Orange)
- Category: Informational
- ISSN: 2070-1721
- Date: June 2014
- Obsoletes / Updates: none listed in the title block 🦋
Abstract ✨
okay so this doc sums up how NAT64 gets deployed in real life and what operators actually learned from it 🧚 It covers both NAT64 Carrier-Grade NAT (NAT64-CGN) and NAT64 server Front End (NAT64-FE) 💅
Status of This Memo 🌸
this is NOT a standards track spec, it's published just for info 📚
it's a product of the Internet Engineering Task Force (IETF) and it represents the consensus of the IETF community 🫶 it got public review and the Internet Engineering Steering Group (IESG) approved it for publication. not every IESG-approved doc is a candidate for any level of Internet Standard, so check Section 2 of RFC 5741 if you're curious 🙈
current status, errata, and feedback info live 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 doc is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the publication date. pls actually read those, they explain your rights and restrictions for this doc 🥹 and if you pull Code Components out of this doc, they must include the Simplified BSD License text described in Section 4.e of the Trust Legal Provisions, and they come with no warranty, as the Simplified BSD License says 🔥
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 . . . . . . . 211. Introduction 🌈
okay so IPv6 is the only sustainable answer for numbering nodes on the Internet, because IPv4 is running out 😭 network operators basically have to roll out IPv6-only networks to keep up with the Internet growing without any IPv4 addresses left 💅
single-stack IPv6 can make network provisioning way simpler, and 464XLAT [RFC6877] has some of the justification for that 🎀 IPv6-only connectivity is also a win for mobile operators. in mobile, IPv6-only usage means you can use a single IPv6 Packet Data Protocol (PDP) context or Evolved Packet System (EPS) bearer on Long Term Evolution (LTE) networks. that cuts out big network costs (sometimes you'd need two PDP contexts otherwise) and skips the need to assign IPv4 addresses to customers 🙌 in broadband in general, it lets edge-network growth scale without being stuck on IPv4 numbering limits 🚀
in transition, some networks are gonna stay IPv4 only for quite a while 🥲 IPv6 networks and IPv6-only hosts will have to coexist with IPv4 numbered resources. dual-stack deployments haven't shown up at the rate people expected over the last 10 years, and one possible read is that legacy networks won't jump over quickly 🙈 so the Internet will have dual-stack nodes, IPv4-only nodes, and nodes that can be deployed as IPv6-only. a translation mechanism based on a NAT64 function [RFC6145] [RFC6146] is likely to be a key piece of Internet connectivity for IPv6-IPv4 interoperability ✨
[RFC6036] reports that at least 30% of operators plan to run some kind of translator (presumably NAT64/DNS64). so advice on NAT64 deployment and operations is kind of a big deal 💜 [RFC6586] documents the implications for IPv6-only networks. this doc is meant to be specific to NAT64 network planning 🧚
2. Terminology 📚
okay so [RFC6144] describes a framework for making interworking possible between IPv4 and IPv6 networks 🦋 it describes two operation modes, stateful translation and stateless translation, in Section 3.2 of [RFC6144]. this doc covers how those two modes get used, and it further sorts NAT64 functions, locations, and use cases 💅 the main location distinction is whether the NAT64 sits in a Carrier-Grade NAT or a server Front End. the terms "NAT-CGN" and "NAT-FE" are a topological distinction that signal different features used in a NAT64 deployment 🌸
- NAT64 Carrier Grade NAT (NAT64-CGN): a NAT64-CGN lives in an ISP network 🏠 IPv6-enabled subscribers use it to reach existing IPv4 Internet services. the ISP, as an administrative entity, fully controls the IPv6 side, but has limited or no control over the IPv4 Internet side. so NAT64-CGN deployments may have to think about the IPv4 Internet environment and its services, and pick configuration choices to match 🍓
- 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 a traffic load balancer or a firewall, for example 🧱 the NAT64-FE operator has full control over the IPv4 network inside the data center, but only limited influence or control over the external Internet IPv6 network 👑
3. NAT64 Networking Experience 💖
3.1. NAT64-CGN Consideration 🌷
3.1.1. NAT64-CGN Usages 🎀
fixed network operators and mobile operators may put NAT64 translators in access networks or in mobile core networks 🗼 NAT64 can be built into all sorts of devices, like routers, gateways, or firewalls, so IPv6 users can connect to the IPv4 Internet 🌐 given how many users there are and how short public IPv4 addresses are, stateful NAT64 [RFC6146] is the better fit for squeezing the most out of shared public IPv4 addresses 🙌 stateless NAT64 can give better transparency features [MOTIVATION], but it has to be coordinated with Address plus Port (A+P) processes [RFC6346] as specified in [MAP-T] to deal with an IPv4 address shortage 💅
3.1.2. DNS64 Deployment 🛰️
okay this part is so important 🫶 DNS64 [RFC6147] is recommended for use together 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 to IPv4-only applications, or applications that use IPv4 literal addresses 🎀 using DNS64 helps 464XLAT automatically discover NAT64 prefixes through [RFC7050] 🔍 Berkeley Internet Name Daemon (BIND) software supports that function 💜
the big thing to know: DNS64 generates the synthetic AAAA reply when services only provide A records 🤯 operators should not expect to reach the IPv4 parts of a dual-stack server using NAT64/DNS64. traffic gets forwarded on IPv6 paths when dual-stack servers are the target, and IPv6 traffic may be routed around instead of going through NAT64 🛣️ only traffic going to IPv4-only services has to traverse the NAT64 translator. in a way, that encourages IPv6 usage and limits NAT translation, compared to NAT44, where every traffic flow has to be translated 🦋 in some cases NAT64-CGNs may serve double roles, as a translator and an IPv6 forwarder 🧚 in mobile networks, NAT64 may be deployed as the default gateway serving all the IPv6 traffic. traffic heading to a dual-stack server only gets forwarded on the NAT64, so both IPv6 and IPv4 are suggested to be configured on the Internet-facing interfaces of NAT64 🔥
we tested the top 100 websites (referring to [Alexa] statistics) 📊 43% of them get connected and forwarded on NAT64, since those websites have both AAAA and A records 😳 with IPv6 support expanding, the translation process on NAT64 will likely matter less over time 🌈
one more: the DNS64-DNSSEC interaction [RFC6147] may impact validation of Resource Records retrieved from the DNS64 process 🙈 specifically, DNSSEC validation will fail when DNS64 synthesizes AAAA records for a DNS query received with the "DNSSEC OK" (DO) bit set and the "Checking Disabled" (CD) bit set 💀
3.1.3. NAT64 Placement ✨
Okay so, every connection to an IPv4 service from an IPv6-only client has to go through the NAT64-CGN, no exceptions 💅. It can be a big win for troubleshooting and traffic engineering to keep the IPv6 traffic native for as long as possible inside the access network and only translate packets at or near the network egress 🦋. In fixed networks, NAT64 may be a feature of the Autonomous System (AS) border 🌸. In mobile networks, it may be deployed in an IP node beyond the Gateway GPRS Support Node (GGSN) or Packet Data Network Gateway (PDN-GW), or directly as part of the gateway itself in some situations 🧚. This gives consistent attribution and traceability inside the service provider network, which is so iconic 🫶. It's been observed that correlating log information is a mess across multiple vendors' equipment because the log record formats are inconsistent 😭. Putting NAT64 in a centralized spot may reduce the diversity of log formats and simplify network provisioning 💜.
Also, NAT64 is only aimed at serving traffic flows from IPv6 to IPv4-only services, so the user traffic volume shouldn't be as high as in a NAT44 scenario. That means the gateway's capacity in that location may be less of a concern or hurdle to deployment 💖. ngl, though, centralized placement would need a stricter high-availability (HA) design 💀. It would also make geolocation based on IPv4 addresses pretty inaccurate, which is already the case for NAT44 CGNs 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 🌈. This has already been spotted in mobile networks, where dual-stack phones normally set up a dual-stack PDN/PDP Type [RFC6459] so they can query both IPv4 and IPv6 addresses, plus IPv4-allocated addresses (which are very often private ones) 📱. [RFC6724] always prioritizes IPv6 connections, whether the end-to-end path is native IPv6 or IPv6 translated to IPv4 via NAT64/DNS64 👑. Meanwhile, a "Happy Eyeballs" [RFC6555] algorithm will steer some IP flows across IPv4 paths 🦋. Which path gets picked can depend on particular implementation choices or settings on a host-by-host basis, and it may not match an operator's deterministic scheme 🤷♀️.
Our tests verified that hosts may end up switching between IPv4 and IPv6 paths as they access identical services at different times [COEXIST] 😳. Since the topology on each path can be totally different, this may cause an unstable user experience and some degradation of Quality of Experience (QoE) when falling back to the other protocol 💅. It's also hard for operators to find a way to keep the network stable with optimal resource utilization 😭. In general, it's desirable to figure out a solution that introduces IPv6/IPv4 translation service for 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 an end-to-end native IPv6 environment available, hosts should be upgraded aggressively to move toward IPv6 only 🚀. There are ongoing efforts to detect host connectivity and propose a new DHCPv6 option [CONN-STATUS] to convey the right configuration information to 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 used to connect different IP family domains and spread workloads across multiple domains or internal servers 🎀. In some cases, IPv4 address exhaustion isn't a problem inside an IDC's internal network 🙌. IPv6 support for some applications may need extra investment and workload, so IPv6 support may not be a priority 🥲. NAT64 can still be used to support widespread IPv6 adoption on the Internet while keeping access to IPv4-only applications 🌍.
Different strategies have been described in [RFC6883]; they're called "inside out" and "outside in" 🔄. An IDC operator may use the following practices in the NAT64-FE networking scenario 📋.
- Some ICPs who already have satisfactory operational experience might adopt single-stack IPv6 operation when building data center networks, servers, and applications. That's because new services can be delivered without having to think about IPv4 NAT or the address limitations of IPv4 networks 💅. Stateless NAT64 [RFC6145] can be used to provide services for IPv4-only customers. [SIIT] has more descriptions and guidelines 📚.
- ICPs who try 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 come with proxy functionality built in 🔧. IPv4 addresses configured in the proxy may be multiplexed, like a stateful NAT64 translator 🪞. A similar challenge shows up as more users with IPv6 connectivity access IPv4 networks 😩. High loads on load balancers may cause extra latency, IPv4 pool exhaustion, and so on 💀. So this approach is only reasonable at an early stage ⏳. ICPs may move to dual stack or IPv6 single stack later, 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 registered directly in the authoritative DNS servers 📝. In that case, there's no need to deploy DNS64 name servers 🙅♀️. Those AAAA records can point to natively assigned IPv6 addresses or IPv4-converted IPv6 addresses [RFC6052] 🎯. Hosts aren't aware of the NAT64 translator on the communication path 🫥. For testing, operators could use 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 for avoiding failure and significantly increasing network reliability 🛡️. It's useful not only for stateful NAT64 cases but also for stateless NAT64 gateways 🫶.
Three redundancy modes are mainly used: Cold Standby, Warm Standby, and Hot Standby 🎀.
- Cold Standby HA devices don'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 a result, all existing established sessions through a failed translator get disconnected, and end systems will need to recreate the translated flows 💀. Since the backup NAT64 is manually configured to switch over to active NAT64, it may have unpredictable impacts on ongoing services 😬.
- Warm Standby is a flavor of Cold Standby. The backup NAT64 keeps running while the primary NAT64 is working, which makes failover quicker 🏃♀️. The Virtual Router Redundancy Protocol (VRRP) [RFC5798] can be a solution for automatic handover during Warm Standby 🤖. During testing, the handover took a maximum of 1 minute when the backup NAT64 had to take over routing and reconstruct the Binding Information Bases (BIBs) for 30 million sessions ⏱️. In the deployment phase, operators could balance loads across distinct NAT64 devices, and those NAT64 devices make a warm backup of each other ⚖️.
- Hot Standby must synchronize the BIBs between the primary NAT64 and the backup 🔥. When the primary NAT64 fails, the backup NAT64 takes over and maintains the state of all existing sessions, so internal hosts don't have to reconnect to external hosts ✨. The handover time is extremely reduced. During testing that used Bidirectional Forwarding Detection (BFD) [RFC5880] combined with VRRP, a handover time of only 35 ms was observed for 30 million sessions ⚡. Under ideal conditions, Hot Standby deployments could guarantee session continuity for every service 👑. 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 of 800,000 sessions per second is a rough estimate of 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 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 uses more resources to synchronize state, but it potentially achieves seamless handover 🌟. For stateless NAT64, things are simple because state synchronization isn't necessary 🍓. For 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 Appendix A 📎.
Our statistics from a mobile network show that almost 91.21% of traffic is accounted for by HTTP/HTTPS services 📱. These services generally don't require session continuity, so Hot Standby doesn't offer much benefit for those sessions on this point 🙅♀️. In fixed networks, HTTP streaming, P2P, and online games would be the major beneficiaries of Hot Standby replication [Cisco-VNI] 🎮. Consideration should be given to how important it is to maintain 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 Quality of Experience (QoE), and DNS64 could generate different synthetic responses for limited traffic or destinations 🌈. Further considerations are discussed in Section 6 🫶.
4.2. Load Balancing ✨
okay so load balancing is the friend that shows up to help redundancy design get even better 💖 together they give you better scalability and resiliency. 🦋 stateless NAT64s allow asymmetric routing, and anycast-based solutions are recommended in [MAP-DEPLOY]. 🌸 for stateful NAT64s, load balancing might make more sense, because it helps avoid single-point failures. bc NAT64-CGN and NAT64-FE have totally different facilities, here's what to think about for each one 👑
- NAT64-CGN normally doesn't implement load-balancing functions 🙈 those can live in other dedicated equipment. so the gateways have to resort to DNS64 or an internal host's behavior. once DNS64 is deployed, load balancing can happen by synthesizing the AAAA response with different IPv6 prefixes ✨ for apps that don't need a DNS resolver, internal hosts could learn multiple IPv6 prefixes through the approaches defined in [RFC7050] and then pick one based on a given prefix selection policy 🧚
- a dedicated load balancer could sit at the front of a NAT64-FE farm 💅 it could use proxy mode to redirect flows to the right NAT64 instance. stateful NAT64s need a deterministic pattern to arrange the traffic, so outbound and inbound flows traverse the identical NAT64 🔥 that's why static scheduling algorithms, for example a source-address-based policy, are preferred. a dynamic algorithm, like 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, like meeting accounting requirements and identifying the sources of malicious attacks 🕵️♀️ operators are asked to record 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 compact format. at scale, operators have to build up dedicated transport links, storage systems, and servers just to manage this logging. the amount of data is honestly wild 💀
there are also several improvements that can help with this 🍓 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. it's all about balance, bestie ⚖️✨
5.2. Geolocation
IP addresses are usually used as inputs to geolocation services 🗺️ but address sharing stops these systems from resolving the location of a host based on IP address alone. so apps that assume that geographic info may not work as intended 😩 the possible solutions listed in [RFC6967] are meant to bridge the gap. however, those solutions can only provide a suboptimal substitution for host identification. in particular, they may not solve today's problems with source identification through translation. here are the current practices to mitigate the issue 🫶
- operators who adopt NAT64-FE may leverage 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 they may look up 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, so it may be superior to use in a NAT-FE environment ✨ on the downside, XFF is specific to HTTP. it restricts usage so the solution can't be applied to requests made over HTTPS. this makes geolocation problematic for HTTPS-based services 😭
- the NAT64-CGN equipment may not implement XFF. in that case, geolocation based on shared IPv4 addresses is rather inaccurate 🙃 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, and 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 give a geolocation system 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 provides a translation capability between IPv6 and IPv4 end nodes 🦋 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 make those functions infeasible. most NAT64-CGNs mainly provide FTP-ALG [RFC6384]. NAT64-FEs may have more features 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 an HTTP header, the "Transport" field in an RTSP SETUP message, or the "Received:" header in an SMTP message. ALG functions 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 and content providers might choose to avoid situations where an ALG might be required. at the same time, it's important to remind customers and app developers that IPv6 end-to-end usage does not require ALG and therefore results in a better overall user experience 👑
service reachability also depends on IPv6 support on the client side 🧚♀️ we tested several kinds of applications, as shown in the table below, to verify IPv6 support. the experiences of some applications still align with [RFC6586]. for example, we tested P2P file sharing and streaming apps including eMule v0.50a, Thunder v7.9, and PPS TV v3.2.0. some software has issues with IPv6 support at this time. apps would benefit from 464XLAT [RFC6877] until the software adds IPv6 support. a SIP-based voice call was tested in an 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 😱 to fix that, Interactive Connectivity Establishment (ICE) as described in [RFC5245] is recommended to be supported for SIP IPv6 transition. [RFC6157] describes both the signaling and the media-layer process, which should be followed. it's also 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 were tested, including IPsec Authentication Header (AH) and IPsec Encapsulating Security Payload (ESP). it was 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 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 |
+----------------+----------------------------------------------------+6.2. Resource Reservation 🎀
okay so session status usually gets managed by a static timer 🕰️ 🙄 For example, 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]. ngl, that's a lot of timer for something that's just sitting there. In some cases, NAT resources get eaten up by users who are barely active at all 💀 The NAT and other customers then get service degradation because other subscribers on the same NAT64 device are using up the ports. bestie, we need a flexible NAT session control to fix this 💅 The Port Control Protocol (PCP) [RFC6887] could be a candidate to provide that capability. A NAT64-CGN should integrate with a PCP server to allocate available IPv4 address/port resources. Those resources could be assigned to PCP clients through PCP MAP/PEER mode. Doing this might improve user experiences, for example by assigning different sizes of port ranges to different subscribers ✨ These mechanisms also help minimize terminal battery consumption and cut down on the number of keep-alive messages sent by mobile terminal devices 🔋 main character energy for mobile devices 🦋
Subscribers can also benefit from network reliability 🫶 It's been discussed that Hot Standby gives a satisfying experience after an outage of the primary NAT64. Operators may be rightly concerned about the big investment needed for NAT64 equipment compared to low ARPU 😭 Transport links can be expensive, because the primary NAT64 and the backup are normally in different locations, separated by a relatively large distance. Extra cost would come with making sure the connectivity quality holds up 💸 That said, it may be necessary for apps that are delay-sensitive and need session continuity, like 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 🦋
okay this one is giving drama 🔥 IPv6 requires that every link in the Internet have a Maximum Transmission Unit (MTU) of 1280 octets or greater [RFC2460]. However, once NAT64 translation is deployed, some IPv4 MTU constrained link will be in a communication path, so the originating IPv6 nodes may receive an ICMP Packet Too Big (PTB) message reporting a Next-Hop MTU less than 1280 bytes 😱 The result is that IPv6 allows packets to contain a fragmentation header without the packet actually 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 are likely to 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's 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 it 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 apply universally to the legacy "IPv4 Internet" that is bridged by NAT64-CGNs 😅 It is, however, 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 the NAT64-FE case is strongly recommended to be set to more than 1260 bytes 🫶
8. ULA Usages 🌈
so 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 get stripped when the packets go out to the IPv4 Internet, so ULAs are only valid inside 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 only an IPv6 address and connected to a NAT64-CGN, then when it connects to an IPv4 service, it receives an AAAA record generated by the DNS64 with the ULA prefix. A Global Unicast Address (GUA) gets selected as the source address to the ULA destination address. When the host has both IPv4 and IPv6 addresses, it initiates both A and AAAA record lookups, so both the original A record and the DNS64-generated AAAA record get received 👀 A host that is compliant with [RFC6724] will never prefer a ULA over an IPv4 address. An IPv4 path will always be selected 😭 That 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, changing a terminal's behavior involves significant costs 💸 Therefore, it is not suggested that operators configure ULAs on a NAT64-CGN.
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 💀
okay bestie, this part is SERIOUS 🚨 This document presents the deployment experiences of NAT64 in CGN and FE scenarios. In general, RFC 6146 [RFC6146] provides TCP-tracking and address-dependent filtering mechanisms to protect NAT64 from Distributed Denial of Service (DDoS) attacks 🛡️ In NAT64-CGN cases, operators could also adopt unicast Reverse Path Forwarding (uRPF) [RFC3704], plus blacklisting and whitelisting, to enhance security by specifying access policies. For example, a NAT64-CGN should forbid establishing a 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, dividing 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 📝✨
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.cn12. References 📚
the reference list is up next, so keep your eyes peeled 👀🦋
12.1. Normative References ✨
These are the big must-reads 📚🎀 (the ones the spec leans on). Here's the full list, exactly as it's written:
[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.
[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.
[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 🌸
These are the extra-credit reads 🧠 (background and related work, and a bunch of drafts still in progress). Here's the full list:
[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.
[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.
[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.Appendix A. Test Results for Application Behavior 🧪
Okay so, we ran a bunch of apps in a lab to see how they'd cope when the primary NAT64 goes down 😭. The setup was an IPv6-only WiFi network, and people hopped on with laptops, tablets, or phones. NAT64 was the gateway for internet access. Cold Standby, Warm Standby, and Hot Standby were each tested. Participants may have felt a service interruption during the NAT64 handover, so we tried different interruption lengths to see how each app reacted. Here's the tea 🍵:
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 |
+----------------+------------------------+-------------------------+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📦 where this page comes from
- ietf: rfc7269 2014-06
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms