Hacker News Reader

Comment by 2024throwaway | Hacker News Reader

2024throwaway

I personally don't think making a very large amount of devices completely obsolete is the best thing, from an environmental standpoint.

Call me a dumb hippie.

View on HN

IPv6 support existed in even Windows XP, if not older. Things without IPv6 support are already obsolete.

A bunch of IoT hardware and other microcontroller-based hardware has IPv6 support, but that support is often disabled to save a couple of kilobytes of flash memory. You can buy all kinds of hardware today that lacks IPv6 support.

Of course, if that hardware needs to access IPv6 services, they might as well disable IPv4+ICMP+DHCPv4 support and enable the IPv6 size in firmware, and probably get similar savings.

To be honest, I'm not sure why companies still ship ESP32-like hardware with that little storage given how cheap flash storage is, but these optimisations are more common than one might think or hope.

That is basically planned obsolescence. The world (except a few regions) is essentially out of IPv4 addresses.

There are plenty of IPv4 addresses for server use, and IPv4 in client networks is easily accomplished using whatever form of NAT you prefer. DNS64+NAT64 will work fine for IoT crap (not like your thermostat is validating DNSSEC), and a whole bunch of ISPs rely on DS-Lite+CGNAT to allow IPv4 connectivity over their essentially IPv6-only backbone already.

Publicly reachable IPv4 on the consumer side is dying rapidly, but IPv4 LANs and servers can still work exactly because of the versatility IPv6 allows.

As it has been since 2011, and yet here we are.

> A bunch of IoT hardware and other microcontroller-based hardware has IPv6 support, but that support is often disabled to save a couple of kilobytes of flash memory.

Wait a minute, kilobytes? That much? It’s not like one needs to duplicate the entire IP layer, it seems to me the only changing parts are parsing & generating the packets.

For IPv6 you need to implement NDP, RA, and a bunch of changes to the DHCP server. You also need to start paying attention to ICMP.

The documentation for ESP-IDF (https://docs.espressif.com/projects/esp-idf/en/latest/esp32/...) says:

> Disabling CONFIG_LWIP_IPV6 can save about 39 KB for firmware size and 2 KB RAM when the system is powered up and 7 KB RAM when the TCP/IP stack is running. If there is no requirement for supporting IPV6, it can be disabled to save flash and RAM footprint.

> Disabling CONFIG_LWIP_IPV4 can save about 26 KB of firmware size and 600 B RAM on power up and 6 KB RAM when the TCP/IP stack is running. If the local network supports IPv6-only configuration, IPv4 can be disabled to save flash and RAM footprint.

IPv6 takes up more ROM than IPv4, and as far as I know ESP-IDF doesn't actually fully support IPv6 either.

At this point we're talking microcents of storage, but unfortunately the 13KB of size difference can make the difference between "the code fits" and "we need to spend a dollar more per unit".

My it really is kilobytes. Okay I guess my next project will be a TCP-IP stack on an 32-bit RISC-V micro-controller, we’ll see how much code this actually requires. My understanding of IP may be off, but I still feel those numbers are about an order of magnitude bigger than they actually need to be.

I mean, I can fit an entire cryptographic library¹ in 65Kib of RV32IC object code, and it’s not even particularly optimised for this use case. There’s no way the overhead of supporting IPv6 has to be that big.

[1]: https://monocypher.org

I think the individual parts will not be that large, but ESP-IDF is a fully features RTOS, not a dedicated microcontroller library. It provides socket APIs that integrate with both WiFi and ethernet, for instance.

If you're optimising for size, I bet you can do a lot better, but that's not really what ESP-IDF is doing. It's providing a network stack for TCP+UDP+IP+DHCP+ICMP+NDP+ARP+DNS with (close to) standard C APIs.

Microcontroller developers can probably download and use smaller libraries if they wanted to, but ESP-IDF provides a rather comfortable development experience compared to stringing together a whole bunch of libraries and talking to the hardware directly.

Still, doing a lot of things is not an excuse for the individual components to be bigger. Not unless you can justify it with interaction between components, stuff like TCP and UDP being aware of what goes on in the IP stack below and having to special case v4 and v6 (made up example, I don’t know if that’s true).

And now I’m wondering how much it would take to implement a full network stack with a nice C API.

Those devices won't necessarily be made obsolete, there are solutions for proxying ipv4 -> ipv6 and I think we'll see many consumer routers enabling those features by default for devices that do not support ipv6.

IPv6 has been supported for ~20 years. Not many devices in any regular use these days with network support, lack IPv6. That pool of devices will be almost entirely gone in 8 years when this is due.

I think we simply have different definitions of "devices".

I'm not talking about just phones, tablets, and laptops.

Which devices don't support IPv6 at this point?

Smart sprinklers. Industrial equipment. CCTVs.

Do those access the Czech government website?

I was speaking to sun setting IPv4 in general.

That said, I have to imagine that there probably are plenty of those devices that do access Czech internal services at least.

IPv4 will be around for a long time. Nobody will care if it is running on internal network. Or quadruple NATed. There are enough IPv4 addresses for sites to have them. But not enough for every user.

> I was speaking to sun setting IPv4 in general.

It's 2024 and Fidonet still works.

Nobody's sunsetting IPv4. It will fade into obscurity on its own as IPv6 adoption increases and IPv4 addresses become increasingly hard to get, as it should.

police knock on the door

“DAD, YOUR SPRINKLERS ARE HACKING THE RECYCLING COLLECTION TIMETABLES AGAIN”

(spend enough time around places like this, though, and one could easily imagine this being a thing in 2032)

As an aside, I notice a lot of the recent commits to the ESP32 repo are for ipv6 fixes. It already works in the tasmota esp32 builds on devices at my place.

This said, by then, maybe the core OS will not be metal, but Linux on all these device and we'll get top ipv6 support.

More likely, in 2032, well have a bunch of crap, built from very old SOCs running Linux 2.4.

Sounds like their creators have some work to do

Sounds like IPv6-as-botnet-DDoS-prevention is a viable strategy! Can't get DDoS'd by the unmaintained crap if said crap doesn't even speak the required protocol!

Are you sure you want any of those on a public network anyway? If they're not firewalled right now then you're already in trouble.

Also, it is eight years in the future. What future devices won't support IPv6?

This is also about the Czech government sites removing IPv4 support. What devices that would be used to access site won't support IPv6? They all do today.

Plenty. Including the ones that should know better. E.g. esphome is still working on IPv6 support ( https://github.com/esphome/feature-requests/issues/718 ).

Then there's a veritable black hole of various crappy security cameras, IP phones, and WiFi printers. And they can live for a veeeeery long time.

And I don't think I've ever seen a hotel network with IPv6 support. And I've actually seen a hotel (in Palo Alto) that gives out real IPv4 addresses to clients.

Pass laws requiring long term hardware support and open source code for unsupported devices.

... and unlimited flash space for forever upgrades!

... and unlimited flash space for accepting larger and larger upgrades, forever!

If it's open source I'll delete 90% of the manufacturer provided telemetry/tracking/anti-features and use 1/20th of that free space to add the feature I want.

One response to EU recycling mandates is to just pull out of those markets. Some website operators just block the EU as it's easier than complying with privacy regulations. When new regulations per the USA's Americans with Disabilities Act mandated captions, a few MOOCs just yanked their videos.

Reply on news.ycombinator.com