As it should. Date notwithstanding, I would actually enjoy if there was a manually induced latency penalty for "legacy IP" that needs to be manually turned off on Linux. I know some people don't care at all, but the internet was made to be addressable. IPv6 is the only shot we have to go back to that.
- I don't want my interfaces to have multiple IP addresses
- I don't want my devices to have public, discoverable IPs
- I like NAT and it works fine
- I don't want to use dynamic DNS just so I have set up a single home server without my ISP rotating my /64 for no reason (and no SLAAC is not an answer because I don't want multiple addresses per interface)
- I don't need an entire /48 for my home network
IPv6 won't help the internet "be addressable." Almost everyone is moving towards centralized services, and almost no one is running home servers. IPv4 is not what is holding this back.
NAT only matters in so far as you don't technically need a firewall to block incoming traffic since if it fails a NAT lookup you know to drop the traffic.
But from a security standpoint you can just do the same tracking for the same result. That is just technically a firewall at that point.
I recently changed ISPs and have IPv6 for the first time. I mostly felt the same way, but have learned to get over it. Some things took some getting used to.
An "ip address show" is messy with so many addresses.
Those public IPs are randomized on most devices, so one is created and more static but goes mostly unused. The randomly generated IPs aren't useful inbound for long. I don't think you could brute force scan that kind of address space, and the address used to connect to the Internet will be different in a few hours.
Having a public address doesn't worry me. At home I have a firewall at the edge. It is set to block everything incoming. Hosts have firewalls too. They also block everything. Back in the day, my PC got a real public IP too.
NAT really is nice for keeping internal/external separate mentally.
I'm lucky enough my current ISP does not rotate my IPv6 range. This, ironically, means I no longer need dynamic DNS. My IPv4 address changes daily.
A residential account usually gets a /56, what are you talking about? Nowhere near a /48! (I'm just being funny here...)
There are reasons to need direct connectivity that aren't hosting a server. Voice and video calls no longer need TURN/STUN. A bunch of workarounds required for online gaming become unnecessary. Be creative.
Only because most people don't know how NAT is hurting them, and because corporations have spent incredible resources on hacking around the problem for when peer to peer is required (essentially only for VoIP latency optimization and gaming).
NAT hurts peer to peer applications much more than cloud services, which are client-server by nature and as such indeed don't care that only outgoing connections are possible.
Odido is the cheapest ISP for a reason. They refuse to implement anything that isn't strictly required.
Perhaps implementing an Odido tax might actually make Odido care enough to throw the switch on IPv6. They bought 2a02:4240::/32, they just refuse to make use of it.
Annoying things such as paying taxes, recycling/not polluting etc.?
Some things really can only be solved via central coordination, as there is no natural game-theoretic/purely economic path from one local minimum to another. Being able to dig a small trench and letting gravity and water do the rest is great, but sometimes you do need a pump.
I'm not convinced that IPv6 is such a case, but if it is, that's exactly the type of thing governments are much better at than markets.
It will be a neat experiment, but I think most software will break and will remain broken indefinitely and then people will turn to LLMs to try to automate fixing all of it and that will turn into a mess just due to the sheer amount of changes required with little scrutiny.
Not sure if you're taking the piss or just missed it but allowing build with either protocol alone is one of the genuine ideas in this joke:
> Yeah. The date notwithstanding, I do actually think we should do most
of this for real.
> Maybe we don't get away with the actual deprecation and the warnings on
use just yet, and maybe we won't even get away with calling the
config option CONFIG_LEGACY_IP, although I would genuinely like to see
us moving consistently towards saying "Legacy IP" instead of "IPv4"
everywhere.
> But we should clean up the separation of CONFIG_INET and
CONFIG_IPV[64] and make it possible to build with either protocol
alone.
great, now can we convince the rest of the internet to start adding AAAA records and ipv6 endpoints for things. Github is still a nightmare to use DNS64 and NAT64 to access those from IPv6 only machines.
Or all the Container based stuff that still falls flat with ipv6 only modes. Docker still shits the bed if you dont give it ipv4 unless you do a lot of manual overrides to things. A bunch of Envoy based gateway proxies fail on internal ipv6 resources in a k8s cluster that runs on ARM64.
There is just a bunch of nonsense you have to deal with if you choose the ipv6-only route
Dont get me started on CDNs like Bunny or Load Balancers as a service like those from Hetzner, UpCloud, etc that don't work with ipv6 origins.
Source: Trying to run a ipv6 only self-hosted box on hetzner.
I've tried to run an IPv6 only box on Hetzner 2-3 years ago. Didn't have a problem with the platform, but with RedHat because subscription-manager didn't work over a IPv6-only stack.
When I accidentally had IPv6 only for a new Windows box it was very apparent what was a priority (worked regardless) and what wasn't important (only began working once I had IPv4 and everything fixed too).
Baked in advertising? Works with any network. The option to turn off the baked in advertising? That needs IPv4.
I honestly think GitHub and AWS are the two biggest blockers to IPv6 left. Sure your public web servers might need IPv4 for a long while yet, but all these backend microservices and CI builds etc could all be v6 only, except they need to pull stuff from GitHub or certain AWS services.
As it should. Date notwithstanding, I would actually enjoy if there was a manually induced latency penalty for "legacy IP" that needs to be manually turned off on Linux. I know some people don't care at all, but the internet was made to be addressable. IPv6 is the only shot we have to go back to that.
- I don't want my interfaces to have multiple IP addresses
- I don't want my devices to have public, discoverable IPs
- I like NAT and it works fine
- I don't want to use dynamic DNS just so I have set up a single home server without my ISP rotating my /64 for no reason (and no SLAAC is not an answer because I don't want multiple addresses per interface)
- I don't need an entire /48 for my home network
IPv6 won't help the internet "be addressable." Almost everyone is moving towards centralized services, and almost no one is running home servers. IPv4 is not what is holding this back.
NAT only matters in so far as you don't technically need a firewall to block incoming traffic since if it fails a NAT lookup you know to drop the traffic.
But from a security standpoint you can just do the same tracking for the same result. That is just technically a firewall at that point.
I recently changed ISPs and have IPv6 for the first time. I mostly felt the same way, but have learned to get over it. Some things took some getting used to.
An "ip address show" is messy with so many addresses.
Those public IPs are randomized on most devices, so one is created and more static but goes mostly unused. The randomly generated IPs aren't useful inbound for long. I don't think you could brute force scan that kind of address space, and the address used to connect to the Internet will be different in a few hours.
Having a public address doesn't worry me. At home I have a firewall at the edge. It is set to block everything incoming. Hosts have firewalls too. They also block everything. Back in the day, my PC got a real public IP too.
NAT really is nice for keeping internal/external separate mentally.
I'm lucky enough my current ISP does not rotate my IPv6 range. This, ironically, means I no longer need dynamic DNS. My IPv4 address changes daily.
A residential account usually gets a /56, what are you talking about? Nowhere near a /48! (I'm just being funny here...)
There are reasons to need direct connectivity that aren't hosting a server. Voice and video calls no longer need TURN/STUN. A bunch of workarounds required for online gaming become unnecessary. Be creative.
> Having a public address doesn't worry me. At home I have a firewall at the edge. It is set to block everything incoming.
Concern is privacy, not security. Publicly addressable machine is a bit worse for security (IoT anyone?), but it is a lot worse for privacy.
You already have a public IP address the only difference is if you have a rotating IP address which is orthogonal to IPv6.
The only difference is most ISPs rotate IPv4 but not IPv6.
Heck IPv6 allows more rotation of IPs since it has larger address spaces.
IPv4 is not holding back home setups, nobody cares about NAT at home.
The place where it hurts is small VPSs, from AWS to mom and pop hosters, the cost of addresses is becoming significant compared to low cost VPSs.
> nobody cares about NAT at home.
Only because most people don't know how NAT is hurting them, and because corporations have spent incredible resources on hacking around the problem for when peer to peer is required (essentially only for VoIP latency optimization and gaming).
NAT hurts peer to peer applications much more than cloud services, which are client-server by nature and as such indeed don't care that only outgoing connections are possible.
Why, so you can inflict some personal pain on people without IPv6 access?
Surely IPv6 support will spontaneously materialize on their networks once their pain becomes big enough!
Please no. I used to have a Dutch ISP a few months ago that did not support IPv6 yet. (Odido. Same ISP that leaked my data in a big hack.)
Odido is the cheapest ISP for a reason. They refuse to implement anything that isn't strictly required.
Perhaps implementing an Odido tax might actually make Odido care enough to throw the switch on IPv6. They bought 2a02:4240::/32, they just refuse to make use of it.
This reminds me of the ways the governments screw over people to force them to do things they don’t want to.
Annoying things such as paying taxes, recycling/not polluting etc.?
Some things really can only be solved via central coordination, as there is no natural game-theoretic/purely economic path from one local minimum to another. Being able to dig a small trench and letting gravity and water do the rest is great, but sometimes you do need a pump.
I'm not convinced that IPv6 is such a case, but if it is, that's exactly the type of thing governments are much better at than markets.
It will be a neat experiment, but I think most software will break and will remain broken indefinitely and then people will turn to LLMs to try to automate fixing all of it and that will turn into a mess just due to the sheer amount of changes required with little scrutiny.
Perhaps it's time to submit patches that allow building it without IPv6 instead. Countless hours of configuration meddling will be saved.
Not sure if you're taking the piss or just missed it but allowing build with either protocol alone is one of the genuine ideas in this joke:
> Yeah. The date notwithstanding, I do actually think we should do most of this for real.
> Maybe we don't get away with the actual deprecation and the warnings on use just yet, and maybe we won't even get away with calling the config option CONFIG_LEGACY_IP, although I would genuinely like to see us moving consistently towards saying "Legacy IP" instead of "IPv4" everywhere.
> But we should clean up the separation of CONFIG_INET and CONFIG_IPV[64] and make it possible to build with either protocol alone.
Good stuff (both the joke and the genuine proposal of splitting the config options for IPv4 and IPv6).
The best pranks are the ones that succeed to rattle an individual. Build it!
IPv6 vs. 4 is like Python 3 vs. 2, just worse.
And IPv6 vs v4 discussions are just like Python 3 vs. 2 discussions: Often much more annoying than just getting it over with and switching.
great, now can we convince the rest of the internet to start adding AAAA records and ipv6 endpoints for things. Github is still a nightmare to use DNS64 and NAT64 to access those from IPv6 only machines.
Or all the Container based stuff that still falls flat with ipv6 only modes. Docker still shits the bed if you dont give it ipv4 unless you do a lot of manual overrides to things. A bunch of Envoy based gateway proxies fail on internal ipv6 resources in a k8s cluster that runs on ARM64.
There is just a bunch of nonsense you have to deal with if you choose the ipv6-only route
Dont get me started on CDNs like Bunny or Load Balancers as a service like those from Hetzner, UpCloud, etc that don't work with ipv6 origins.
Source: Trying to run a ipv6 only self-hosted box on hetzner.
I've tried to run an IPv6 only box on Hetzner 2-3 years ago. Didn't have a problem with the platform, but with RedHat because subscription-manager didn't work over a IPv6-only stack.
When I accidentally had IPv6 only for a new Windows box it was very apparent what was a priority (worked regardless) and what wasn't important (only began working once I had IPv4 and everything fixed too).
Baked in advertising? Works with any network. The option to turn off the baked in advertising? That needs IPv4.
I honestly think GitHub and AWS are the two biggest blockers to IPv6 left. Sure your public web servers might need IPv4 for a long while yet, but all these backend microservices and CI builds etc could all be v6 only, except they need to pull stuff from GitHub or certain AWS services.
I suppose this will lead to a classic torvalds rant. I will be watching r/linusrants
We’re so close guys! Another 25 years and we might almost be there!