Roku Doesn’t Support IPv6
DingleBog3899 (via John Gruber):
Our tribal network started out IPv6, but soon learned we had to somehow support IPv4 only traffic. It took almost 11 months in order to get a small amount of IPv4 addresses allocated for this use. In fact there were only enough addresses to cover maybe 1% of population. So we were forced to create a very expensive proxy/translation server in order to support this traffic.
We learned a very expensive lesson. 71% of the IPv4 traffic we were supporting was from ROKU devices. 9% coming from DishNetwork & DirectTV satellite tuners, 11% from HomeSecurity cameras and systems, and remaining 9% we replaced extremely outdated Point of Sale(POS) equipment. So we cut ROKU some slack three years ago by spending a little over $300k just to support their devices.
[…]
Now if ROKU cannot be proactive at keeping up with connectivity standards they are going to be wiped out by their own complacency. Judging by the growing number of offers to replace their devices for free their competitors are already proactively exploiting that complacency.
I suppose I’m lucky that, as an end user, IPv6 so far isn’t something I’ve had to think about. It’s kind of like Y2K in that I know there’s been a lot of work going on, but it’s been mostly invisible. I don’t actually know which of my devices and apps have been updated.
Geoff Huston (in February 2022, via Tim Bray):
I bet that nobody believed in 1992 that thirty years later we’d still be discussing the state of the transition to IPv6! In 1992, we were discussing what to do about the forthcoming ‘address crunch’ in IPv4 and, having come to terms with the inevitable prospect that the silicon industry was going to outpace the capacity of the IPv4 address pool in a couple of years, we needed to do something quickly. We decided to adopt a new protocol, IP version 6, a couple of years later, and in December 1995 the IETF published RFC 1883, the specification of IPv6.
There were many views as to how long the transition from IPv4 to IPv6 would take, from an optimistic six-month rapid cutover to a hopelessly pessimistic view of a protracted ten-year transition. If there was a prevalent view at the time, it was that the transition would take a further five years or so. But don’t forget that this was in the lead up to the Internet bubble of 2000, and anything that was going to happen five years from now was shelved as a ‘tomorrow’ problem while we toiled away on adding more carriage capacity to the network, fixing the myriad of issues with routing, and making dial-up modem access work!
While this was a pressing issue in 1992, four years later in 1996 there was no longer any particular sense of urgency about the transition to IPv6. Why not? There are four major reasons for the shift in attitude.
Google (via Hacker News):
Google collects statistics about IPv6 adoption in the Internet on an ongoing basis. We hope that publishing this information will help Internet providers, website owners, and policy makers as the industry rolls out IPv6.
It’s around 38% right now.
Previously:
- Linode Price Increases
- App Store APIs and Testing
- The Monkey and the Apple
- North America Out of New IPv4 Addresses
8 Comments RSS · Twitter · Mastodon
It’s probably part of the problem that American consumers didn’t have to worry about this (due to a large supply of IPv4 addresses), because it means US companies don’t care about it much, either. Yet the rest of the world relies on relies on these companies.
In my country there are already many IPv6-only (well, so called Dual Stack lite) home connections, so many people have had to pay extra for a proper Dual Stack so certain things like online multiplayer and VPN connections work. But it’s finally getting better.
Wow, it's amazing to see how much impact a single device like ROKU can have on a network's infrastructure. It's concerning to think that a lack of proactive measures on ROKU's part could potentially lead to their demise. It's clear that as technology advances, companies need to be willing to adapt and update their products accordingly. However, I can't help but wonder if there are any alternatives to the expensive proxy/translation server that was created to support IPv4 traffic. Have you considered implementing NAT (Network Address Translation) or DHCP (Dynamic Host Configuration Protocol) to help manage the limited IPv4 addresses? I'm curious to hear your thoughts on this.
A large part of the problem is because instead of solving one problem (address space limitations) and leaving other problems to the future(NATing etc), they solved them all in one go, making it difficult to adopt instead of making adoption easier.
And that's from someone who likes IPv6 and sets it up wherever they go.
@Michael Is there any reason your websites aren't IPv6? For Dreamhost I note this page, although there's a caveat about Dreampress. In general, if your (web) applications don't use IP addresses for access control and/or you know they also support IPv6, it should be fine. And in general if your servers/VPss support v6, then the right thing to do is just to turn it on and set up the corresponding AAAA; most servers default bind to :: as well as 0.0.0.0 (sometimes on the same socket). You may or may not need to open up an entry in an IPv6 firewall. In general server-side is easy, and you should, because that helps out clients that would otherwise have to get to you through CGNAT.
But you're right, v4 is still the lowest common denominator, so not having v6 is not critical, except to geeks who just love the return of the pure end-to-end network. And, in truth, other solutions (Headscale/Tailscale, Zerotier, InnerNet, CJDNS, Tinc, Cloudflare Tunnel plus Warp, FRP, many, many others) provide an allusion of IPv6 that is in many ways more compelling than the real thing when so much of the world is IPv4+NAT only today. (I share the author's recommendation of Cloudflare: it may be centralised and the server may be closed and you might not have total confidence in Cloudflare's privacy practices, but it's hard to argue with the speeds and the results.) When I moved back from A&A, a UK ISP with a superb stand on Internet connectivity and IPv6, but on VDSL 80/20 Mbps, to Virgin Media, the only cableco in the UK and the only "ultrafast" connectivity in my area, with acceptable speeds in the modern era but with absolutely no IPv6 whatsoever, I made the regrettable decision to forsake IPv6 and instead use Cloudflare. Convenient end-to-end connectivity between my own devices is more important to me than v6 connectivity to the public Internet as such, because if I want that on the IPv4-only network, I need a IPv6 tunnel, like the (very excellent) Hurricane Electric Free IPv6 Tunnel Broker which, although it works, will take a few hundred megabits off my downstream speeds and add latency. If you want to learn, and try, definitely give it a go. But, in the end, IPv6 will be at its most beautiful and the network will flourish only when enough people are on it to make its availability a given on any connection you use. At that point, set down your VPNs, deploy letsencrypt certificates on all your web servers, configure the names of all your hosts in the public DNS, configure your firewall to allow all traffic on all your trusted hosts, and let a million flowers bloom. :)
@Sebby I thought this wasn’t relevant to my sites because they aren’t using unique IPs, anyway. Is there an advantage to adding a unique IPv6 when people access via the name?
I do have internal v4 addresses for mail and database servers, but that shouldn’t affect anyone reading the sites.
@Michael Whether you expose internal machines is up to you, if you can ensure safe and authenticated access or have a firewall that will permit you to restrict access then you might use that, but if your internal IPv4 is working fine and you can jump to them already then it's no big deal to leave them alone. Web hosters can share IP addresses v4 and v6, but there's clearly a bigger reason to share v4 than v6, and Dreamhost are probably just giving you the benefit of free unique v6 simply because they can; it costs nothing and you can rely on the IP address to e.g. differentiate virtual hosts. The reason your external presence should have v6 is simply so your potential clients need not go through CGNAT at their end to get to your v4 address, which conceals your visitor's IP from you, requires state on the NAT box and might reduce performance. If you're low-traffic and you don't care who's connecting it might not make much of a difference in the here and now, but you'd ideally like to anticipate the day when your visitor only has v6, and their v4 is either non-existent or a translator, so that there's a clear gain from connecting on v6 (starting, most probably, with mobile networks). So make your external servers--those that have public v4 addresses already--accessible on v6 as well, if you can. Web, mail (MX), and DNS are probably the big ones.
