New patches allow building Linux IPv6-only | Hacker News Reader

New patches allow building Linux IPv6-only

phoronix.com

121 pointsBender188 comments

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.

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.

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.

they do use it in their speedtest server.

  curl -v https://speedtest.ams.t-mobile.nl.prod.hosts.ooklaserver.net:8080
  ...
  * Connected to speedtest.ams.t-mobile.nl.prod.hosts.ooklaserver.net (2a02:4240::e) port 8080

Probably a requirement from Ookla, so again "They refuse to implement anything that isn't strictly required".

> They refuse to implement anything strictly required

This describes a lot of businesses ngl.

Bell in Canada is one huge head scratcher. They are one of the largest ISPs here and I can even buy 8 gig internet to my house if I want but they don't support IPv6.

Apparently (according to techs) a lot of ISPs are like that - they said they have everything up and running and even tested to turn on IPv6 but they haven't received the go-ahead.

He mentioned this because marking my connection as a "business" one without changing anything else would allow it to get IPv6 (a /64, bah).

Canadian ISPs are also extremely far behind on IPv6. Bell is the largest ISPs in the country and they still don't have IPv6. I'm with one of their wholly owned subsidiaries (EBOX) which offers static /56 allocations, but good luck trying to find anyone in tech support who understands WTF you're talking about.

- 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.

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.

IPv6 can "leak" MAC addresses of connected devices "behind the firewall" if you don't have the privacy extensions / random addresses in use.

There are a number of footguns for privacy with IPv6 that you need to know enough to avoid.

Privacy extensions are enabled by default on OSX, windows, android, and iOS: https://ipv6.net/guide/mastering-ipv6-a-complete-guide-chapt...

On Linux, I think the defaults are left up to the distros so there is a chance of a privacy footgun there. Hopefully most distros follow the example set by Apple and Microsoft (a sentence I never thought I would write...)

They are now - I'm not sure when they implemented them but I know Windows at least would do some really stupid stuff very early on.

Aren't we talking about now?

No one is saying we should have activated IPv6 in its first iteration.

All desktop/mobile OSes today use "Stable privacy addresses" for inbound traffic (only if you are hosting something long-term) and "Temporary addresses" for outbound traffic and P2P (video/voice calls, muliplayer games...) that change quickly (old ones are still assigned to not break long-lived connections but are not used for new ones).

I'm not confused about the NAT / firewall distinction, but it might be nice if my ISP didn't have a constant, precise idea of exactly how many connected devices I owned. Can that be _inferred_ with IPv4? Yes, but it's fuzzier.

Is this solved by the device having between 1 and X randomly generated IPv6 addresses?

Some of my devices have 1, some 2, and some even more. Takes some precision out, at least.

Aren't your home addresses assigned by your local router?

the ISP can see 58 different ipv6 addresses sending packets in the last hour

With ipv4 it can see one ipv4 address

Now sure that 58 could all be on one device with 58 different IPs and using a different one for each connection

In reality that's not the case.

Okay but why does this matter? They're your ISP they also have your address, credit card number and a technician has been in your home and also supplied the router in the common case.

The theoretical vague problem here is being used to defend a status quo which has led to complete centralization of Internet traffic because of the difficulty of P2P connectivity due to NAT.

No device on my ipv6 vlans can establish P2P tunnels outside with random clients.

Firewalls and good old monetisation prevented your p2p connectivity utopia, not nat.

The ISP still doesn't know how many devices are connected, because a lot of those devices are using randomized and rotating IPs for their outbound connections.

With SLAAC and a random IPv6 you would get at least the same level of privacy. One public IPv4 isn't different from /48 IPv6 network.

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.

Even in a NAT-less world, the common advice is to use a firewall rule that disallows incoming connections by default. (And I'd certainly be worried if typical home routers were configured otherwise.) So either way, you'd need the average person to mess with their router configuration, if they want to allow incoming P2P connections without hole-punching tricks. At best, the lack of NAT might save you an address-discovery step.

> the common advice is to use a firewall rule that disallows incoming connections by default.

That's good advice! But firewall hole punching is also significantly easier (and guaranteed to work) compared to NAT hole punching. Address discovery is part of it, but there are various ways to implement a NAT (some inherently un-hole-punch-able) and only really one sane way to do a firewall.

> you'd need the average person to mess with their router configuration,

At least with IPv6, that firewall is likely to exist in the CPE, which sophisticated users can then ideally open ports in (or which can implement UPnP/NAT-PMP or whatever the current name for the "open this port now!!" protocol of the decade is); for CG-NAT, it's often outright impossible.

UPnP has covered a huge percentage of use cases that actual users care about, and those who it doesn't cover are often able to do their own customization.

upnp should not exist. Any new router default disables it, as it should be.

Care to elaborate? Non-sophisticated users don't deserve IP reachability?

I used to have it enabled long ago. It's insecure. Random cheap devices will open up ports with upnp without the user noticing. It doesn't work that well either, cause hosts will conflict on ports. P2P applications have better ways to establish connectivity.

How can both be true at the same time: It's insecure for random devices to be able to open up ports, and applications don't even need to open up ports for P2P communication?

If a random device/application wants to insecurely communicate with somebody/something, it will find a way, I agree on that.

Hole-punching tricks work fine. They don't work at all of both users are behind IPv4 NAT/CGNAT.

NAT is hurting anyone who has to use CGNAT and share an IP with a bunch of other people.

Plenty of people care about CGNAT making it impossible to connect to them.

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.

NAT is arguably a very broken solution.IPv4 isn't meant to be doing address translation, period. NAT creates all sorts of issues because in the end you're still pretending all communications are end to end, just with a proxy. We had to invent STUN and all sorts of hole punching techniques just to make things work decently, but they are lacking and have lots of issues we can't fix without changing IPv4. I do see why some people may like it, but it isn't a security measure and there are like a billion different ways to have better, more reliable security with IPv6. The "I don't want my devices to have public, discoverable IPs" is moot when you have literally billions of addresses assigned to you. with the /48 your ISP is supposed to assign you you may have 4 billion devices connected, each one with a set of 281 trillion unique addresses. You could randomly pick an IP per TCP/UDP connection and not exhaust them in _centuries_. The whole argument is kind of moot IMHO, we have ways to do privacy on top of IPv6 that don't require fucking up your network stack and having rendezvous servers setting that up.

We may also argue that NAT basically forces you to rely on cloud services - even doing a basic peer to peer VoIP call is a poor experience as soon as you have 2 layers of NAT. We had to move to centralised services because IPv4 made hosting your own content extremely hard, causing little interest in symmetrical DSL/fiber, leading to less interest into ensuring peer to peer connections between consumers are fast enough, which lead to the rise of cloud and so on. I truly believe that the Internet would be way different today if people could just access their computers from anywhere back in the '00s without having to know networking

And the worst part about CGNAT is that you have two bad solutions:

Either EIM/EIF (preferably with hairpinning) where you can practically do direct connections but you have to limit users to a really low number of "connections" breaking power users.

Or EDM/EDF where users have a higher number of "connections" but it's completely impossible to do direct connections (at least not in any video/voice calling system).

Why don't you want every device to have a public IP? There seems to be a perception that this is somehow insecure, but the default configuration of any router is to firewall everything. And one small bonus of the huge size of a /64 is that port scanning is not feasible, unlike in the old days when you could trivially scan a whole IPv4 /24 of a company that forgot to configure their firewall.

NAT may work fine for your setup, but it can be a huge headache for some users, especially users on CGNAT. How many years of human effort have gone towards unnecessary NAT workarounds? With IPv6, if you want a peer-to-peer connection between firewalled peers, you do a quick UDP hole punch and you're done - since everything has a unique IP, you don't even need to worry about remapping port numbers.

Your ISP shouldn't be rotating your /64, although unfortunately many do since they are still IPv4-brained when it comes to prefix assignment. Best practice is to assign a static /56 per customer, although admittedly this isn't always followed.

And if you don't need a /48... don't use it? 99.99% of home customers will just automatically use the first /64 in the block, and that's totally fine. There's a ton of address space available, there's no drawback to giving every customer a /56 or even a /48.

I don’t want some of my devices to be publicly addressable at all, even if I mess up something at the firewall while updating the rules. NAT provides this by default.

I don’t want a static address either (although static addresses should be freely available to those who want them). Having a rotating IP provides a small privacy benefit. People who have upset other people during an online gaming session will understand; revenge DDoS is not unheard of in the gaming world.

> I don’t want some of my devices to be publicly addressable at all, even if I mess up something at the firewall while updating the rules. NAT provides this by default.

This feels like a strawman. If you are making the sort of change that accidentally disables your IPv6 firewall completely, you could accidentally make a change that exposed IPv4 devices as well (accidentally enabling DMZ, or setting up port forwarding incorrectly for example).

As someone who has done this while tired, it’s a lot easier to accidentally open extra ports to a publicly routable IP (or overbroad range of IPs) than it is to accidentally enable port forwarding or DMZ.

You could accidentally swap ips to one that had a port forward, some applications can ask routers to forward, etc etc. I donmt know how exactly we'd measure the various potential issues but they seem incredibly minor compared to the sheer amount of breakage created by widespread nat.

I don’t have any problems with NAT on my network.

You can have IPv6 firewalls emulate the behavior of NAT so it blocks unsolicited inbound traffic while allowing outbound traffic. If you get a /48 form your ISP you could rotate to a new IP address every second for the rest of your life.

Right, but if you’re messing around as a naive learner it’s easy to accidentally disable that or completely open up an IP or range due to a bad rule. It’s a lot harder to accidentally enable port forwarding on a NAT.

> It’s a lot harder to accidentally enable port forwarding on a NAT.

It's probably less than three clicks on most home router web UIs.

Very hard to make all those clicks accidentally. But anyway I’m talking about pf/iptables rules, not web UIs.

But you have to specify not only the exposed port but also the destination address and port which is not easy to do accidentally.

edit: typo

> You can have IPv6 firewalls emulate the behavior of NAT so it blocks unsolicited inbound traffic while allowing outbound traffic.

Are there any (consumer?) firewalls that do not do this? I know Asus do this (and have for years).

AIUI most 'enterprise' firewalls have a default deny shipped from the factory and you have to actively allow stuff.

> I don’t want some of my devices to be publicly addressable at all, even if I mess up something at the firewall while updating the rules. NAT provides this by default.

Do you ever connect your laptop to any network other than your home network? For example, public wifi hotspots, hotel wifi, tech conferences, etc? If so, you need to be running a firewall _on your laptop_ anyway because your router is no longer there to save you from the other people on that network.

It's also a good idea even inside your home network, because one compromised device on your network could then lead to all your other firewall-less devices being exploited.

Not every device can run its own firewall. IoT devices, NVR systems, etc should be cordoned off from the internet but typically cannot run their own firewall.

Sure, but they sit on an iot vlan where your firewall prevents access except specificly allowed services

You must have not read my original post. I said that the NAT provides an additional fallback layer of safety in case you accidentally misconfigure your firewall. (This has happened to me once before while working late and I’ve also seen it in the field.)

Most public wifi has client isolation enabled for this reason. Firewall or not, you can't communicate with other clients.

Only if they're set up properly, which is quite the gamble. I was recently in a hotel and I listed all the chromecast devices throughout the entire hotel. I could see what everyone was watching and if I was a lesser person I could have controlled their TVs or changed what they were watching.

What about device like those Chromecasts which don't even have firewalls? The only real solution would be to bring your own hardware firewall / access point and connect it as a client off the hotel wifi. Who is really going to do that?

> hollowing can crash the target process if the payload isn't carefully matched to the host process architecture.

So here's the thing. My ISP does _not_ rotate my IPv4 address, but _does_ rotate IPv6. Why? I'll never know.

Anyhow. I'm not confused about NAT vs. firewalling. No one who dislikes IPv6 is confused by this.

> Anyhow. I'm not confused about NAT vs. firewalling. No one who dislikes IPv6 is confused by this.

"No one"; LOL. I've participated in entire sub-threads on HN with people insisting that NAT = security. I've cited well-regarded network educators/commentators and vendors:

* https://blog.ipspace.net/2011/12/is-nat-security-feature/

* https://www.f5.com/resources/white-papers/the-myth-of-networ...

That article is making a narrower claim than you're implying. It argues that NAT is not a security mechanism by design and that some forms of NAT provide no protection, which is true.

It also explicitly acknowledges that NAT has side effects that resemble security mechanisms.

In typical deployments, those side effects mean internal hosts are not directly addressable from the public internet unless a mapping already exists. That reduces externally reachable attack surface.

So, the disagreement here is mostly semantic. NAT is not a security control in the design sense, but it does have security-relevant effects in practice.

I personally do consider NAT as part of a security strategy. It's sometimes nice to have.

Both of those articles are actually wrong. They say "if an unknown packet arrives from the outside interface, it’s dropped" and "While it is true that stateful ingress IPv4 NAT will reject externally initiated TCP traffic" respectively, but this is in fact not true for NAT, which you can see for yourself just by testing it. (It's true for a firewall, but not for NAT.)

The biggest security-relevant effects of NAT are negative. It makes people think they're protected when they aren't, and when used with port forwarding rules it reduces the search space needed to find accessible servers.

I agree it can be a useful tool in your toolbox sometimes, but a security tool it is not.

[flagged]

You can't correlate the number of addresses with the number of devices because IPv6 temporary addresses exist. If you enable temporary addresses, your computer will periodically randomly generate a new address and switch to it.

https://www.rfc-editor.org/rfc/rfc8981.html

[flagged]

Temporary addresses are enabled by default in OSX, windows, android, and iOS. That's what, like 95% of the consumer non-server market? As for Linux, that's going to be up to each distro to decide what their defaults are. It looks like they are _not_ the default on FreeBSD, which makes sense because that OS is primarily targeting servers (even though I use it on my laptop).

Temporary addresses are used by any Linux distro using NetworkManager (all desktop ones). For server distros, it can differ.

In Gnome it's just a toggle in the network settings

and most OS do enable it by default

> ALL THE HEAVY LIFTING THERE

> MUCH MORE IMPORTANT

I haven't done the exhaustive research but props in advance for being the only person shouting in caps on HN. Definitely one way to proclaim one's not AI-ness without forced spelling errors.

Didn't even think about that. Interesting.

I feel like this is a silly narrowing of the problem for normal, retail users. My priority isn't masking "the number of addresses" or devices. My desire is to not have a persistent identifier to correlate all my traffic. The whole idea of temporary addresses fails at this because the network prefix becomes the correlation ID.

I'm not an IPv4 apologist though. Clearly the NAT/DHCP assignments from the ISP are essentially the same risk, with just one shallow layer of pseudo-obscurity. I'd rather have IPv6 and remind myself that my traffic is tagged with my customer ID, one way or another.

Unfortunately, I see no real hope that this will ever be mitigated. Incentives are not aligned for any ISP to actually help mask customer traffic. It seems that onion routing (i.e. Tor) is the best anyone has come up with, and I suspect that in today's world, this has become a net liability for a mundane, privacy-conscious user.

> The whole idea of temporary addresses fails at this because the network prefix becomes the correlation ID.

So the same as the public IPv4 on a traditional home NAT setup?

Most home users do not have a static public IPv4 address - they have a single address that changes over time.

But most ISPs aren’t giving out static IPv6 prefixes either. Instead they are collecting logs of what addresses they’ve handed out to which customer and holding on to them for years and years in case a court requests them. Tracking visitors doesn’t need to use ip addresses simply because it’s trivial to do so with cookies or browser fingerprinting. There’s exactly zero privacy either way.

> Instead they are collecting logs of what addresses they’ve handed out to which customer and holding on to them for years and years in case a court requests them.

They are only supposed to hang on to them for a limited time according to the law where I live (six months AFAIK). Courts are also unwilling to accept IPv4 addresses as proof of identity.

> Tracking visitors doesn’t need to use ip addresses simply because it’s trivial to do so with cookies or browser fingerprinting

Cookies can be deleted. Browser fingerprinting can be made unreliable.

Its not zero privacy either way. Privacy is not a binary. Giving out more information reduces your privacy.

> Most home users do not have a static public IPv4 address - they have a single address that changes over time.

I'd be curious to know the statistics on this: I would hazard to guess that for most ISPs, if your router/modem does not reboot, your IPv4 address (and IPv6 prefix) will not change.

[flagged]

> My desire is to not have a persistent identifier to correlate all my traffic.

Reboot your router. Asus (with the vendor firmware) allows you do this in a scheduled manner. You'll get a new IPv4 WAN IP (for your NAT stuff) and (with most ISPs) a new IPV6 prefix.

As it stands, if you think NAT hides an individual device, you may have a false sense of security (PDF):

* https://oasis.library.unlv.edu/cgi/viewcontent.cgi?article=1...

Many routers don't firewall by default. Lemme check later, but pretty sure my basic ASUS router doesn't either.

> Why don't you want every device to have a public IP?

What would be the advantage in it?

Trivially easy do direct connections between devices (if desired), no issues when creating VPNs between networks using private ranges.

What would be the disadvantage?

Well, the disadvantage would be that it would be really difficult to do direct connections between devices.

I don't want VPNs between private ranges.

I don't want publically-routable IP addresses on anything.

>> Why don't you want every device to have a public IP?

> What would be the advantage in it?

Not having to deal with ICE/TURN/STUN. Being able to develop P2P applications without having to build out that infrastructure (anyone remember Skype's "supernodes"?).

This is not something I ever want any device on my network to do.

It's about being able to run apps that can operate without have an HQ that needs to be phoned home to for operation, which is currently generally necessary with NAT.

> Why don't you want every device to have a public IP?

Big companies would abuse that beyond belief. Back around the late 90s ISPs wanted to have everyone pay per device on their local networks. NAT was part of what saved us from that.

IMO, IPv6 should have given more consideration to the notation. Sure, hex is "better in every way" except when people need to use it. If we could just send the IPv6 designers back in time, they could have made everyone use integer addresses.

    # IPv4 - you can ping this
    ping 16843009
    # IPv6 - if they hadn't broke it :-(
    ping 50129923160737025685877875977879068433
    # IPv7 - what could have been :-(
    ping 19310386531895462985913581418294584302690104794478241438464910045744047689

It's simple, unambiguous, and scales infinitely.

> Back around the late 90s ISPs wanted to have everyone pay per device on their local networks. NAT was part of what saved us from that.

But with IPv6 a single device may have multiple addresses, some of which it just changes randomly. So this idea that they'll then know how many devices you have and be able to pay per device isn't really feasible in IPv6.

A single /64 being assigned to your home gives you over 18 quintillion addresses to choose from.

If the ISP really wanted to limit devices they'd rely on only allowing their routers and looking at MAC addresses, but even then one can just put whatever to route through that and boom it's a single device on the ISP's lan.

It's simple, unambiguous, and scales infinitely

This is a joke right? How does it "scale infinitely"? It is clearly ambiguous in your ipv7 example.

> Why don't you want every device to have a public IP?

Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.

> With IPv6, if you want a peer-to-peer connection between firewalled peers, you do a quick UDP hole punch and you're done - since everything has a unique IP, you don't even need to worry about remapping port numbers.

There is no guarantee with IPv6 that hole punching works. It _usually_ does like with IPv4.

> Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.

The answer here is kinda that Wi-Fi isn't an appropriate networking protocol for lightbulbs (or most other devices that aren't high-bandwidth) in the first place.

Smart devices that aren't high bandwidth (i.e. basically anything other than cameras) and that don't need to be internet accessible outside of a smart home controller should be using one of Z-Wave/Zigbee/Thread/LoRaWAN depending on requirements, but basically never Wi-Fi.

Silliness of smart bulbs aside, I would hope the answer is how ipv6 is actually safe for this, not that you should just not use wifi.

Well Thread uses ipv6 in a safe way for this, nobody ever complains about how they wish their Thread network only used ipv4. :)

> Suddenly, your smart lightbulb is accessible by everyone.

A firewall solves that issue, IPv4 or IPv6.

A lot of people, even on HN, mistake "addressable" for "accessible".

It's because router defaults have been bad for a long time and NAT accidentally made them better.

I finally have IPv6 at home but I am being very cautious about enabling it because I don't really know what the implications are, and I do not trust the defaults.

>> Why don't you want every device to have a public IP?

> Suddenly, your smart lightbulb is accessible by everyone. Not a great idea.

Why would it be "accessible by everyone"? My last ISP had IPv6 and my Asus (with the vendor firmware) didn't allow it. My printer automatically picked up an IPV6 address via SLACC and it was not "accessible by everyone" (I tried connecting to it externally).

My ISP doesn't rotate my /48

However if I change my ISP I get a new one, and that means a renumbering.

So run fc00::/7 addresses with IPv6 NAT.

That addresses all of your concerns, and you have that option.

But that doesn't allow to bitch about it so - no.

Sure you can do that

So what's the point in ipv6?

You can do fc00::/7 in addition to public addresses so your lights don't have public address while your phone does.

I mean, so many reasons. Not the least of which is carrier grade NAT is out. And that alone implies so much cost savings, performance increase, and home user flexibility .

I'm struggling to assume good faith on your question, since it's so strange. I feel like I need to start from scratch explaining the internet, since asking this question reveals a lack of knowledge about everything networking.

I don't have CG Nat, I choose a proper ISP. Opening a hole in my ipv6 firewall or forwarding a port in in my ipv4 firewall is effectively the same thing, I define the policy (allow traffic arriving on $address on tcp/1234 to this server on vlan 12) and it goes live.

Away from home, like I am at the moment, I vpn all my traffic back home, to work, or to a mullvad endpoint. Neither the hotel wifi nor tethering off my phone gives me a working ipv6 address (anything other than an fe80::) anyway.

All my workflows work on ipv4 only. Some workflows (especially around the corporate laptop) don't work on ipv6 only - maybe that's a zscaler thing, maybe its a windows thing.

As such the only choice is ipv4 with ipv6 as a nice to have, or ipv4 only.

Personally I prefer the smaller attack surface of a single network protocol.

Sounds like ipv6 is a good solution for people who choose ISPs with CGNat. It doesn't matter to me if I vpn home via my ipv6 endpoint or my ipv4 endpoint, I expose a very minimal set of services.

I guess if I wanted to host more than 4 servers on the same port at home it would be handy, as my ISP will only allow me to have 4 public IPs without paying for more. I don't host anything other than my wireguard endpoint and some UDP forwards which I specific redirect to where I want to go (desktop, laptop, server) - another great feature of nat, but yes nat66 can do that too.

But where's the killer feature of ipv6. Is it just CGNat on poor ISPs?

I'm not sure where that long story is supposed to convey. Cool story, bro.

> Sounds like ipv6 is a good solution for people who choose ISPs with CGNat.

I mean… this is just "not even wrong".

> Is it just CGNat on poor ISPs?

I already said no to this.

Look, like I said, you appear to be unaware of so much about everything about the Internet, running an ISP, running a service provider, corporate networks, ISP-customer relationships, small businesses, BGP viable policies, cloud economics, etc… that it's hard to know where to even start. And while HN is great for some things, HN comments are just not suitable for something that is shaped more like a course or internship. This can't even be described as "gaps" in your knowledge.

I'm put off by your confidence without the knowledge, and of course also by your implication that if you have CGNat then you should have just worked a little harder to not be so poor, to pay a better ISP, or you should move to a more expensive place where other ISP options exist. Of course ignoring that this doesn't scale to the population at all, and extra address bits are very relevant to scaling.

I don't directly deal with public peering, I leave that to my colleagues, my only practical BGP knowlege is on private ASes.

Your shitty ISP doesn't give you an ipv4 access, that's fine. ipv4 address blocks cost $20 an address and are cheaper today in real terms than in 2016, and have been coming down in nominal terms for years.

ipv6 makes sense at a global scale, it still makes no sense for many individuals with a good ISP, mainly because of how it was implemented, too much stuff still relies on ipv4. If you have to also run ipv4 then why run ipv6.

I have no services I use that are ipv6 only

I have services that are ipv4 only, so I have to run a 6:4 nat

I want a stateful firewall because it's not 1999

I want to handoff to multiple consumer ISPs, using PBR, not running BGP, so I need to use NAT66 (changing IPs isn't good enough, I want to round-robin based on various rules, send traffic to dropbox via one ISP, send udp via another, etc)

I have software which doesn't work on ipv6 on a client, so I have to run CLAT on the device

But not all my local devices can run CLAT, I thus have to run dual stack to use ipv6 successfully.

Thus as I'm running ipv4 anyway, and running NAT, there is no benefit over running ipv4 only. IPV6 adds more things to go wrong (NAT64/DNS64), but offers no benefits.

Even without the ipv6 client requirement I still need to run both NAT64 and NAT66. I have an ipv6 only network at home which I put phones on. It works, but there's no benefit other than keeping awareness of ipv6.

Now sure, the reason that ipv4 addresses are cheap is because other people are moving to ipv6 (especially mobile), and relying on 464 gateways, with 46 in their CPE and 64 on the ISP level. That's great.

But that doesn't change the equation for someone with a choice of ISPs, as they can choose an ISP which provides them with static ipv4 addresses.

Address space isn't the only benefit.

I'll just leave this here if you want to find out https://www.catchpoint.com/benefits-of-ipv6

That would be fine if it were default. My router doesn't even have that option.

NAT is a horrible, HORRIBLE hack that makes everything in networking much more complicated. IP networking is very elegant when everyone is using globally unique addresses and a ugly mess when Carrier NAT is used.

NAT demonstrably does not work fine. We have piles of ugly hacks (STUN, etc) that exist only because NAT does. If you really want to keep NAT then nothing stops you from running it on IPv6, but the rest of us shouldn't suffer because of your network design goals.

> I like NAT

I'm in favor of having society overrule you. NAT is a horrible kludge and not okay. Never was.

How is a public address any worse than NAT? You can always choose to not respond.

Maybe you don't need the addresses, but there are other advantages. If we made the move, I suspect we could give you the experience you want and the one I want. I personally do want to host my own services. My phone is configured to send my pictures to Google and my personal NAS. Centralized services mean you have to trust that provider. These days I don't. I intend to leave centralized services so I know my content isn't training AI or the doorbell isn't spying on me or my neighbors. But, no instead we should force everyone to share the same IP addresses and run less efficient routing.

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!

I am running IPv6 only servers, and I think it's fair that v4 only people feel the same pain some time in the future.

IPv6: only better than v4 if you kneecap v4, even then maybe not

It’s not implemented in the Linux kernel, but the latency penalty you’re describing is part of the “Happy Eyeballs” algorithm: https://en.wikipedia.org/wiki/Happy_Eyeballs

As sad as it makes me to admit, I don't think IPv6 is ever going to happen without government intervention. Adoption is flat at under 50% over the past year. IPv6 doesn't benefit big tech. SNI routing and NAT work pretty well for centralized platforms. AWS will gladly rent us IPv4 addresses until the end of time.

> IPv6 doesn't benefit big tech.

It does, and big tech has largely adopted IPv6.

For users with IPv6, the v6 path is often less constrained than then v4 path. Serving data faster/more consistently is of benefit to big tech. For a lot of users, v4 and v6 routing are different, which is also helpful for big tech. If you have two paths to the server (and happy eyeballs or something), you have more resiliance to routing issues.

Clouds are slow on v6, but CDNs are not. Adoption on eyeball networks has been very slow, and it's unlikely to speed up much, IMHO. The benefits of v6 for ISPs are not that big for established serviced with large v4 pools. For ISPs running CGNAT, more v6 means less CGNAT and CGNAT is a lot more expensive than plain ip routing. (Doesn't mean all CGNAT providers run v6, but it's an incentive).

SNI routing is such a bad way to do what should be L3 problem that people implemented PROXY protocol to send information about user's endpoint address without doing MITM.

The Internet itself is growing, so "50%" does still represent a growing number of users. Also Google's stats are missing half a billion v6 users from China.

Another way to do ipv6 without government intervention is to make it 1. actually what people want, just v4 with more bits 2. have a reasonable migration path from v4. They made something overcomplicated that disregards all existing users, and now they act like this was the only possible way to avoid address exhaustion and it's everyone's obligation to switch. Even if the govt successfully forced v6, it'd be a downgrade.

v6 mostly is just v4 with more bits, and it has a reasonable migration path from v4 too. I don't think a more reasonable migration path is even possible given the constraints of v4.

About the only thing new in v6 that's not already in v4 is SLAAC, which isn't very complicated. Routing works the same, the addresses work the same, DNS, TCP, firewalling etc all work the same. If anything they removed complexity by dropping broadcast and making NAT unnecessary.

People just have some very weird misconceptions about v6, and will frequently argue that e.g. it was badly designed for not doing a thing that it does actually do, or for not doing something impossible.

The biggest thing is all the v4 addresses are no longer valid in v6. They had a choice and went with making a separate parallel network with new routes. This means DNS DHCP etc work similarly but are completely different, and the separation between DNS v4 and v6 of course is never clear in any router UI, network config file, etc. And the routes themselves are different.

SLAAC itself isn't complicated, but it means introducing multiple kinds of addresses, which is complicated. Privacy addresses were the latest thing. The history of this has left the defaults in a wacky state, like I got a new router and idk what to expect if I enable v6 on it. Even disabled v6 on my laptop cause idk what it'll do when I join someone else's network. Default should've just been DHCP+NAT from the start, not a loaded gun aimed at foot.

And SLAAC means random addresses that are human-unreadable. "Just use DNS" but nah, nobody will do that.

  ::203.0.113.42 (tunnels to 203.0.113.42 over v4)
  ::ffff:203.0.113.42 (opens a v4 connection via an AF_INET6 socket)
  64:ff9b::203.0.113.42 (translates to v4 at nearest NAT64 point)

What are these then? Also, it's not like they had a choice here. v4 is hardcoded to 32 bits, so the option of making a single network with a bigger address size wasn't available.

I think I can count that as falling under both "something it already does" and "something that's impossible".

Your laptop will just get some IPs as appropriate for the network it's on, and then it'll use them. You don't need to think hard about it.

> enjoy if there was a manually induced latency penalty for "legacy IP" that needs to be manually turned off on Linux

That sounds so bad, it probably will be a windows feature.

> I would actually enjoy if there was a manually induced latency penalty for "legacy IP" that needs to be manually turned off on Linux

Use the source, Luke. Why not start with yourself ?

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.

The main thing I don't like is type-ability. Even now I type in 192.168.1.14 to connect to my mates computer to play satisfactory. No way in heck am I trying in an ip6!

Hmmmm maybe someone should come up with a SYSTEM to organize NAMES for ips, maybe using hierarchical DOMAINs.... Oh wait.

Your bad attempt at humor makes it quite clear that you've never dealt with network engineering or administrating to any extent.

Admitting that ipv6 has some downsides, however minor they may seem to you, won't hurt your quest to render ipv4 obsolete.

In fact being less insufferable is how you win people to your causes, not by laughing at their genuine albeit minor issues.

They were making a legitimate point a humorous way. The problem of manually typing in IP addresses has been solved by DNS for over 50 years.

I haven't had to type an IP address to access something on my home network for at least a decade, except for (occasionally) my xxx.1 router.

We could abbreviate that to SND!

how about just having zeroconf on and using .local domains?

Why not just type in "mates-pc" and have functional mDNS and not have to memorize a bunch of numbers?

Why not just expect your OS's DNS setup to actually just work?

Because mDNS usually doesn't work and just expecting it to work doesn't change that?

> Why not just expect your OS's DNS setup to actually just work?

Maybe use an OS or DNS stack that isn't terrible?

Incredible asking for a not-broken DNS and IP stack is just too far out there when it seems most of the closed source OS platforms seem to manage just fine.

Or let me guess, you've specifically configured it to not "leak" such useful information?

Skill issue. Works fine for me in a mixed Linux/Apple environment.

I didn't write any mDNS software. Blame those guys.

Well I mean “those guys” did a good job and the network administrator might need to do some debugging.

I never have to debug why my dhcp server isn't handing out ipv4 addresses or deal with conflicts, but if I did, it'd break mdns too. mdns is an extra moving part to deal with.

I've had numerous issues with dhcp servers over the years and clients not understanding their responses. Acting like they never have issues is just burying your head in the sand. mDNS often works just fine on most common OSes, if you don't explicitly block them.

Default home router out of the box is not going to have DHCP issues. Custom config or bigger network, sure, I've dealt with it too.

By debugging I mean just checking if you have not blocked broadcast packets at the firewall or some similar misconfiguration. I doubt it’s actual bugs when it doesn’t work. On your second point, it’s actually more resilient than DHCP because it works with IPv6 too.

Idk, just checked my LAN-connected Mac's arp tables now and none of the hostnames are there, even after I ping the multicast. Haven't messed with any settings.

Does anything respond to the multicast ping? If that doesn’t work then mDNS isn’t going to either. Router config is the likely culprit.

Yeah they respond. `ping mdns.mcast.net`, shows responses from ip addresses I recognize on my LAN, `arp -a`, still no hostnames. Tried all the other suggestions online too. Tried on my Mac and Rpi, same network, just a single ethernet LAN.

Router is all default except that I port-forwarded something. Funny enough, it sees the hostnames. I'm guessing it's some problem with both my computers, but no real need to fix this because I memorized the addrs already.

What network administrator?

No way in heck are you typing fd00::d or similar? Why not?

I recently learned I can skip middle .0's in IPv4, no more 192.168's for me it's 10[.0.0]'s going forward.

I wish I had your problems. :D . Problems that are really only a mild inconvenience, and can be solved with a single line in hosts file.

My biggest and possibly only problem preventing me from going IPV6-only is that Github doesn't support it, and there's just too much darn software I need to needs Github. (Yes, I know NAT64 exist - it's just extra complexity for something that is not even my problem in the first place).

When I was in grade school I did a presentation on ipv6 and how it was the future of the Internet. That was like 20 years ago.

Good stuff (both the joke and the genuine proposal of splitting the config options for IPv4 and IPv6).

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.

This. Sure there are still some applications that might be difficult to v6 enable, so either patch it or use one of the myriad of options to give it a v6 front end.

It would've been less annoying to not do a breaking change from Py2 to 3. JS never had a breaking change like that.

There are genuine improvements in IPv6 aside from the abundance of addresses. The two that immediately come to my mind are:

1. SLAAC means routers no longer need to keep a record of each client on the network. With DHCP, the router had to maintain a table of which addresses had been assigned and getting an address involved 2-way communication. With SLAAC the router just periodically broadcasts the prefix to the network and any device that wants an address can just listen to that broadcast and assign themselves an address within that prefix without having to inform the router and without the router needing to maintain a table of assigned addresses. (2-way communication is still possible since devices can solicit a broadcast but it is not necessary)

2. With IPv6, middleboxes are no longer allowed to fragment packets. The only device that can fragment a packet is the original sender. If any segment along the path has a lower MTU than the size of the packet, the original sender is notified and then they can fragment the packet.

Python 3.7 or Python 3.8 ? /s

I would like this option, to make it easier to run a CI environment truly IPv6-only. As in socket() to create a v4 socket should fail.

seccomp could only do this partially, in that there are other avenues (e.g. io_uring), and I want it to be the case throughout the boot process.

Creating a v4 socket should map to a v6 address lower down, making v6 transparent to v4 only applications.

The best pranks are the ones that succeed to rattle an individual. Build it!

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!

It's already the major protocol in many countries. A decade ago people were laughing, saying IPv6 will never break 10% adoption. Now it's 50% and somehow people are still making the same joke. Are we insidiously shifting the goalpost somehow?

I don't know 'bout you but ots of services are confident enough in the technology to allow IPv6-only as an option, see eg. Hertzner.

At this point one has to be borderline delusional to think IPv6 is only viable in another 25 years.

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.

Around the same time, I think the Photoprism image also didn't work on IPv6 because of Traefik

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.

It's particularly aggravating with AWS, since they charge for IPv4 addresses yet many of their services aren't IPv6 capable.

They do seem to be making progress on that: https://aws.amazon.com/new/?ams%23article-feed%23pattern-dat...

They've enabled v6 on an average of something like two services per week for the past year... but they have a lot of services.

This may be a “joke”, but it’s disturbing to see people clamoring to deny others their freedom in a FOSS context.

Want to use IPv6? Fine. But don’t try to remove v4 support from people who have built stable networks around it.

You won’t be able to force the world to switch to IPv6 with tricks like this, any more than you can force old industrial machines to stop using ancient 486es as controllers. There is a lot of old equipment in the world.

IPv6 was built to work alongside v4, and there is no reason to change that.

> it’s disturbing to see people clamoring to deny others their freedom in a FOSS context

How does "allow building Linux to be IPv6-only" somehow "deny others their freedom" exactly? I'm willing to wager most distributions will still be dual v4+v6, but if they aren't, isn't that something for you to bring up with your distribution rather than that the kernel just allows something?

Coupling this patch with language about “legacy IP”, along with the follow up comments from the person who submitted the patch, it is clear that the submitter is hostile towards IPv4. I also see hostility towards IPv4 in the comments here and other similar discussions.

I have no problem with allowing optional IPv4 or IPv6 only builds as long as both are kept well-maintained.

> it is clear that the submitter is hostile towards IPv4

But so what? It still doesn't remove v4, in any shape or form, and if that was proposed to the kernel, I'm again fairly confident it'd be rejected.

> I also see hostility towards IPv4 in the comments here and other similar discussions

Ah, yeah that might be. I just saw your comment first, with no context of what you were actually answering, so it kind of looks like you're replying "to the submission", which really isn't denying any freedoms, I guess I was confused about that, my bad. Still, wouldn't it be better to answer directly to those comments, rather than "replying" to an argument/debate that is actually happening elsewhere?

Somehow IPv4 versus IPv6 has become one of those noxious political-technical debates like Android versus Apple or GPL versus BSD/MIT, in which both sides are dug in and think that the other side must be destroyed.

The reason that I don’t like seeing patches like this, even as a “joke”, is that there are real people who would like to see IPv4 removed (possibly by government intervention) in order to achieve their dream of an IPv6 only internet. The whole idea is preposterous, but here we are. It’s about as realistic as banning cars but that doesn’t stop the endless flame wars about it.

Someone has to step in to point out that v4 and v6 were designed to coexist, this is fine, please don’t remove common standards for your personal preferences.

*removed comment. I didn't know this was an April fools joke. sorry for my lack of a clue....

The patchset is an April fools joke and even then it's not going this far.

What? Freedom to opt in or out is good either way.

v6 was meant to succeed v4, not work alongside it. https://datatracker.ietf.org/doc/html/rfc8200#section-1

Reply on news.ycombinator.com