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

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

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

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

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

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

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

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

reply