Roku devices don't support IPv6 in 2023 and it's costing ISPs | Hacker News Reader

Roku devices don't support IPv6 in 2023 and it's costing ISPs

community.roku.com

146 pointsrobbiet480228 comments

Who the hell is giving their Roku a public IP? How is this remotely a problem? This is 100% not the fault of Roku, and 100% the fault of the ISP. The ISP should have an IPv6 to IPv4 gateway built into their modem/router. You have a WAN port that is IPv6 and an LAN port that IPv4.

IPv6 for local networks, makes no sense is completely unnecessary, and is a hill I will die on. IPv4 is here to stay.

The ISP said they got only a limited set of IPv4 addresses, those are assigned to their CGNAT gateways. Which are expensive, especially for an Indian Reservation, not the deep pockets of some MSP.

The users are behind CG-NAT.

But instead of using IPv6 which is cheaper (no need to maintain CG-NAT, translation devices, or deal with traffic that is being routed way more expensively) the Roku devices are only streaming over IPv4.

Each new user that adds an IPv4 only device adds additional load the CG-NAT and additional capacity will need to be provisioned. That is an additional expense and burden.

Most of my traffic at my house (on Comcast) is over IPv6, because most if not all streaming services now support IPv6 for content delivery, so the small amount of data that may need to go over IPv4 when the majority can go over IPv6 reduces the load on IPv4.

Why does the IPv4 address need to be publicly exposed outside of a customer’s LAN? I thought you could set up NAT on a router to translate local IPv4 addresses to something IPv6 that is exposed publicly.

Is this simply bad planning from the ISP where they didn’t handle it correctly? Or is there something I’m not understanding about NAT?

I think in an ideal world all devices would be using IPv6. But I thought it would be common knowledge among network engineers that many devices still use IPv4, so you have to either handle it somehow or tell your customers that some of their devices simply won’t work.

Because the IP address the Roku is trying to reach is an IPv4 address. You can't just translate that to IPv6 and say "good luck little packet".

If you translate at the customers router that's fine and all, but now you have an IPv4 packet in an IPv6 packet, that IPv6 packet needs to get routed to a device that knows how to then turn it back into an IPv4 packet so that it can then go travel on the open internet like the electrons intended...

Once that IPv4 response come back, it needs to get translated back to IPv6, sent to the customers edge, which translates it back from IPv6 to IPv4 to send to the Roku device.

Oh, what a mess. I don’t like that at all.

I was assuming that there was some way to translate the IPv4 address of the server to an IPv6 one and process it that way, putting the burden of supporting IPv6 on the server side. I had no idea that Roku would actually need to be exposing an IPv4 server to handle these requests.

That makes sense then that the ISP would need some number of IPv4 addresses that it could use to communicate with IPv4 servers on behalf of IPv4 client devices.

Shame on Roku for perpetuating this problem.

The more usual reason why devices would be making an IPv4 request despite having an IPv6-supporting connection is precisely because the server doesn't support IPv6 - either the network it's on doesn't support it, or it's not configured for it, or more rarely the software on the other end doesn't have IPv6 support. The request can't just be translated into an IPv6 one because there's no way of knowing that the server even understands that, let alone what its associated IPv6 address is.

CG-NAT (NATing centrally at the ISP's internet edge) is cheaper/simpler than something like 464xlat (NATing v4 locally over v6) since you can do the former on 2 boxes instead of 20,000. That said the 2nd option is much cooler :).

464XLAT still requires IPv4 boxes on the edge to translate IPv6 traffic back to IPv4. Whether that is two boxes or 20,000, the same is true for other CG-NAT solutions. Someone somewhere is bearing the cost of translating.

Usually you need a special box at the consumer side to do 464XLAT, it's not something you can just ask your customer's Netgear to do and it's usually more expensive if you want to provide it as the customer's rented router. CG-NAT however looks completely normal to all gear (other than the particular numbers assigned) except the 2 edge boxes. It's the ultimate cost saving kludge.

Most modern OSes (I know for a fact Android, iOS, and Windows) support automatically doing the 4->6 translation on their side (as a matter of fact, some cellular networks in the US are ipv6 only).

I'm unsure if consumer routers would pass on the appropriate RA flag to tell the OS they need to do this in their default configuration however.

Well the devices that support 464xlat already support IPv6 by definition. CG-NAT/464XLAT+Client NAT at the gateway is for the devices like the Rokus that don't support IPv6 at all.

NAT64 doesn't work if the connection is made to a hardcoded IP(v4) address rather than DNS entry, and that's way more common than you'd think! Thus why 464XLAT and similar exist.

Absolutely but CG-NAT would be NAT444 (i.e. double NAT to dual stack) not NAT64. I mean they probably did try NAT64 based on the description of the botched 1st attempt but CG-NAT would have negated the need for NAT64 in the first place. Putting a x464 CLAT that can gateway/NAT the local network everywhere would definitely achieve the same functional goal though, just more ISP devices.

Realistically they are already running a large scale NAT device anyways, otherwise the v6 only clients wouldn't be able to reach v4 only internet services (hello HN server), and if they had planned to CG-NAT from the start it probably could have all been done on the same pair of internet edge routers for much less than 300k additional expense.

As the article says, the Roku traffic is the overwhelming majority of that ipv4 traffic.

HN and similar mostly-text websites would barely show up on the statistics.

NAT scales in both dimensions, you're just as likely to need a larger box for a larger connection table as you are a larger bandwidth.

It's also about ports. If I have 10 Gbps of IPv4 flow but my devices are licensed for and operate on 1 Gbps, I need to license 10 1 Gbps ports.

When I was last working at an ISP, various CG-NAT solutions charged not just based on the connection table, but also there was various licensing for various slide-in cards.

If the ISP is having to buy additional hardware/additional ports on upstream providers just to power their CG-NAT that is an additional cost.

If the POP where you have your CG-NAT doesn't have more bandwidth available you end up running your ports hot... so now you either need to rent a new location, get your connectivity up there and start figuring out how to route the traffic.

It's not as simple, and it all costs copious amounts of money. Especially if your IPv6 can more easily be distributed across multiple POP's with multiple forms of connectivity and traffic shaped using BGP or other solutions thereby reducing the load on a single upstream port.

At some point you also need more IPv4-addresses. There are only 65535 ports to be mapped.

At some point but remember it's not "after 65535 connections per IP" it's "after 65535 connections of the same type to the same IP per IP". That is to saythese NATs where 156.78.92.154 is a single public address on the NATing box:

  156.78.92.154:6781<->8.8.8.8:53 UDP
  156.78.92.154:6781<->8.8.8.8:53 TCP
  156.78.92.154:6781<->8.8.4.4:53 TCP
  156.78.92.154:6781<->8.8.4.4:53 UDP

Can all exist simultaneously even though only 1 port is in use and we haven't even started changing the destination IP or ports yet (e.g. 80 and 443 as the destination won't double count and thousands of web servers on different addresses can be accessed via the same source port).

With CG-NAT you can usually support somewhere around 30k customers on the free /24 you get from ARIN for having only IPv6 and needing space to translate in (for new orgs like new ISPs this is assigned immediately out of a reserved block, bypassing the waitlist for existing orgs trying to get free reclaimed space).

> IPv6 for local networks, makes no sense is completely unnecessary, and is a hill I will die on. IPv4 is here to stay.

Why would you make everything gratuitously complicated by having two separate forms of addressing? All that IPv4 gains you is new and exciting ways to mess up your networking. Just give every device a normal public address (of course you probably want to firewall off inbound traffic from the WAN to the LAN, but that's got nothing to do with addresses) and have a normal network rather than some bizzare frankenstein mashup.

Why would I want any of my devices on my network to have a publicly route-able address?

> Why would you make everything gratuitously complicated by having two separate forms of addressing?

How is IPv6 itself not "gratuitously complicated". You think I am going to remember the IP of my firewall, my network switch, if it is that mess of characters that is an IPv6 address? I can easily recall 10.10.10.1 is my gateway, or that 192.168.1.1 is my gateway. You think instead setting up local DNS server and domain so I can do myrouter.lan is somehow "less complicated"?

Hard pass.

fe80::1 is your gateway, fe80::2 can be your switch, fe80::blah can be your server. Let the device automatically get it's temporary public address it uses when talking through fe80::1, you shouldn't really need to know it or use it. If you really do feel free to use DHCPv6 or a static SLAAC offset or mDNS but you're just making more work for yourself if it's a home environment.

I felt this way until I learned that the RFC1918s we all love (10. 192.168. etc.) have a nice v6 equivalent: fd80::1 fd80::2 ... etc.

https://www.ripe.net/participate/member-support/lir-basics/i...

>Why would I want publically routable addresses

Hate to break it to you but that is how the internet was intended to work for end-users. Firewalls are cheap and easy to install :)

> Why would I want any of my devices on my network to have a publicly route-able address?

So that your addressing works normally, and you don't have to deal with the same machine having two different addresses depending where you are (e.g. my photo server's address is the same whether I'm travelling or at home). Even if you only ever access your home network from outside via a VPN (which may well be a good idea), having globally unique addresses eliminates a whole bunch of possible issues - no more weirdness because the coffee shop you're in picked the same private subnet as you did.

> How is IPv6 itself not "gratuitously complicated".

IPv6 is needed for the public internet, there are just too many hosts for anything else. So you either learn IPv6 or IPv6 + another similar, but somewhat different thing.

My internal v6 addressing is as such:

fd65:<16-bit-mnemonic>:<vlan-id>::/56

The 16-bit-mnemonic is something memorable to me (e.g. b37a:7357 would be addressable l33tsp34k for "beta test" - that's not the one I use :P). In this case, VLAN 10 would be in the fd65:b37a:7357:10::/56. Gateway for it is fd65:b37a:7357:10::1.

It's really not harder than IPv4 for these cases.

Servers and services are assigned static IPs either via DHCPv6 or directly on the boxes (or both as I kinda use the DHCP table as a poor man's IPAM). Other devices internal IPs and globally routable IPs are assigned through SLAAC with privacy extensions where available.

The main reason would be to do p2p without hacks / servers.

Why are you so militant against the idea?

Sunk cost fallacy.

Why would you need a DNS server? That's what mDNS is for.

Some people might have more than one subnet. Or road-warrior VPN and VPN-ing in. It is nice when your networks name resolution works, even if you are outside your network.

If you have multiple subnets, you almost certainly have an advanced enough router that it supports mDNS forwarding. There's no reason why it can't work across a VPN either.

mDNS forwarding doesn't work on Tailscale :(

mDNS has some downsides that can be important for some. For instance, the fact that you can more easily set the same host name on multiple machines, or the fact that it uses a lot of bandwidth.

> you probably want to firewall off inbound traffic from the WAN to the LAN

But all modem/routers are doing it anyway, they might as well do that on ipv6.

Effectively all router appliances (at home and soho level) are linux appliances, and the firewall is built into the kernel (and in use anyway).

Sorry I do not trust the likes of home router vendors to implement a linux firewall correctly

While people may say "NAT is Not security", it is in fact a layer (ahd huge one) in the security onion, that ipV6 is likely going to increase drastically the amount of ransomware and other malware on the public internet simply because that NAT layer is gone

I remember what it was like when lots more home computers were routable from the public Internet, because having a NAT router between them and there wasn't a nearly-100%-adoption thing yet. In fact, I worked at an ISP (dial-up and DSL) in that era.

It was indeed a shit-show. Adding a NATting router to those set-ups instantly increased their security tremendously. Sure you could use a proper firewall, but the router w/NAT Just Works.

I cant wait until all the printers, and webcams all showup on the public internet again....

Portscanning for smb shares and webcams, LOL. Good times. Found entire offices routing their whole network publicly, back then, shared network drives and printers right there for use by anyone who stumbled on them. It was nuts. Worms spread like crazy. It was a real mess, and that's with the Internet being way the fuck friendlier than it is now.

What's ironic is that the IPv6 people will tell you you can do all of that with IPv6. Which is true, but if we NEED TO CHANGE because we're out of addresses then why go to something that doesn't use the address space?

The problem IPv6 seeks to address has mostly been engineered around for now.

> The problem IPv6 seeks to address has mostly been engineered around for now.

For now is the operative phrase. These are band-aids to keep IPv4 running, but they won't be effective forever.

This is one of the worst takes I've seen in this thread.

NAT is only kind of a firewall and there have been plenty of terrible router firmwares out there that have lead people to subvert it (UPNP being one of the most problematic).

If you in your other thread don't trust the ISP device, then don't trust NAT on your ISP device either. Quite often the ISP can have their modem route traffic from their internal 10 net to your internal network if they so choose to.

Instead IPv4, or IPv6 setup to drop NEW/SYN connections to your devices via a router that you provide.

>If you in your other thread don't trust the ISP device, then don't trust NAT on your ISP device either

There is no logic there. firewall configuration is much harder to secure than NAT configuration.

> There is no logic there. firewall configuration is much harder to secure than NAT configuration.

Disagree. Just the XML parsing logic required for uPnP alone is more complex than a basic firewall implementation.

uPnP seems a distraction from the topic. It's not necessary for networking to network -- my LAN intentionally does not support it at all. It is necessary for certain use cases, of course, but it's not mandatory in a network in the general case.

It's necessary for feature parity with IPv6 (or, equivalently, with the 2000s-era Internet). Even if you don't use uPnP, the amount of complex protocol parsing necessary to support/work around NAT (e.g. SIP is particularly tricky) is a larger attack surface than a full IPv6 stack.

> that ipV6 is likely going to increase drastically the amount of ransomware and other malware on the public internet simply because that NAT layer is gone

malware has connected outwards to c&c servers for more than 20 years

> Sorry I do not trust the likes of home router vendors to implement a linux firewall correctly

Neither do I, but that's a fixable situation. Get an appliance router that lets you put DD-WRT (or similar) on it. Or use a computer instead of an appliance and set it up any way you like.

I am by trade a network administrator, and I run enterprise gear in my home.

I am not running a home router or dd-wrt. But I am not a typlical user going down to best buy to pick up the latest Belkin or Asus wireless AP / router combo they have on sale for $99 and hooking it up to my internet using default "wizard" settings from the mobile app...

Nor I am I trusting Comcast, or ATT to configure their residental rented equipment properly with proper firewall rules

My comment is not about me, I have enterprise grade nextgen firewalls that are $$

My comment is about Grandma that calls up comcast to have them set it all up, or Sally that is going into best buy for the "Geek Squad" so hook her up...

If I’m following your logic, you’re saying you trust tplink etc to keep Grandma safe, but only for IPv4, and not IPv6? Why?

I am not trusting them, behind a ipv4 nat inbound connections are by default inaccessible

ipv6 most configuration end up with all devices publically routable and must have a firewall deny policy inplace to block inbound connection

Shodan is filled with people with misconfigured ipv4 routers that end up with all kinds of device that should not be on the public internet (webcams, printers etc) out there for anyone to connect to. This requires a user to actively do something on the device (most likely following a bad online tutorial) in order to port something though the NAT.

with IPv6 this problem will get FAR FAR FAR FAR worse.

> I am not trusting them, behind a ipv4 nat inbound connections are by default inaccessible

No they're not. They're by default obscured, but anyone can guess your internal IP and send a packet for it, and the router will happily forward it on unless its firewalling tells it not to. And that's without even even getting into all the extra attack surface opened up by legitimate and not-so-legitimate workarounds for the issues NAT causes.

Large ISPs like Comcast already have enormous IPv6 networks, and have appropriate, default-deny firewall configurations for them.

I'm only familiar with the largest ISPs in Britain, but they also have default-deny configurations on the IPv6 routers they supply. Obviously.

> Grandma / Sally

Try avoiding the casual ageism and sexism.

>Try avoiding the casual ageism and sexism.

Try not to find offense in all things, feel free to refer to my comment thread from the other day about offense being a you problem not a me problem ;)

Finally some sense. There are so many senseless IPv4 shills here. IPv6 always works, never had a problem with it.

Just switch to it alrready.

I'll switch when IPv4 stops working. Until then, I have no reason to switch.

> It's costing ISPs

I hate my ISP so this is actually a feature. If they add an IPv4 surcharge to my bill then I'll reconsider.

> I'll switch when IPv4 stops working. Until then, I have no reason to switch.

IPv4 has stopped working for a lot of people already, especially if they're not with a fancy-pants ISP with lots of legacy IPv4 addresses already 'in the bank'. From another discussion:

> I've actually run into this [CG NAT] helping a friend host a game server on their residential internet in a more rural part of Texas. They had to call their ISP and request a static IP address at an extra cost of something like $5/mo.

* https://news.ycombinator.com/item?id=35046929

IPv4 is also not working for the Indian reservation mentioned in the article: they had to spend >$200K to support these Roku devices.

Sure, I get that. But it's their problem, not my problem. I'll only switch when it becomes my problem.

So, because I don't want to change something that works and whose predictions of demise have been grossly overstated by decades I'm a shill?

"Just switch to it." Sure, pal, You pay all of the transition costs for everyone and you got a deal.

Not everything needs or should have a public IP address much less a bunch of IOT garbage. I suspect you, like everyone else who just says, whY aReNt We On IpV6 yEt??!11 imagine that most people's security practices are like yours and most people's ability to maintain software and security practices are like yours.

They are not.

I'm holding out for a modern address space extension conceived this century that doesn't suck, or at least a naming convention that doesn't suck. But no one will change until it's really needed and "hack" that improve the Internet, even if by accident, like NAT, can't fix it.

> Sure, pal, You pay all of the transition costs for everyone and you got a deal

Except at this point the costs are reversed - IPv4 costs more than IPv6. Just look at the article we're commenting on - supporting IPv4 clients is costing them a lot more. At the same time more and more cloud hosts are charging more for IPv4. In 2023 it's supporting IPv4 that costs more, not IPv6.

> Why would you make everything gratuitously complicated by having two separate forms of addressing?

If it ain't broke, don't fix it? If IPv6 brings no benefit to my LAN, why should I spend all the effort needed to shift it to IPv6? I can just make the connection to the internet IPv6 and leave everything else alone.

Although I have additional friction in my case, in that I have numerous devices that are IPv4-only. So no matter what, I'd have to at least have one LAN segment that is IPv4.

Because that's not the way TCP was designed in the first place. Instead you're used to hack on top of hack to make IPv4 not explode in a ball of flame there are far more billions of end points than IP addresses.

The thing is you really don't realize how shit your network experiences are because of this. Everyone is just attempting to tunnel more services via HTTP/HTTPS and the particular fun problems that entails rather than having byzantine hacks built in to their NAT routers. IPv4 is no longer fit for purpose.

> to make IPv4 not explode in a ball of flame there are far more billions of end points than IP addresses.

But in my LAN, there is no IP address exhaustion. I have orders of magnitude more IP addresses than I'll ever use. IP address exhaustion applies to the internet at large. I'm not talking about that.

In the internet at large, IPv6 has to happen. In my LAN, I don't see a need for it. I can route between the IPv4 endpoints in my LAN and the IPv6 endpoints on the internet.

And because I have IPv4-only hardware on my LAN, I need an IPv4 segment to support it at the very least. So why not keep the entire LAN IPv4?

> But in my LAN, there is no IP address exhaustion. I have orders of magnitude more IP addresses than I'll ever use. IP address exhaustion applies to the internet at large. I'm not talking about that.

As long as you never VPN into or out of another network whose administrator thought the same thing. But yes.

> And because I have IPv4-only hardware on my LAN, I need an IPv4 segment to support it at the very least. So why not keep the entire LAN IPv4?

v6 uplink is going to increasingly be cheaper and/or faster than v4 uplink (as with the issue in the article), so presumably you'll want to run v6 on your LAN at least for the devices you game/stream from (and sooner or later there will be v6-only services that you want to connect to). I would think that any device not supporting IPv6 is so obsolete/unsupported as to be dangerous to connect to the internet, so you already need to deal with having two distinct segments on your LAN. But sure, if you've got good v4 uplink at a reasonable cost then no need to migrate yet.

If I don't realize how shit it is, I don't think it's a shit experience. I don't care how it was designed and what you call a "byzantine hack" I call a feature that saved the Internet about 20-25 years ago. Having everyone on a public addressable host is not good. (Yes, I know you can do this on IPv6, but then it's like you're just applying Byzantine hacks to get the security feature you already had on IPv4.)

> Having everyone on a public addressable host is not good.

We had every host on an IPv4 address at the University of Washington back before 1998 and NAT was actually banned by the CAC Department since they billed by number of nodes on the network, so NAT was a way to cheat their billing system.

I learned quite a lot of internet security from having 1998-era Unix servers hanging directly off onto the internet with no firewall or NAT.

A pipe dream, but the best case seems to be a total standardization on v6

Congratulations on completely failing to understand how CGNAT loads work & their costs, and jumping to a wildly incorrect understanding of the situation

Yeah, and that's currently the top comment.

Which leads me to believe that the main barrier to IPV6 is just that people don't want to re-learn anything.

> the main barrier to IPV6 is just that people don't want to re-learn anything.

I disagree, actually. I think the main barrier is that networking folks have been pretty bad at explaining this to non-networking folks. IPv6 isn't exactly simple to understand.

I'm a reasonably network-savvy guy, and I'm sure that I understand less about IPv6 than I think I do. I just don't know what parts I'm not understanding properly, and what parts I just don't know about.

It's pretty hard to find good explanations of this stuff that aren't aimed at networking experts.

It's terrible isn't it. I'm not a network specialist yet have a reasonable enough understanding of ipv4, nat etc that I think my home network is, at least ok. Can look at ip addresses in logs and know what machines most of them are etc.

I get tired of this "I'm an expert you're an idiot" trope that comes up about it. Here on this damn website you have people who hack kernel, people who manage massive databases, people who hack front end stuff that scares me, experts in functional programming, language designers, fpga designers... In short it's very, verry flipping technically adept crowd. You didn't reach them.

Networking "experts" who want to blame everyone else for a lack of understanding need to look in the damn mirror and ask themselves "How did we fail so very, very hard at explaining this stuff?" "Why are we not able to provide a link to an article with an estimate of time taken for everything you need to know about ipv6 to use it exclusively?" "Why don't we want to make this easy for everyone?" "Why can't we be minimally polite?"

I'm an expert in being a jerk on occasion and this occasion the "Everybody else is stupid and lazy because they don't understand it's not us at all" trope is definitely being a jerk. And I'm jerk enough to point it out.

The hostility is what I think is more damaging than anything else. When people have an objection to something that is resulting from them misunderstanding the thing, telling them they're stupid, lazy, or even malicious just makes them disengage (and correctly so).

The end result is that they will continue to object to the thing, but won't raise their objections to the experts anymore. And why would they? Nothing good came from it the first time.

It turns what should be a cooperative relationship into a combative one. I see this happen in pretty much every discussion of IPv6 around, including this one.

The other issue is that the subject matter experts rarely actually explain anything. They just toss out acronyms and buzzwords and consider the matter corrected. But it's not -- they're talking as if their audience is another subject matter expert, when it's usually not. Acronyms and buzzwords mean little to them.

And telling them to "google it" likewise does little good. The audience isn't a subject matter expert, doesn't want to be, and shouldn't have to be. If IPv6 really is so complex that you have to be an expert in order to use and configure it properly, then isn't that a problem with IPv6?

My assumption is that's not the case (but I'm not sure on this point), but instead, the experts are failing to actually teach people about this stuff.

In the end, I blame the rollout of IPv6 itself. Exactly zero attention and effort was paid to evangelizing and educating people about it. There was no gradual rollout plan put into place and encouraged.

The IPv6 rollout effort failed to do the things that are necessary to facilitate a shift of this magnitude. This makes the whole thing very confusing and leads people who aren't elbows deep in the topic to lean toward "I don't feel that I can do this safely, so it's better that I don't do it at all". Which is not an unreasonable stance.

The tragedy is that it all could have gone so much better than it has. It could have been a thing everyone unified about rather than a thing that is rapidly becoming a kind of holy war.

yeah or just what about an article or even a whole book on the subject of:

"You're gonna move your home network to ipv6, here's what you need to know to not f&^k up hard and get pwned" At the level like we know for ipv4.

Right now, I actively disable ipv6 in devices on my network because I don't have a clue about how it all works. Am I making something addressable from the public internet? Am leaking every mac address I have? So much more I'm sure I havent even considered.

Then when you look at ipv6 tutorials you see nuts things like each octet containing a zero value can be shortened to just a single zero :00000000: becomes :0: ok fine, but consecutive octets of zero are removed so :00000000:00000000: becomes :: swallowing a delimiter so programming this stuff you can't even just split on the delim and /know/ what octet is where. Now maybe theres a good reason for that but where is the explanation? Not in any of the tutorials that have to explain how this stuff works rather than something, you know, useful. As presented it's pure additional, utterly meaningless, learning overhead.

So yeah. I'm too stupid to run ipv6 and I know it. But I'm not nearly as stupid as those who claim it's ready for prime time because it damn well isn't.

Anyone thinks it is. Link the document with a time estimate on running a home network with ipv6 knowing what you need to know (and know already for ipv4) to not do something idiotic.

In this crowd, we'll learn stuff just because it looks cool and you can't reach us? Get outta here.

Yeah as an old former-system admin its kind of amusing to be on the receiving end...

I think the main barrier is that for most people IPv4 works just fine and they've never experienced a problem that IPv6 would solve. Maybe they will, some day, like if Facebook and Google shut down their IPv4 IPs.

Speaking for myself, but my main barrier to IPv6 adoption is my ISP (Wave/Astound, Seattle eastside) still being IPv4-only, despite having DOCSIS3.1 service.

I didn’t think it was even possible to have DOCSUS3.1 without IPv6 :S

Main barrier for me is there’s no interoperability with ipv4, and no official transition plan (just a bunch of rfcs suggesting different transition plans).

Prediction: CGNAT processing costs for gigabit subscribers will become neglible in the medium term (3-5 years). Not that it's wildly expensive today...

You are literally posting this comment on a story about CGNAT processing costs being wildly more expensive than a small ISP cares to deal with. To the point where they’re willing to buy and distribute AppleTVs to reduce costs.

Even if that price decreases in real terms, washing a whole bunch of traffic through a big-ass NAT is always going to cost more than just not doing that.

The cost of an IPv4 address is around $50. Annualized it's a few dollars. So, that's the baseline for where CGNAT makes financial sense.

That's a lot less than the cost of an Apple TV.

MAP-T/MAP-E moves the CG-NAT functionality to the CPE. 60x users per IPv4 address should be doable.

> IPv6 for local networks, makes no sense is completely unnecessary, and is a hill I will die on. IPv4 is here to stay.

This is a position of privilege. The developing world would like access to the Internet and lack access to the (mostly) exhausted IPv4 space. Should we not work to make Internet access ubiquitous?

He's talking about running IPv4 on his LAN, not the internet. That wouldn't use up any of the internet's IPv4 space and wouldn't affect other internet users.

> IPv6 for local networks, makes no sense is completely unnecessary, and is a hill I will die on. IPv4 is here to stay.

my mobile phone in the UK on one of the big 4 carriers only has IPv6 addresses

and only has IPv6 connectivity

(using 464XLAT)

link local ipv6 can be deterministic (no more shuffling IPs around!) and no more silly dhcp services running on anaemic hardware.

Ditto for NAT, where devices can reach v6 endpoints (though stateful firewalls should stick around!).

Honestly, I really hate change. but ipv6 does have some upsides and rather than complicate things, embracing actually simplifies things.

The issue is that we have a lot of sunk cost on how we bolt on shit to ipv4 to make it passable in the modern day, and we begrudge having to relearn what we think is solved.

How do you reach all 2^128 ips when you only have 2^32 destinations?

IPv6 makes sense everywhere.

Not going to lie, I just turn IPv6 off on my router because I don't fully understand it and because I pay a little extra for a block of 3 IPv4 addresses.

who cares if it's "public" if it's firewalled; likely by default

Hills sparsely populated with corpses are equally fascinating and comical.

I have reviewed the logs for our video CDN and out of 150,000 sessions, only 48 were identified to be using IPv6. These sessions were identified by the user-agent Roku/DVP-12.0 (12.0.0.xxxx-xx), indicating that the recent update to the operating system now supports IPv6.

I wonder if it's just a bunch of old and outdated Roku boxes causing problems? They probably work off of a ~3-5 year support cycle like phones but are updated even more infrequently by endusers (why should they if it's still working for them?).

I believe Rokus auto-update frequently. All of my devices are up to date on version 11.5.

I have a Roku 3 (these came out in 2013) which I regularly update. The support cycle is fairly long. I think they did stop supporting some Roku 2s at one point due to a new feature the old hardware just couldn't support.

All other streams are made with 11.5 - which is the official latest version.

Release notes don't say anything about that change but it wouldn't surprise me if it was left out.

The amount of idiocy and ignorance around ipv6 is crazy.

I’ve seen many supposedly senior engineers that claimed they didn’t want to implement ipv6 because anyone could connect to hosts from “outside”.

Nat has become so engraved in people’s thinking that they can’t even understand the actual role of a firewall anymore.

We’re going to see many stories like this, where networking incompetence will start costing pretty pennies to companies.

Basic corporate and home networking with NAT and sane default firewalls have been solved for so long now that even senior engineers have never had to deal with it. I haven't had to deal with firewalls in 15 years now.

So I can't entirely fault them for not understanding, but you're right, it's kinda nuts.

It’s not just that ipv6 is publicly routable but rather the mistrust of ipv6 itself. There have been a multitude of remotely exploitable vulnerabilities with ipv6 many in embedded devices that are not getting patched.

Turn on ipv6 and all of these vulnerabilities are instantly exploitable. It’s not a matter of filtering as some of these vulnerabilities are in parts of the icmpv6 required for configuration. For an alarming example check out some of the rtos vulns back in 2020.

> I’ve seen many supposedly senior engineers that claimed they didn’t want to implement ipv6 because anyone could connect to hosts from “outside”

I had this argument with the head of dev ops at my previous work. They claimed IPv6/dual stack networks were a security risk that couldn’t possibly be tolerated. The fact that they were going to be private sunsets, and would have a firewall, NACL’s, etc was lost on them.

On the flip side I'm so regularly impressed by what random HNers know about networking (particularly due to containers) I sometimes wonder if there is a point in me being a network guy!

I think a large part of the general attitude is IPv6 is a topic everyone is exposed to but few have really been expected to know so there is a lot of strong feelings about how it's crazy compared to the thing they've already spent 20 years getting familiar with. I think if everyone was exposed to NAT in the same fashion there would be a 10x stronger reaction against NAT than IPv6 but at this point everyone is used to NAT and IPv4 and forgets how weird/annoying they really are too.

I remember the early Internet, before NAT. Everyone had public IPs everywhere. Most universities had public IPs on the desktop (and dorm room.) My home network was a /24 with no NAT. NAT was supposed to be the exception, not the rule.

My first Networking job (2012-2015) was still like that! It was a regional health system that had a /16 from the early 90s (pre-ARIN). We were still using public IPs on printers and guest networks even. It was a bit of a pain going to the next place with 10x the devices and 1/10th the IP space.

Funnily enough the first job with all public IPs was the one with some IPv6 deployed while the 2nd was the one without. Of course it was the same manager in the early 1990s that rolled out IPv4 there that rolled out IPv6 in the 2010s so maybe it's not so surprising.

I have devices on public v6 at home. When I hear people complain about these things I honestly ask them. What the hell are you running on your machine that you dont want anyone accessing? Bind it locally then or use an fwall.

I am astounded by the lackadaisical stance of network admins in the pro-v4 camp.

By traffic it seems like "if only we didn't have these Rokus!" but it's a streaming device, it generates a lot of traffic compared to the other IPv4 only devices. Inevitably the long tail of devices is what's costing them extra (sounds like CG-NAT dual stack or 464xlat at the gateway) not just the Roku devices.

As someone who operates their own ASN with IPv6 because I like v6 so much the problem here was simply poor planning. Handing out Apple TV's to replace Roku devices isn't going to make the need for v4 services go away at these homes.

It may not reduce the need for IPv4, but it will reduce the need for costly CG-NAT devices and capacity for IPv4 when the streaming can happen over IPv6 which does not require the costly CG-NAT devices.

I may be mistaken on how many people this ISP is serving but for 300K they should have gotten pro serv, licensing, and hardware for ~100 million sessions, some of which now no longer need to go through the NAT64 hardware.

Hopefully they didn't buy through the same people that sold them the NAT64 hardware+software without CG-NAT built in though...

Wonder if ISPs will just let their CG-NAT get overloaded and if you want to send a v4 packet you just have to wait for your time slice on the hardware.

I've seen that. Too many connections, so the idle timeout is now ten seconds. And, as per usual middlebox NAT, no packets sent when closing an idle connection, and no response to packets sent on 'unknown' connections.

I really hate Roku as a product, ads on the home screen and the remote(??) of something I paid for? No thanks. Though, I will concede it is cool to load mostly "unapproved" apps if the developer shares the app ID. (Certain x-rated sites liked to advertise they have a Roku app, something that would never make its way to most other TV boxes)

That's par for the course nowadays, unfortunately. I couldn't name a smart TV system that doesn't have ads.

Roku is far from being the worst offender, my LG C2 that I paid out the nose for has the majority of the home screen taken up with ads.

> I couldn't name a smart TV system that doesn't have ads.

What do you consider to be ads? Apple TV is pretty tasteful in this regard. It never feels like I’m getting served an ad at all. In fact, with all Apple products I never feel like I’m getting served an ad.

Apple TV shows promotions for apps in the top row. These are ads. They are often shows the user isn't interested in, but the service is interested in pushing.

I'm pretty sure thats a feature for any app you put in the top row. If you have Netflix in that row it will show you recommended.

But I don't have to pay extra for those Netflix shows. If you don't have Apple TV+, those cost extra, making it far more of an ad than Netflix simply displaying other shows on their service.

It is. Each app decides what goes at the top, not tvOS or some ad system. It’s why some apps show nothing there.

They're still ads, though.

Yes, I meant Apple TV the device.

my samsung has a permanent ad for appletv, and I'm an apple hater, so I will never buy it and I can't easily make it go away, which makes me hate it more.

...Dear God, it's been so long since a time where there wasn't continuous exposure to ads, that people are starting to argue that certain types of being advertised to aren't advertisements.

Truly, we have have fallen far away from the light of $DEITY.

I feel the same way about tvOS, but I've not used it without being subscribed to Apple TV, so I don't know if it pushes that hard if you don't have it. Otherwise the default screen has their service's stuff mixed in with other services (if they support that—some don't, like IIRC Netflix) and the amount of promotion isn't worse than if you're in another streaming app and they're trying to show you shows you're already paying for, that they want you to watch—and the actual app menu has none of that, no ads at all.

> but I've not used it without being subscribed to Apple TV, so I don't know if it pushes that hard if you don't have it

It doesn’t. The only apple product I’m pushed to use is iCloud on my phone and computer which is quite aggressive because it’s a notification you can’t disable .

> I couldn't name a smart TV system that doesn't have ads.

Which is the #2 reason why I won't ever own a smart TV system.

Apple TV doesn’t have ads.

It basically has ads with the default home screen setup to show you what's new on ATV+ and iTunes. Slightly more tasteful than McDonald's McDelivery Banner ads but it's essentially the same.

The background-banner at the top of the Home Screen shows banners from the currently highlighted app - if you remove the AppleTV+ app from the top-row of your home-screen then you don’t see any promotions of any kind.

> It basically has ads with the default home screen setup to show you what's new on ATV+ and iTunes.

This objection perplexes me. What would you rather have on the Home Screen? A blank screen? A list sorted from A-Z. Oldest to newest (for the most compulsive of TV viewers?)

Something not trying to sell me something or get me to subscribe to a service? You know, not ads?

I went away from it, but ultimately came back because its universal search worked best for me. Fire Stick, Chromecast w/ Google TV, and Apple TV all routinely were unable to inform me that a show or movie I searched for was available for me to stream on a service I already subscribed to.

At least on my Roku I can turn most of the fluff off, and I'm much more confident I won't spend money renting something I have available to stream for free. Beyond the basics of 4K and HDR support, I didn't realize this would be the most important thing to me.

Edit: saw this article not 60 seconds later haha https://www.theverge.com/23621907/streaming-tv-boxes-roku-am...?

I promise you, LG's WebOS is worse in almost every conceivable way.

Rubbish. My webOS TV has proper filtering at the router level and has exactly 0 ads on it. Having full root access is great too.

I also think it’s appalling how much input lag there is with these devices. It’s 2023 and there’s seconds long delay between input and response with these things. I get they’re cheap but how much CPU is needed to move a cursor?

I’ve tried pretty much all of them except Apple TV, and I’d say Roku is the least laggy overall. Our FireTV devices became so laggy they were unusable. Android TV isn’t too bad, but Roku feels a bit more responsive to me.

This depends highly on the app that's being used. The Roku OS itself is responsive, but app quality varies widely.

> First off I despise both Apple and that other evil empire (house of mouse) I want nothing to do with either of them.

It’s funny that the poster despises Apple. But is okay with a company where the CEO explicitly said that they want to make money not via hardware sells, but via selling user’s television watching behavior.

Everything about the Roku is a janky experience. From the ad that takes up the Home Screen to the hard coded buttons that go to the highest bidder.

I have one remote that still has a useless Rdio button.

> via selling user’s television watching behavior

Gross. I hate how commonplace this is becoming. Even your basic non-Roku-OS TV people are saying never to connect it to the internet as it'll just fingerprint stuff on your HDMI and tell advertisers you're watching Game of Thrones

I used to think like that, then I realised that my life is not actually being made worse because of it. The TV doesn’t know who I am, personally (I’m not signed-in to any accounts) and it’s all just mass aggregate data that will probably end-up being ignored by network-execs so why worry?

My issue with Roku is that advertising makes it a bad product.

I'm not worried about some specific risk coming from Roku itself. But Roku contributes to the normalization of surveillance capitalism which I think is fundamentally corrosive to a free and democratic society. Having such a business model makes Roku a willful part of the problem, so I want nothing to do with them.

I just bought a brand new motherboard that still has VGA and PS/2 ports, so I would guess IPv4 isn't going away any time soon. Old standards seem to hang around forever for legacy support. Why an ISP would assume they could set up an IPv6 only network is beyond me.

Unless it's a server motherboard, it most likely supports DisplayPort or HDMI, possibly even over Thunderbolt/USB-C?

Legacy compatibility is not an issue (unless it makes things complicated, unreliable or limited in the name of backward compatibility). Lack of modern functionality is.

Similarly, presence IPv4 support in devices is not a problem - lack of IPv6 support is. The comparable issue would be if you have bought a new motherboard but all it supports is VGA - now, that'd be quite inconvenient (even if it's a server board that runs headless 99.99% of the time).

This reminded me of an e300-8D I recently parted ways with. Bought new in 2017 but only had VGA out from the BMC... I gave away the VGA monitor I was using with it. Looking back I'm surprised I didn't just buy an active converter, it was such a pain to pull that monitor out :p.

Same story, except that I have an ASRockRack EPYC board for a home router/server/NAS combo.

Fortunately, most of server boards have a built-in LOM solution with some sort of IP-KVM. So the actual video output is only ever needed for the very first time - and that's if LOM defaults are not known.

Or, well, if things break - e.g., I've had issues because management port sharing was enabled by default and I haven't realized I should turn it off until I've noticed that my server became unresponsive for IPMI-over-IP queries.

I'm a bit frustrated that I had to purchase an adapter, but at least that was an one-in-a-lifetime purchase.

Not sure why we are comparing hardware with software here. Your motherboard can run IPv6 just fine :)

You probably bought a server motherboard, so the ports are there for old KVM-type devices. Good luck buying a consumer motherboard with VGA and PS/2 ports.

Nobody was comparing hardware with software. The point was that things tend to stick around way beyond when their "replacement" rolls out.

https://www.msi.com/Motherboard/B450-A-PRO-MAX

Here you go. It's a little older, but AM4 is still competitive, especially if you're using video from the CPU. In which case, the lack of a 500 series chipset isn't a big limitation.

I raise you a B550M board! https://www.biostar.com.tw/app/en/mb/introduction.php?S_ID=9...

Depending on the rules there's also the https://www.asus.com/motherboards-components/motherboards/pr... with ps/2 and while there is no physical VGA you can passive adapter one out of the DisplayPort connector.

Passive adapters from DisplayPort to VGA sounds unlikely? Port powered adapter, sure, but unless they're doing something really weird, you need at least some DACs and maybe something to translate sync? That's unlike single channel dvi-d <-> hdmi conversion which is just a matter of connecting pins; IIUC, you can passively convert from display port to single channel dvi-d (and therefore hdmi), but dual-channel dvi-d needs active conversion too.

If it were passive, I'd say it counts (maybe some board connected vga to the dvi-a pins?), but I not the OP.

It’s very likely I’m just assigning too much functionality to DP++ in my memories :).

For a company who thrives on making cheap devices and charging for licenses/platform, this is almost a crime especially when supporting ipv6 on Linux based devices is much easier now. Wonder why don’t support it.

> Wonder why don’t support it.

It's probably harder to tie devices in a single household together with IPv6 than with IPv4, or so they think.

They don't make (much) money on their devices, they make money on selling data collected and aggregated by their devices. Their "privacy" policy [0] is a hoot to read. "Whatever we can do, we will. If the laws of the country we collected the data in would interfere with that, we'll move the data and then do what we want." I mean, they grant themselves permission to nmap your network for other devices! Emphasis mine.

> We may receive information about the browsers and devices you use to access the Internet, including our services, such as device types and models, unique identifiers including advertising identifiers (e.g., for Roku Devices, the Advertising Identifier associated with that device), MAC address, IP address, operating system type and version, browser type and language, Wi-Fi network name and connection data, __and information about other devices connected to the same network__.

[0]: https://docs.roku.com/published/userprivacypolicy/en/us

> It's probably harder to tie devices in a single household together with IPv6 than with IPv4, or so they think.

It's probably easier, in fact. A significant and growing number of households are behind CGNAT on IPv4 and not have a 1:1 household : ip address relationship. On the other hand, if they're on IPv6, they're most likely on the same /64.

But, Roku's not doing IPv6 was handy for me when Netflix decided not to accept IPv6 connections over Hurricane Electric tunnels. I didn't have to change anything, and I didn't have to do anything, the Rokus were already ignoring IPv6.

The big issue with v6 is you don't know what every ISP is doing with their IP space. The current RIPE recommendation is to delegate somewhere between a /48 to a /56 to every customer. Some ISPs might only delegate a 64, and perhaps typical home wifi setup may only use a single /64. For data aggregation maybe the error is ok, but I've wondered about what IP banning/filtering looks like for v6. Assume everyone gets a /64 and most cats will have 256 lives, and sometimes 16384. Assume everyone has anything larger than a 64, and you may block 255+ other people with the intended target.

IP based bans have long been obsolete imo. These days a combination of google captcha tracking and phone number verification is mostly used. A few things like IRC and 4chan still do IP bans which is painfully obvious when you notice you are randomly banned depending on what CG-NAT handed you at the time.

Start by banning /64's, but if you see a lot of nearby bans in some ASN, mark that one for bigger bans. Easy-peasy-ish.

> __and information about other devices connected to the same network__

They may also be doing more nefarious things, but this might just mean it watches for UPNP and other announcement-broadcast messages on your network (like, say, mdns).

The rest of their "Haha, you bought one of our devices, all your data is ours!" policy doesn't give me much cause to give them the benefit of the doubt here.

At least some people [0] have reported their Roku device scanning their network, which is explicitly allowed in that policy. Though you can probably do a lot of it passively without leaving those annoying traces.

Once they've granted themselves permissions to do it, why wouldn't you? Knowing a house is an Apple household with a lot of devices probably means they've got money, or at least a willingness to take on debt. You can get a sense of when devices come and go to help identify activity, and if you're particularly annoying, you could snoop wireless signal strength of other devices on the LAN to get an idea of who's in the room with you.

If it's only got a few Androids and Chromebooks, well, probably lower income. If you can't find a thing on the LAN, you're probably in the house of a computer security researcher and should behave. Etc.

If they meant to say "We watch for UPNP announcements to identify other content sources on your LAN," they could have said that. But they didn't. They left the door wide open to do whatever home LAN analysis they think they can get away with.

I mean, this is a company whose response to the "Do Not Track" bit is to ignore you [1]. No standards? It's literally in the name.

> Do Not Track

> Some Internet browsers include the ability to transmit “Do Not Track” signals. Since uniform standards for “Do Not Track” signals have not been adopted, the Roku Sites do not currently process or respond to “Do Not Track” signals.

[0]: https://community.roku.com/t5/Wi-Fi-connectivity/Roku-Device... [1]: https://docs.roku.com/published/cookiepolicy/en/us

> At least some people [0] have reported their Roku device scanning their network, which is explicitly allowed in that policy.

Not just no, but hell no. I would 100% interpret that behavior as the prelude to an attack.

They use this for the remote feature in the app. You can control roku's on your network without being signed into the roku account tied to the device iirc.

(At least. Not saying they are not doing anything else bad, Just that there is a valid use.)

> It's probably harder to tie devices in a single household together with IPv6 than with IPv4, or so they think

So I wonder if this means it is harder to ID the consumer with IPv6 ?

It's easier. You'd be using SLAAC and your devices would have globally unique IP address based on the MAC address of their network interface.

Expect that some systems use random temporary IPv6 exactly to make it harder to track (even Windows)

Probably not very helpful against adversary device (like Roku) running on the same LAN.

Are Rokus Linux based? I'd love to install an alternate distribution on one.

What would the point be, exactly? The stuff that makes a Roku worthwhile are all the apps and the proprietary drivers and networking stack stuff. If you're going to put an alternate distro on it, you might be better off getting a whitebox Android TV/Kodi/whatever box off of Aliexpress than trying to get around the limitations on the Roku hardware.

It would be pretty cool to be able to program my Roku to do anything I want, rather than be limited to whatever they want. In theory I can connect another device to the TV and use it as a display, but even in that case the Roku software is active. A security researcher (amateur or professional) is going to want to get in there and see what's going on in addition to running through a proxy.

There are also some scenarios (admittedly pretty contrived in our compute-rich world) where your TV computer is the only one available to you, and so it would be in your interest to expand its functions. Imagine a kid in a poor neighborhood - theoretically with just a keyboard and a USB stick he could be using that TV as an internet-connected computer to learn how to program. That's a lot more value than running Netflix, IMHO.

Right -- and I get that -- but I guess my point is, what can even really be done by rooting a Roku, since all the stuff in user space is close source/proprietary and the drivers are unlikely to be useful with an alternate distro.

A RPi would be a much better choice for a poor kid in a neighborhood who wanted to have a way to program.

Have you tried buying an RPi lately? They are impossible to find. And it may be that compute devices will get harder to find over time. That poor kid may not have another choice.

From Wikipedia:

> The Roku box runs a custom Linux distribution called Roku OS.

Looks like yes.

> Are Rokus Linux based?

Even if it wasn't, don't most embedded OSes come with IPv6 support? How small do you have to be to not have it? QNX is pretty compact, and even it has it:

* https://www.qnx.com/developers/docs/7.0.0/#com.qnx.doc.neutr...

LwIP is common on embedded devices. It has only supported dual stack in the last few years but even if it's possible, there are resource savings when only running v4.

This is an area that seems surprisingly empty from my observations. There doesn't seem to be much interest in rooting Rokus, and even if you did there doesn't seem to be a good open source replacement. The closest would be to install Android TV, but that's just exchanging one closed garden for another.

What I don’t understand is why. Their OS is built on a linux kernel from at most a couple of years ago. I’m assuming the same goes for the libraries and the parts of the userland they didn’t make themselves. On any linux kernel not from the 90s it’s more effort not to support IPv6. Unless they rolled their own, which would be a tremendously stupid thing to do.

Perhaps they have a limited development team and chose to focus on matters that bring in the most dough and/or make their average customer the happiest.

then they would have supported ipv6 because it’s less effort not to strip it out of the open source software they’ve based their platform on

Don’t confuse kernel support with their custom userspace software. That may be where the issue is.

Most consumers don't care, and home routers don't support it well

Most ISPs don't support it well, and will still give you a dynamic IP

Companies don't want to bet their reliability on something that fails as much, with an alternative that is working, and invest to maintain both and troubleshoot them

I will worry with IPV6 when I can safely disable IPV4, until then I disable IPV6

The recent Netflix password-sharing cracking may create some Roku victims.

The other day, I reviewed the devices logging into my account, all inside my house. However, there was one caveat: two Apple TVs in IPv6 and one Roku in IPV4, with different ASNs, showing as two separate networks 900 km apart. I didn’t receive any Netflix notice so far.

No, the absurdly poor migration path to IPv6 is costing the tech community as a whole.

No one cares about ipv6. not even VPS providers, it's always turned off by default unless you want to go through the pain of enabling with commands. no thanks.

"First off I despise both Apple and that other evil empire (house of mouse) I want nothing to do with either of them."

So they decide to go with a company/device that has the absolute worst record of spying on their users? Roku is terrible. But if they're okay with it looking over their shoulder at everything they watch, then go for it.

There's no ipv4 nat for IPv6?

There is but it'd require a special device at each customer location. CG-NAT (a.k.a. double NAT) is probably what they did because it only requires a couple of centralized boxes then the rest is deployed like a normal dual stack network and your average home Netgear router works with it out of the box.

NAT in the other direction (i.e. IPv6 local client, IPv4 remote host) is easier, and I'd be very surprised if they didn't already have that given the number of v4 only sites, but doesn't really help the v4 only devices.

Sorry flop the numbers. I meant public V6, private V4 nat.

I think that's what NAT64 is for.

What makes no sense in 2023 is to have an IPv6-only network. That is liable not to work. Someone will eventually bring some old device that won't be able to connect.

Did you mean "IPv6-only network"?

Definitely, thanks!

> Someone will eventually bring some old device that won't be able to connect.

I have a separate WiFi AP just for my guests. It only goes to the internet and does not route to my LAN at all. It supports IPv4 and IPv6 so everyone's covered.

I do this because my LAN is encrypted and it's inconvenient to have to issue new certs to anybody stopping by just so they can reach the internet. But as a bonus, I don't have to worry about accommodating whatever oddball hardware my guests may have.

I recommend this practice. It works really well.

that's not a bug, it's a feature

My #1 step in troubleshooting any network issues is to disable IPv6. Step #2 is so rarely needed that I no longer remember what it was. IPv6 has been a failure, it is about time we openly admitted it. Why? Simple - it causes consumer pain and no consumer gain

I feel similarly, but what is the solution? IPv4 blocks are all but impossible to get anymore, there's a waiting list at ARIN that doesn't really ever move. The company I was working at signed up 3 or 4 years ago for a /24 and never heard back to this day. Sure you can rent/buy them on the open market, but that's only going to last so long, and eventually puts anyone without FAANG money out of the running...

Regulation. Incentivize ipv6, tax ipv4 only devices, mandate ipv6 in government networks.

Ah yes "the government will fix it" okay .

Maybe practice what you preach and deploy v6. I have. Infact I run v6 only.

You can’t just change the size of an IPv4 address without creating a whole new thing.

Yes, but let's not pretend that IPv6 was just IPv4 with a larger addr size. A lot of other unnecessary cruft got changed. That is kinda the issue. Add an extra octet to IPv4, call it IPv5. Done. DHCP (as is) can already handle variable-length addresses so it'll work unmodified for 5-byte addrs, for example. Same for ARP.

> Yes, but let's not pretend that IPv6 was just IPv4 with a larger addr size. A lot of other unnecessary cruft got changed.

Mostly removed (e.g. removing fragmentation). If you're making an incompatible protocol, might as well take the chance to remove the cruft.

> Add an extra octet to IPv4, call it IPv5. Done.

Have fun debugging nondeterministic routing loops lol.

Fragmentation is mostly removed on IPv4 as well. Almost everything sends DF, and there's very little legitimate fragmented traffic. You can just drop fragments wherever convenient. If you want to be nice, it's a good idea to have a small reassembly buffer, but if it's too much work, just drop them.

It's beyond too late to change anything, but I imagine if IPv6 had started with a sensible rollout plan and worked backward from there, it would look somewhat different and it would have taken a lot less time to take hold.

IPv6 doesn't remove fragmentation. IPv6 fragmentation works differently. See https://www.rfc-editor.org/rfc/rfc8200#section-4.5

The Fragment header is used by an IPv6 source to send a packet larger than would fit in the path MTU to its destination. (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see Section 5.)

But the IPv6 changes are actually good, right? IPv4 was designed for an entirely different world and IPv6 was designed for this world. You're only going to get one chance to make these kind of improvements.

IPv6 has link-local, v4 doesn't. That is a huge configuration win.

IPv4 also has link-local addresses. They belong to the range 169.254.0.0/16.

And is it enabled by default?

Also is it mathematically unique not to cause any potential conflicts.

Yes. 169.254.0.0/24 addresses show up quite often.

I am wondering if we could hack the ipip tunnel to automagically handle a bigger address space.

Much akin to your idea but mostly supported already

You can though, there is an options field in IPv4 that could have been made to hold extended address values.

It was used as part of the Extended Internet Protocol: https://www.rfc-editor.org/rfc/rfc1385

And the Address Extension protocol aka IPv7: https://www.rfc-editor.org/rfc/rfc1475

And now you need all routers in your path to support it. Effectively creating two incompatible networks and achieving a worse result.

Routers already support the Options field, it's part of IPv4. The old RFCs mentioned are specifically designed so only routers at the edge need to support them.

You should try reading the specs before making technical claims instead of completely missing the point of why those RFCs were created in the first place.

Instead we have to rehash an argument from 30 years ago.

IPv6 was enabled about 6 months ago in my area by my ISP. I noticed it was on about a week after they enabled it because I saw funny IPv6 networks I didn’t recognize in a log somewhere. I doubt this national ISP would turn on IPv6 like this without any notification if they were concerned it would cause “consumer pain and no consumer gain”. No pain here, and I’m hosting IPv6 only sites I can easily access from my mobile (with native IPv6) for fun.

Is it possible your ISP’s IPv6 network was problematic? I’m not sure how you can draw the conclusion that “IPv6 has been a failure” given evidence it’s live, in public, serving its purpose. The world has not exploded.

That hasn't been my experience at all. Working around slow, unreliable NAT devices (all of them) causes stuff that runs over ipv6 (these days, almost anything that uses significant bandwidth) to work better and faster for me.

There is a cost there though as mentioned in the forum post. The ISP in question is using CGNAT, but they need more IPv4 addresses even with CGNAT to support higher loads. CGNAT only reduces the number of IPv4 addresses required, it does not eliminate the scaling.

However, I do think IPv4 is honestly pretty good for local or even WAN networking for organizations. You're unlikely to ever hit limits in the reserved blocks and it's much easier to read and work with IPv4 addresses. Maybe we need easier configs to block IPv6 except for external addresses?

> I do think IPv4 is honestly pretty good for local or even WAN networking for organizations

Strong disagree here: I sometimes do work which involves VPNing-in to SMB company on-prem networks from within other SMB’s on-prem networks, so they’re all invariably using 192.168.x.x or 172.16.x.x whuch means they all conflict with each other when you want to use LAN resources at the same time you’re VPN-ing to another network.

My hope is that IPv6 will mean point-to-site and site-to-site VPNs will die-off and we’ll be able to connect all hosts directly to other hosts (IPSec Transport Mode) - but then I’m reminded that configuring an IPv6 firewall for IPSec is conceptually much harder than setting up OpenVPN - and SMBs don’t have much in the way of people who even know what IPSec is, ugh.

I remember when I first got Google Fiber and the solution to "amazon.com will not load, ever, period" was to disable ipv6 on their router.

Not sure I've ever bothered to turn it back on.

If only everyone hadn't dragged their feet "because it's too hard"; we could maybe be living in an IPv6 utopia? Maybe if the government started handing out fines? haha

At least for local applications at home, this has been my experience as well. I'm sure data center operators love ipv6 but it's been nothing but a headache with no benefit for home consumer use.

Please leave the profession - you lack the required qualification.

IPv6... Can it just go away already?

Adoption has been declining for years. Many devices don't support it. Many services seemingly support it but break in strange ways.

And not to mention it's a subtle and yet powerful privacy attack vector.

> Adoption has been declining for years.

Source?

> Many devices don't support it.

Source?

> Many services seemingly support it but break in strange ways.

Got any examples?

> And not to mention it's a subtle and yet powerful privacy attack vector.

This is the only statement you've made that has any merit, and even then very little.

Privacy Addresses have been a thing for a while, and most OS's support it. No longer are there stable addresses being generated from the MAC address, and all outbound connections are now on randomized addresses from the /64 that is announced through SLAAC.

Just like IPv4 having a single address for a household, IPv6 has a /64 per household (although many ISP's let you request more if you want).

IPv6 is growing, more and more traffic is going over IPv6 and it is not likely to go away any time soon.

Taking some points from their side not because I necessarily agree with the conclusion but just because this comment comes off a little strong:

Adoption hasn't been declining by any measure but the adoption rate isn't as high as it was 5 years ago. Of course eventually the rate has to slow down because there is less and less to change over so that doesn't mean much. Overall though adoption has continued to increase without any long term dips.

Many devices don't support it is probably one I consider true though. It's getting way better as the years go on but it's fair to say the world isn't past IPv4 only devices in households by any measure. Typically embedded products are the worst. Home security stuff, point of sale gear, older or just crappy media devices, oddly some IoT type devices like a fridge. Plenty of gear also supports it but just very poorly. Of those that do not all understand NAT64 either so while they may support IPv6 but they don't necessarily work without IPv4 (this also getting better as more services move to supporting IPv6 too).

SIP and WebSocket are examples of some protocols that can break services under NAT64, especially with so much of the web being v4 only. They should be fine if the world ever moves 100% to IPv6 though. The era of misconfigured AAAA records wreaking havoc thankfully seems to have come to an end.

I don't have anything to add on the privacy discussion, I think you nailed it there.

> Many devices don't support it is probably one I consider true though. It's getting way better as the years go on but it's fair to say the world isn't past IPv4 only devices in households by any measure. Typically embedded products are the worst. Home security stuff, point of sale gear, older or just crappy media devices, oddly some IoT type devices like a fridge. Plenty of gear also supports it but just very poorly. Of those that do not all understand NAT64 either so while they may support IPv6 but they don't necessarily work without IPv4 (this also getting better as more services move to supporting IPv6 too).

This is very much the case. I used to compile statistics about various devices for our network gateway. ipv6 support was very hit or miss and was the root cause of many spurious support tickets.

Here you go:

https://www.potaroo.net/ispcol/2022-02/ipv6-fig4.png

also:

https://www.potaroo.net/ispcol/2022-02/ipv6-fig5.png

You can answer the rest of your own questions. I am not your personal Google.

Allocations describe how many new blocks are being assigned. For adoption you'd want something like this link https://bgp.potaroo.net/v6/as2.0/index.html which displays the number of IPv6 advertisements at a given time, including assignments that were made in previous years from prior allocations.

When you look at the same graph for IPv4, its pretty obvious that graph isn't showing data that supports the conclusions you're drawing from it:

https://www.potaroo.net/ispcol/2022-01/addrfig2.png

On what metric does this look like it's declining? https://www.google.com/intl/en/ipv6/statistics.html

That graph also shows another interesting bit: it seems that IPv6 usage is higher on weekends — i.e. home internet connections. So it's even worse that Roku of all people doesn't support IPv6, considering IPv6 is ahead in homes.

hmmm no thanks. i'd very much like to not have to deal with NAT anymore, just some firewall rules instead.

do temporary addresses do nothing?

IPv6 adoption has been increasing.

There remains the problem that we've run out of IPv4 addresses. I agree that IPv6 was not the ideal solution to this, but it's the only solution we have.

I'm going to ask this and it's going to sound accusatory but I insist it's innocent: what is a more ideal solution than what we have?

I don't know, it's not my specialty, not an issue I've spent any time researching, and the ideal solution depends on the requirements that are trying to be met. I also don't know what all those requirements are.

IPv6 is obviously addressing many requirement beyond IP space exhaustion, though. When I speak of an "ideal solution", I'm speaking about just addressing that issue.

Even if I had a perfect solution at the ready, it wouldn't matter. We have to work with standards, and the adopted standard is IPv6. So it's the only solution we have available.

Reply on news.ycombinator.com