RFC 6586
Experiences from an IPv6-Only Network
RFC 6586: Experiences from an IPv6-Only Network 🎀
okay bestie, this is RFC 6586, and it's called Experiences from an IPv6-Only Network ✨ It was written by J. Arkko and A. Keranen, both at Ericsson, and it came out in April 2012. It's an IETF doc with the category Informational, so it's sharing real-life lessons, not setting a standard 💅 The ISSN is 2070-1721. The title block doesn't list anything it obsoletes or updates, so it's totally its own thing 🦋
Abstract 💜
this doc talks about what happened when we moved a small group of users onto an IPv6-only network, where they could still reach the IPv4-only parts of the Internet through a NAT64 device 🌈 It covers the practical stuff, the roadblocks, and the opportunities, and it gives some recs on where setups like this make sense and what to think about in the network design. It also flags the further work we still need to do before IPv6-only networking works everywhere 🫶
Status of This Memo 📜
this is not an Internet Standards Track specification. It's published for information only 🌸
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 was approved for publication by the Internet Engineering Steering Group (IESG). Not every doc the IESG approves is up for any level of Internet Standard, so check Section 2 of RFC 5741 if you want the full story 🧚
For the current status, any errata, and how to give feedback, go to http://www.rfc-editor.org/info/rfc6586 ✨
Copyright Notice 🔒
Copyright (c) 2012 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) as they stand on the date this doc was published. Please read these carefully, because they spell out your rights and restrictions for this doc, no cap 📚 Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions, and they come without warranty, as described in the Simplified BSD License 🫶
Table of Contents 🧚
1. Introduction ....................................................3
2. Technology and Terminology ......................................4
3. Network Setup ...................................................4
3.1. The IPv6-Only Network ......................................5
3.2. DNS Operation ..............................................6
4. General Experiences .............................................7
5. Experiences with IPv6-Only Networking ...........................9
5.1. Operating Systems ..........................................9
5.2. Programming Languages and APIs ............................10
5.3. Instant Messaging and VoIP ................................11
5.4. Gaming ....................................................12
5.5. Music Services ............................................13
5.6. Appliances ................................................13
5.7. Other Differences .........................................13
6. Experiences with NAT64 .........................................13
6.1. IPv4 Address Literals .....................................14
6.2. Comparison of Web Access via NAT64 to Other Methods .......15
7. Future Work ....................................................15
8. Conclusions and Recommendations ................................16
9. Security Considerations ........................................18
10. References ....................................................19
10.1. Normative References .....................................19
10.2. Informative References ...................................19
Appendix A. Acknowledgments .......................................211. Introduction ✨
okay so this doc is all about our experiences moving a small number of users to an IPv6-only network. They can still reach the IPv4-only parts of the Internet through a NAT64 device 🦋 This wasn't a temporary experiment. We set it up with a permanent change in mind, and it involves both office and home users, a mix of computing equipment, and a bunch of different applications. We learned the practical details, the roadblocks and opportunities, and a more general sense of when a setup like this can be recommended and what to think about in the network design 💅 Just note that this memo mostly covers what we saw in 2010. Things change as software gets updated, new products show up, and so on 🌸
The networks in this setup had been running in dual-stack mode for a long time. In one case, that was over ten years 🎀 Our IPv6 connectivity is stable and used all the time, with no big problems. Since the IETF is working on tech like NAT64 [RFC6144] and a few network providers were talking about going IPv6-only, we decided to push our network beyond the "comfort zone" and really understand what it means to have no IPv4 connectivity at all 🔥 This also let us test a NAT64 device that Ericsson is developing ✨
The main takeaway is that IPv6-only networking is possible, but there are a bunch of issues, like some applications not supporting IPv6 and bugs in parts of the code that nobody had tested yet 😭 Because of that, dual-stack [RFC4213] is still our recommended model for general purpose networking right now. IPv6-only networking can be used by early adopters or in highly controlled networks 🧚 The doc also suggests actions to make IPv6-only networking work in all environments. Fixing problems with a handful of key applications would make a huge difference for large groups of users and networks, which is a big deal 👑 It's really important that the Internet community understands these deployment barriers and works to remove them 🫶
The rest of this doc is laid out like this. Section 2 introduces some relevant tech and terms. Section 3 describes the network setup. Section 4 covers our general experiences. Section 5 covers experiences related to having only IPv6 networking available. Section 6 covers experiences related to NAT64 use. Section 7 shares some of our ideas for future work. Section 8 draws conclusions and makes recommendations on when and how to use IPv6-only networks. Finally, Section 9 talks about the relevant security considerations 💖
2. Technology and Terminology 🧠
in this doc, these terms come up a lot. "NAT44" refers to any IPv4-to-IPv4 network address translation algorithm, including both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663] 🦋
"Dual-stack" refers to a technique for fully supporting both Internet protocols, IPv4 and IPv6, in hosts and routers [RFC4213] ✨
"NAT64" refers to a Network Address Translator - Protocol Translator defined in [RFC6144], [RFC6145], [RFC6146], [RFC6052], [RFC6147], and [RFC6384] 🌈
3. Network Setup 🏡
we tested IPv6-only networking in two different environments: office and home 🎀 In both, all the hosts already had normal dual-stack native IPv4 and IPv6 Internet access. The networks were already using IPv6 in their servers and DNS records too 💜 The network was also part of a whitelisting arrangement, so IPv6-capable content providers could serve their content to the network over IPv6 🫶
The office has a mixed bag of hardware, with PCs, laptops, and routers running Linux, BSD, Mac OS X, and Microsoft Windows 💻 Common uses include email, Secure Shell (SSH), web browsing, and various instant messaging and Voice over IP (VoIP) apps. The home has PCs, laptops, and a bunch of server, camera, and sensor appliances 📷 The main operating systems there are Linux and Microsoft Windows. Common apps include web browsing, streaming, instant messaging and VoIP, gaming, file storage, and various home control apps 🏠
Both environments use lots of firewalling, and filtering is applied to both IPv4 and IPv6 traffic. But firewall capabilities, especially in older firewall software, mean the IPv4 and IPv6 filtering isn't identical, because some features that were common for IPv4 weren't implemented for IPv6 yet 🔥 Also, in the home, individual devices are directly reachable from the Internet over IPv6 (for select protocols like SSH), but not over IPv4, because there aren't enough public IPv4 addresses available 🙈
In both environments, volunteers could opt in to the IPv6-only network. The group was small: roughly five permanent users, plus a dozen users who had been on the network for at least some amount of time 🧚 Each user had to connect to the IPv6-only wired or wireless network. Depending on their software, they might also have had to set up their computer by indicating that there is no IPv4 and/or by setting DNS server addresses 💅 The users were also asked to report their experiences back to the organizers ✨
3.1. The IPv6-Only Network ✨
okay so the IPv6-only network was built as a parallel network sitting right beside the existing dual-stack one 💖 we kept the dual-stack network around for the people who didn't opt in, and because we knew there were still some IPv4-only devices floating around the house 🏠 a separate wired access network got made using VLANs (Virtual Local Area Networks), and it got its very own IPv6 prefix 🎀 then there was a separate wireless network bridged to the wired one. the wireless part needed extra access point hardware, because the simple access point model we used couldn't advertise multiple wireless networks from a single device. lowkey annoying, since plenty of other access points can do it 🙄 all this secondary infrastructure added some management burden and cost, not gonna lie 💀 and it got extra messy because the home network already had two setups, one for family and one for visitors. to copy that model for the IPv6-only network, there are now four separate networks, with several access points on each one 🌸 iconic, but a lot of hardware 😭
the IPv6-only networks sit on the edge of the network with a stateful NAT64 [RFC6146] that has DNS64 built in 🦋 no IPv4 routing and no Dynamic Host Configuration Protocol (DHCP) is offered on these networks. the NAT64 device sends Router Advertisements (RAs) [RFC4861], and that's how the hosts learn the IPv6 prefix and can configure their own IPv6 addresses automatically 🧚 each new IPv6-only network needs one new /64 prefix for those advertisements. on top of that, each NAT64 device needs another /64 prefix for representing IPv4 destinations inside the IPv6-only network. so one IPv6-only network needs a /63 of address space in total ✨ good news though: this space was easy to find, because IPv6 allocations are deliberately made in big blocks 👑 extra address space can come out of the existing block without any registry involvement. another option would have been to use the Well-Known Prefix [RFC6052] to represent IPv4 destinations in the IPv6-only network 🍓 either way, the prefixes have to be listed in the intra-domain routing system so they can actually be reached. in one case, going from one block to several also meant we needed an improved routing configuration 🔥 and the new prefixes have to be added to the right firewall rules too.
setting up NAT64 and DNS64 by themselves is easy, and an experienced network manager can do it quickly 💅 the thing that takes time is duplicate infrastructure. when you need separate gear for dual-stack and IPv6-only networks, the extra switches, cables, access points and so on take a bit of installation effort 🫶 and if whitelisting agreements or IPv6 ISP connectivity are involved, you'll need to negotiate with outside partners first 🤝 not the vibe, but it's the reality.
3.2. DNS Operation 🌈
Router Advertisements carry DNS Configuration options [RFC6106], and those options list the DNS64 as the DNS server the hosts should use 💜 we also added aliases to the DNS64 device, so it can receive packets sent to the well-known DNS server addresses that Windows operating systems use: fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0:0:0:ffff::3 🧁 later on, we added support for stateless DHCPv6 [RFC3736] too. we do recommend turning on RFC 6106, the well-known addresses, and stateless DHCPv6, because that gives different types of IPv6-only hosts the best shot at using DNS without anyone configuring things by hand 🎀 DNS server discovery was never a problem in dual-stack networks, since DNS servers on the IPv4 side can easily hand out IPv6 information (AAAA records) as well 🙌 but with IPv6-only networking, it becomes crucial that the local DNS server can also be reached over IPv6 🚨 in principle, it's exactly the same as needing IPv4-based DNS and DNS discovery in IPv4-only networks. the catch is that IPv6 discovery is a bit more complicated, because there are several alternative techniques 😵💫
when a host served by the DNS64 asks for a domain name that has no AAAA (IPv6 address) record but does have an A (IPv4 address) record, the DNS64 synthesizes a AAAA record from that A record (as defined for DNS64 in [RFC6147]) and sends it back in the DNS response 🦋 packets sent to that synthesized address get routed through the NAT64, translated to IPv4 by the NAT64, and forwarded to the queried host's IPv4 address. return traffic gets translated from IPv4 back to IPv6 and forwarded to the host behind the NAT64 (as described in [RFC6144]) 🔁 the result is that hosts in the IPv6-only network can contact any host on the IPv4 Internet, as long as those hosts have DNS address records. honestly, that's the magic part ✨
the NAT64 devices have standard dual-stack connectivity, and their DNS64 function can use both IPv4 and IPv6 when it asks DNS for information 💻 a destination that has both an A and AAAA record isn't handled in any special way, because hosts in the IPv6-only network can reach it over IPv6 anyway 🌸 destinations with only an A record get the synthesized AAAA record described above. however, one of our open visitor networks shares infrastructure with the home network, so that one needed a special setup 🙈 right now, the home network gets its IPv6 connectivity through a tunnel via the office network, and it's undesirable to let outsiders on the visitor network generate traffic through the office network. that's true even when the traffic is just passing through and being forwarded to the IPv6 Internet 🚫 so in the visitor network, there's a special IPv6-only to IPv4-only configuration where the DNS64 never asks for AAAA records and always generates synthesized records. this means no traffic from the visitor network goes through the office network, even traffic headed to the IPv6 Internet, but traffic from the home network can still use the IPv6 connectivity the office network provides 🧚♀️ main character energy for the home network, no cap 👑
Note: This configuration may also be useful for other purposes. For instance, one drawback of the standard behavior is that if a destination publishes AAAA records but has bad IPv6 connectivity, the hosts in the IPv6-only network have no fallback. In the dual-stack model, a host can always try IPv4 if the IPv6 connection fails. In the special configuration, IPv6 is only used internally at the site but never across the Internet, eliminating this problem. This is not a recommended mode of operation, but it is interesting to note that it may solve some issues. 💀
Note that in NAT64 (unlike in its older variant [RFC4966]) it is possible to decouple the packet translation, IPv6 routing, and DNS64 functions 🧩 since clients are configured to use a DNS64 as their DNS server, there's no need for an Application Layer Gateway (ALG) on the path sniffing and spoofing DNS packets. bestie, that's the lowkey genius part 🤯 this decoupling was actually done by one of our users. he's outside our physical network and wants to talk directly over IPv6 wherever it's possible, without having to go through our central network equipment 🦋 his DNS queries go to our DNS64, and when he needs to reach an IPv4 destination, our central NAT64 gets involved. if some packets need translating, they find the translator through normal IPv6 routing, since the synthesized addresses carry our NAT64's prefix ✨ but for non-synthesized IPv6 addresses, the packets go straight to the destination 🚀 slay, decentralized and efficient 💅
4. General Experiences ✨
okay so bestie, the big question is: can you actually live and work on an IPv6-only network? 💅 The authors say yes! One of them had been on one for about a year and a half when they wrote this, and they had no major problems 🦋 They couldn't spot any practical difference in web browsing (HTTP and HTTPS) 🌐 Email, software upgrades, operating system services, lots of chat systems, and media streaming all worked fine too 🎀 Some Symbian mobile handsets ran every application on IPv6-only, and with Android, all the basic apps worked without problems 📱 The catch? To make that Android handset work on IPv6-only, the OS needed a small tweak so it could find IPv6-only DNS servers 🔧
BUT (and it's a big but 😭) it's not all sunshine. There's some pain involved, so IPv6-only is not suitable for everyone just yet 🥺 Switching IPv4 off breaks a bunch of stuff too, and some users in their environment actually left because they were missing a key feature they needed 💔 The issues fall into a few categories:
Bugs
Lowkey, a lot of this comes down to so few people having tried the software on an IPv6-only network 🙈 Some OS facilities support IPv6 on paper but have super annoying problems that only pop up in IPv6-only setups 🤦♀️
Lack of IPv6 Support
So many apps just don't support IPv6 at all 💀 Some are minor, old tools (like the Unix dict(1) command), some are major apps their users really needed (like Skype), and some are entire categories (many games have issues) 🎮 Good news though: as the experiment went on, they saw improvements in some areas, like gaming ✨
Protocol, Format, and Content Problems
Okay, this one is giving "IP addresses are everywhere and they're causing chaos" 😩 Lots of protocols carry IP addresses inside them, and sending those through a translator can cause problems 🫠 In their setup, the only ALG they used was the one for FTP [RFC6384] 🧚 They still saw protocol issues with IPv4 addresses though. Some instant messaging services didn't work because of it 💬 And some web pages refer to IPv4 address literals (plain IP addresses instead of host and domain names), which makes some links inaccessible on an IPv6-only network 🔗 The authors say this is easy to measure, but they only ran into it a couple of times while actually browsing 👀
Firewall Issues
Firewalls, bestie 😤 They saw a bunch of issues from firewalls that don't fully support IPv6 features. They didn't hit any MTU or fragmentation problems in their networks, but there's potential for trouble 🚧 IPv6 fragment header support isn't complete in all firewalls, and the NAT64 specifications call for using the fragment header even when fragmentation hasn't happened yet (for example, if an IPv4 packet that isn't a fragment doesn't have the Don't Fragment (DF) bit set) 🌸
In general, most issues come down to poor testing and missing IPv6 support in some apps 💅 IPv6 itself and NAT64 didn't cause any major problems once their setup and NAT64 software was stable ✨ Honestly, apart from some apps, the authors felt their translation experience reaching the IPv4 Internet was about the same as their past experiences with NAT44-based Internet access 🦋 Translation does mean losing end-to-end connectivity, but in practice, direct connectivity hadn't really been available to them on the IPv4 Internet for years anyway 🫶
Heads up: the experience can be different with a properly configured set of ALGs and workarounds, like proxies 🎀 Some of the problems they hit can be solved this way. For example, a problematic app can be set up to use a proxy that has both IPv4 and IPv6 access 🙌
5. Experiences with IPv6-Only Networking 🌈
The overall experience was what we just covered 💖 This section gets into specific issues with different operating systems, programming languages, applications, and appliances 🧚
5.1. Operating Systems
Even operating systems have some minor IPv6 glitches 😭 For example, in Linux, Router Advertisement (RA) information isn't automatically updated when the network changes while the computer is on 🙃 That means an unnecessary suspend/resume cycle is needed to get back to a proper state 💀 They also had issues with the rdnssd daemon, which isn't a default feature in Ubuntu and doesn't always seem to work reliably 🤷♀️ To fix this, they had to configure the network manager to use a specific server address 🔧 A later version of the Linux distribution fixed these problems, although some still remained ✨ For instance, in the latest Ubuntu Long-Term Support release (10.04), the network manager by default switched back to an available IPv4 wireless network even when a previously used IPv6-only network was around, and the IPv4 network had no global connectivity until a web-based login was completed 😤
In Mac OS X (Snow Leopard), the network manager had to be explicitly told not to expect IPv4 🍎 The really annoying part was that switching between an IPv6-only and an IPv4-only network meant changing these settings by hand, which made IPv6-only networks undesirable for Mac OS X users 🥲
Also, on Microsoft Windows 7, they ran into problems when relying on default, well-known DNS server addresses 🪟 Without manual configuration, the host couldn't use those DNS addresses, even though the system showed them as the current DNS server addresses 🙈
The latest versions of Android support IPv6 on the wireless LAN interface, but because of a lack of DNS discovery mechanisms, it didn't work on IPv6-only networks 📵 They fixed this, though, and their prototype phones work well now, even in an IPv6-only environment 🎉 The change, DNS Discovery Daemon (DDD), now exists as open source software 🫶 Interestingly, every app they tried so far seemed to work fine on IPv6-only connectivity, though there wasn't exhaustive testing, and they didn't try the known troublesome apps 👀
All of these operating systems (or their predecessors) have supported IPv6 for years now 🕰️ But these little glitches suggest they haven't been thoroughly tested on networks without IPv4 connectivity 😬 At the very least, their usability leaves something to be desired 💅
5.2. Programming Languages and APIs
For apps to support IPv6, they need access to the right APIs 🧑💻 Luckily, IPv6 is well supported by most of the commonly used APIs 🙌 Perl used to be the exception, with only partial IPv6 support up to version 5.14 (released May 14, 2011) 🐪 That version finally includes full IPv6 support, with the core libraries and older modules updated too ✨ With earlier versions of Perl, IPv6 socket support was available as an extension module, but installing it might not be possible without administrative rights 🔒 This also meant other networking core libraries (like FTP and SMTP) couldn't fully support IPv6, so lots of existing Perl programs that use networking may not work properly in an IPv6-only environment 😩
5.3. Instant Messaging and VoIP
By far, the biggest complaint from their group of users was that Skype stopped working 📞😭 In some environments, Skype could be made to work through a proxy configuration, and this was verified in their setting, but it wasn't used as a permanent solution 🫠 They also tested a number of instant messaging apps on an IPv6-only network with NAT64, and the results are in Table 1 📋 The versions used were the latest ones available in the summer of 2010 🌞
SYSTEM STATUS
Facebook on the web (http) OK
Facebook via a client (xmpp) OK
Jabber.org chat service (xmpp) OK
Gmail chat on the web (http) OK
Gmail chat via a client (xmpp) OK
Google Talk client NOT OK
AIM (AOL) NOT OK
ICQ (AOL) NOT OK
Skype NOT OK
MSN NOT OK
Webex NOT OK
Sametime OK (NOW)
Table 1. Instant Messaging Applications in an IPv6-Only NetworkPacket tracing showed that the issues in AIM, ICQ, and MSN seem to be related to passing literal IPv4 addresses in the protocol 🔍 It's still unknown whether configuration, proxies, or ALGs can fix this 🤔 The Google Talk client problem is that the software doesn't support IPv6 connections right now 🚫 They're continuing testing with more apps, and they've seen things change over time 🔄 For example, a new version of Sametime suddenly started working on IPv6-only networks, presumably because the new version is more careful about using DNS names instead of IPv4 addresses 🥹 One challenge in these tests is making sure they can tell IPv6 and NAT64 issues apart from other issues, like a generic problem on a given OS platform 🧐
Some of these problems are solvable though 💖 For instance, they used localhost as a proxy for Skype, then used SSH to tunnel to an external web proxy, which got around Skype's limitations with connecting to IPv6 destinations or even IPv6 proxies 🦋🔥
5.4. Gaming 🎮
Okay so next up is gaming, bestie, and I was lowkey nervous about this one 😭 We tried both web-based games and standalone games that have "network", "Internet", or "LAN" gaming modes. Here's the tea in Table 2 🍵
SYSTEM STATUS
Web-based (e.g., armorgames) OK
Runescape (on the web) NOT OK
Flat out 2 NOT OK
Battlefield NOT OK
Secondlife NOT OK
Guild Wars NOT OK
Age of Empires NOT OK
Star Wars: Empire at War NOT OK
Crysis NOT OK
Lord of the Rings: Conquest NOT OK
Rome Total War NOT OK
Lord of the Rings: Battle for Middle Earth 2 NOT OKTable 2. Gaming Applications in an IPv6-Only Network
Most web-based games worked well, which is giving exactly what our earlier general web experience promised 🌸 However, we did find one web-based game that failed to work, and that was Runescape 🥲 This one is a Java application that fails when it tries to do an HTTP GET request. Nobody knows exactly why yet, but the most likely theory is that the application itself uses an IPv4-literal ✨
The standalone games were way more discouraging, ngl 💀 Without exception, every single one failed to enable connections to ongoing games on the Internet, or even LAN-based connections to other computers on the same IPv6-only LAN segment. This is kind of a surprise, and the results still need further verification 🙈 The annoying part is that the games give no diagnostics about what they're doing, so it's hard to guess what's going on. It's possible their networking code uses older APIs that can't use IPv6 addresses [RFC4038]. The LAN part is even more surprising, because it would mean they can't use IPv4 link local connectivity, which should have been available to the devices. (IPv4 wasn't blocked. There were just no DHCP answers provided on IPv4.) 😤
While none of the standalone games we tested in the summer of 2010 were IPv6-capable, the situation got better during the experiment 🦋 For example, a popular online game, World of Warcraft, now has IPv6 support in its latest version. Some of the older games that have been re-released as open source (e.g., Quake) have also been patched to be IPv6-capable by the open source community. Iconic glow-up 👑
5.5. Music Services 🎧
Most of the web-based music services seem to work fine, presumably because they use TCP and HTTP as their transport 💖 The one notable exception is Spotify, which requires communication to specific IPv4 addresses 💔 A proxy configuration similar to the one we used for Skype makes it possible to use Spotify as well 🫶
5.6. Appliances 📷
There are also problems with different appliances, like webcams 🙃 Many of them don't support IPv6, so they won't work in an IPv6-only network. Also, not all firewalls support IPv6. And even when they do, they may still have issues with some aspects of IPv6, such as fragments. Not me getting the firewall plot twist 💅
Some of these issues are easy to solve when the appliance works as a server, which is what most webcams and our sensor gateway devices do ✨ We placed the appliance in the IPv4 part of the network (in this case, in private address space), added its name to the local DNS, and simply allowed devices from the IPv6-only network to reach it through NAT64. Main character problem-solving energy 🧚
5.7. Other Differences 🌈
One thing that gets simplified in an IPv6-only network is source address selection [RFC3484]. Since there's no IPv4 connectivity, the host only needs to consider its IPv6 source address. For global communications, there's typically just one possible source address, so it's very chill 😌
Some networks that advertise IPv6 addresses in their DNS records actually have some problems, ngl 🙈 For instance, a popular short URL forwarding service advertised a deprecated IPv4-compatible IPv6 address [RFC4291] in its AAAA record. That made it impossible to reach this site unless either IPv4 or NAT64 translation to an IPv4 destination was used. Not slay 💀
6. Experiences with NAT64 🦋
After fixing some initial bugs and stability issues, the NAT64 operation itself has been pretty problem-free 🫶 There have been no unexplained DNS problems or lost sessions. Apart from the specific applications mentioned above and IPv4 literals, the user experience has been in line with using the IPv4 Internet through a NAT44 device. The failures with those specific applications are clearly very different from the IPv4 experience, though 😭
The rest of this section covers our measurements on specific issues. These tests and measurements were performed during the year 2011, so they present a snapshot of the situation at that time. For more up-to-date measurement information, check out various online tools such as [HE-IPv6] 🔥
6.1. IPv4 Address Literals 🔢
While browsing in general works, IPv4 literals embedded in the HTML code may break some parts of web pages when using IPv6-only access 💀 This happens because DNS64 can't synthesize AAAA records for the literals, since the addresses aren't queried from the DNS. Luckily, IPv4 literals seem to be fairly rare, at least rare enough to get noticed during regular web surfing 🥳 The authors ran into this issue only a few times during the entire experiment. Only two of those cases had a practical impact: on YouTube, some of the third-party applications for downloading content didn't work, and one hotel's web page had a literal link to its reservation system 🏨
We tried to measure how likely it is to run into an IPv4 literal on the web. To do this, we took the top 1,000 and 10,000 web sites from the Alexa popular web site list. With the top 1,000 sites, 0.2% needed an IPv4 literal to render all components on their top page (e.g., images, videos, JavaScript, and Cascading Style Sheet (CSS) files). With the top 10,000 sites, this number goes up to 2% 📈
However, it isn't clear what conclusions we can draw from this 🤔 It's often the case that there are unresolvable or inaccessible components on a web page anyway, for various reasons. To understand the true impact, we would have to know how "important" a given page component was. Also, we didn't measure the number of links with IPv4 literals on these pages, and we didn't try to search the sites thoroughly for these literals either.
As noted, personal anecdotal evidence says IPv4 literals aren't a big problem. But clearly, cleaning the most important parts of the web of IPv4 literals would be useful 🧹 With tools such as the popular web site list, some user pressure, and cooperation from content providers, the most urgent part of the problem could hopefully be solved as a one-time effort 🫶 While IPv4 literals still exist on the web, using a suitable HTTP proxy (e.g., [ADD-LITERALS]) can help to cope with them 💖
6.2. Comparison of Web Access via NAT64 to Other Methods ⚖️
We also compared how well the web works behind a NAT64 versus IPv4-only and native IPv6 access. For this, we used wget to go through the same top web site lists described in Section 6.1, again downloading everything needed to render their front page. The tests were repeated, and the average failure rate was calculated over all of the runs. Separate tests were conducted with an IPv4-only network, an IPv6-only network, and an IPv6-only network with NAT64 🧪
When accessed with the IPv4-only network, our tests show that 1.9% of the sites experienced some sort of error or failure. The failure could be that the whole site wasn't accessible, or just that a single image (e.g., an advertisement banner) didn't load properly. It should also be noted that access through wget is somewhat different from a regular browser. Some web sites refuse to serve content to wget, and browsers typically have DNS heuristics to fill in "www." in front of a domain name where needed, among other things. In addition to missing advertisement banners, temporary routing glitches, and other mistakes, these differences also help explain the high baseline error rate in this test. It should also be noted that variations in wget configuration options produced very different results, but we believe the options we settled on bear the closest resemblance to real-world browsing 🤓
When we tried to access the same sites with native IPv6 (without NAT64), 96% of the sites failed to load correctly. This was expected, given that most of the Internet content isn't available on IPv6 💀 The few exceptions included, for instance, sites managed by Google 🔍
When the sites were accessed from the IPv6-only network via a NAT64 device, the failure rate went up to 2.1%. Most of these failures appear to be due to IPv4 address literals, and the increased failure rate matches the occurrence of IPv4 literals in the same set of top web sites. With the top 10,000 sites, the failure rate with NAT64 increases similarly to our test on IPv4 address literals 📊
7. Future Work 🔮
One important set of measurements is still left for future work 🫠 It would be useful to understand the effect of DNS64 and NAT64 on response time and end-to-end communication delays. Some users have anecdotal reports of slow web browsing response times, but we haven't been able to determine whether this was due to the IPv6-only network mechanisms or some other reason. Measurements on pure DNS response times and packet round-trip delays don't show a significant difference from a NAT44 environment. It would be especially interesting to measure delays in the context of dual-stack versus NAT64-based IPv6-only networking. When using dual-stack, broken IPv6 connectivity can be repaired by falling back to IPv4 use. With NAT64, this isn't always possible, as discussed in Section 3.2 ⚡
Also, more programs, especially VoIP and Peer-to-Peer (P2P) applications, should be tested with NAT64 📞 In addition, tunneling and mobility protocols should be tested, and Virtual Private Network (VPN) protocols and applications especially would deserve more thorough investigation 🌸
8. Conclusions and Recommendations ✨
okay bestie, let's wrap this thing up 🎀 the main takeaway is that IPv6-only networking is totally doable 💅 for a big chunk of apps there are no downsides, or they're so tiny they don't matter. we couldn't find any real difference in web browsing, no cap 🌸 and IPv6 (whether it's dual-stack or IPv6-only) comes with built-in perks like direct end-to-end connectivity. for us, that meant we could reach devices on a home network from anywhere on the (IPv6) Internet 🦋 but ngl there are also some issues, like apps that don't support IPv6 yet or bugs hiding in parts of the code nobody tested 💀
so our experience confirms that dual stack should still be the recommended model for general purpose networking right now 🫶 IPv6-only networking is giving early adopters and highly controlled networks 👑 one example is a mobile network where the operator picks the handsets. on some handsets we tested, we literally could not see any functional difference between IPv4 and IPv6 ✨
our recommendations are for the present time, okay? 🕰️ with effort and time, the deployment barriers can get removed and IPv6-only networking can become applicable in every networking situation 🌈
some improvements are already happening, with new products and extra IPv6 support 🚀 we expect the handset market to have way more IPv6-capable devices soon 📱 but some changes need the community to put in extra effort 💪 we've identified a bunch of actions that should be taken to improve IPv6-only networking. here they are:
DNS Discovery 🧭
The state of DNS discovery is still one of the biggest barriers to easy IPv6-only adoption 😭 since DNS discovery isn't a problem in dual-stack networking, there hasn't been enough effort put into testing and deploying the needed components. for example, it would be super useful if RA-based DNS discovery was a standard feature and not just an option in Linux distributions 🐧 we're hoping the recent IETF standardization of RA-based DNS discovery helps make that happen 🙏 other operating systems face similar problems too. the authors believe that, at this time, prudent operational practices call for maximizing the number of offered automatic configuration mechanisms on the network side 🎯 it might also be helpful for an IETF document to give guidance on operating DNS in IPv6-only networks 📝
Network Managers 🛠️
other key software pieces are the network management and attachment tools in operating systems. these tools generally have the required functionality, but they don't always seem to have been tested very much on IPv6, let alone IPv6-only networks 🙃 more work is required here 💖
Firewalls 🔥
more work is needed to make sure IPv6 is supported in equal manner across different firewall products 💅
Application Support 📲
by far the most important action, at least for our group of users, would be getting key apps (like instant messaging, VoIP apps, and games) to a state where they can easily run on IPv6-only networks and behind a NAT64 🎮 to make that happen, application programmers should use IP-version-agnostic APIs so apps automatically use IPv4 or IPv6 depending on what's available 🪄 in some cases, it may also be necessary to add support for new types of ALGs 🧚
IPv4 Literals 🔢
the web should be cleaned of IPv4 literals. also, IPv4 literals should be avoided in application protocol signaling messages 🧹
Measurements and Analysis 📊
it's also important to keep testing, measuring, and analyzing which Internet technologies work on IPv6-only networks, to what extent, at what speed, and where the remaining problems are 🔍
Guidelines 📖
it's also useful to provide guidance for network administrators and users on how to turn on IPv6-only networking 🎀
as you can see from the list above, there are only minor things that can be done through standardization 🤷♀️ most of the effort is practical and centers around improving various implementations 🛠️💜
9. Security Considerations 🔐
okay this part is SERIOUS, so pay attention 🚨 by itself, using IPv6 instead of IPv4 doesn't make a big security difference 🙅♀️ the main security requirement is that network security devices need to be able to deal with IPv6 in these networks. this is already required in all dual-stack networks 😤 as noted, it's important, for example, to make sure firewall capabilities are there 🧱 security considerations for NAT64 and DNS64 are discussed in [RFC6146] and [RFC6147] 📚
in our experience, lots of the critical security functions in a network end up on the dual-stack part of the network anyway 🥹 for example, our mail servers obviously still have to be able to talk to both the IPv4 and IPv6 Internet 📬 so they, and the spam and filtering components that go with them, aren't in the IPv6-only part of the network 🛡️
10. References 📚
10.1. Normative References 🌟
- [RFC2663]: Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999.
- [RFC3484]: Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003.
- [RFC3736]: Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004.
- [RFC4213]: Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005.
- [RFC6106]: Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010.
10.2. Informative References 💜
- [RFC4038]: Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005.
- [RFC4291]: Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006.
- [RFC4861]: Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007.
- [RFC4966]: Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007.
- [RFC6052]: Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010.
- [RFC6144]: Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011.
- [RFC6145]: Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011.
- [RFC6146]: Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011.
- [RFC6147]: Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011.
- [RFC6384]: van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011.
- [ADD-LITERALS]: Wing, D., "Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators", Work in Progress, March 2010.
- [HE-IPv6]: Hurricane Electric, "Global IPv6 Deployment Progress Report", February 2012, <http://bgp.he.net/ipv6-progress-report.cgi>.
Appendix A. Acknowledgments 🫶
the authors would like to thank the many people who've engaged in discussions around this topic 💬 especially the folks who helped build some of the new tools used in our network, our users who were brave enough to go where only a few had dared before 🚀, and everyone who helped us in this effort 🌷 in particular, we'd like to thank Martti Kuparinen, Tero Kauppinen, Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and Cameron Byrne 👑 also, Marcelo Braun, Iljitsch van Beijnum, Miika Komu, and Jouni Korhonen gave useful discussion and comments on the document 💖
Authors' Addresses 📮
Jari Arkko Ericsson Jorvas 02420 Finland
EMail: jari.arkko@piuha.net
Ari Keranen Ericsson Jorvas 02420 Finland
EMail: ari.keranen@ericsson.com
📦 where this page comes from
- ietf: rfc6586 2012-04
- 💖 girlified by claude-haiku-5-5 on : a language model's rewrite of the original, under its terms