[bryden_cruz]

I recently had to set up basic IP-based country detection in Nginx for a project. Parsing and handling IPv4 is trivial. The second I had to account for IPv6 string formats and update the Geo databases to match, the complexity just spiked for no good reason. It feels like we traded address exhaustion for parsing nightmares.

[threiw]

On one of my linux machines the "localhost:8080" did not work after new installation. It resolves to local ipv6 address, while server only listened on ipv4.

After this I go out of my way to disable, remove and nuke ipv6, out of every setup and deployment I do. Ipv6 is already quite complicated, but supporting TWO competing network stacks, with complicated pseudo compatibility, just multiplies unnecessary complexity!

[eqvinox]

Or, you could've fixed your server's configuration. Probably would've been faster than to "disable, remove and nuke ipv6". In general, the mistake is that it says "0.0.0.0" or "0.0.0.0:8080" somewhere where it should really say "::" or "[::]:8080".

(IPv6 sockets by default accept IPv4 connections, unless you disable that either system-wide or on the specific socket.)

By the way, I do agree the colon was a really poor choice for separating the blocks, when it is also used to separate the port number.

[threiw]

I fixed the problem once for all. Now my program even refuses to start, if IPv6 is enabled. I am not going to spend time debugging problem, that can be easily prevented. Pretty valid solution on private networks and local only kubernetes deployments.

If customer wants proper ipv6 support, we can sign a contract and talk about it. But do not expect me to support some technology for free, just because it is enabled by default.

[eqvinox]

Nah, you didn't fix anything, you just moved the problem around.

(Worst case, you moved the problem to your finance department, for buying IPv4 address space. But even if you didn't do that, at some point sooner or later you'll get pressure to support IPv6. And then you'll have to "un-fix" everything you did, and fix the actual problem. Maybe it'll be after you're retire, but I wouldn't take bets on that.)

[ed.: best case, you moved the problem to someone else outside your company or scope. Good for you, I guess. Like the sibling post says, address space shortage is an issue for everyone, and personally speaking I would consider it rude to make it other people's problem.]

[threiw]

As I wrote, we use internal networks and k8s. Most of our nodes can not even access internet. I would welcome pressure to support ipv6, it means juicy fresh contract and money.

> you didn't fix anything, you just moved the problem around.

I do not get this attitude "ipv6 is inevitable". So far no customer even asked about it. We have way more urgent problems like cloudflare blocking, ddos from clankers, state regulations...

If the problem actually becomes real in like 20 years. The clankers will probably solve it in like 10 seconds. There is zero benefit right now to deal with headaches of dual routing and addressing.

[hnfong]

> at some point sooner or later you'll get pressure to support IPv6

I've been told that for 20+ years. Nothing has changed.

[orangeboats]

Did you just miss the headline a few days ago, that IPv6 adoption has reached 50%?

You might be right if IPv6 adoption stayed at 10% or so. But the current trend suggests that sooner or later someone is going to demand IPv6 support on your side.

[john01dav]

This attitude is widespread enough to hold the world back by forcing everyone who interacts with the public Internet to support ipv4 (some technology), "for free". So, either way, we're forcing one of them. So, we might as well lean towards supporting the one that isn't hard capped at 4 billion addresses in a world with at least 2x as many devices. Have you ever tried to deal with NAT punchthrough? That's way more difficult to fix than having to properly configure your server.

[threiw]

> Have you ever tried to deal with NAT punchthrough? That's way more difficult to fix than having to properly configure your server.

Yes I did, and I no longer support that either. For my setups it is local private ipv4 networks all the way now! How tailscale or other VPN deals with that is not my problem!

If two nodes are on different networks, they should not be allowed to talk to each other anyway. Seems like security risk! Clean design, simple rules!

[estimator7292]

You are so very incredibly wrong about absolutely everything here.

[9dev]

> If two nodes are on different networks, they should not be allowed to talk to each other anyway.

We are so lucky people like you aren't in charge, or we wouldn't have the internet in the first place.

[eddythompson80]

Yeah, I’ll sign a contract so you can “support” a configurable bind address. That’s post-doc level of comp-sci stuff right there.

I’ll also sign the “numbers bigger than 2^32” contract and a “weird looking characters in text” contract.

[orev]

What you seem to be misunderstanding is that your whole process of nuking IPv6 is more work than studying the issue for a few minutes and then listening on both protocols. Setting a service to listen on a port will use both IPv4 and IPv6 by default, and if yours isn’t means you’re probably already doing something wrong or also have other bugs.

[themafia]

inet_pton/inet_ntop handle AF_INET6.