Using the Internet without IPv4 connectivity

I have strong opinions about ipv4, especially since I'm forced to use an ipv4 isp. The lack of ipv6 adoption should be considered one of the great failures of tech. Who actually is responsible? Is it router manufacturers writing poor quality firmware, ipv4 advocates in leadership positions at isps, ipv4 address speculators, poor training of network engineers and tech support staff? I think we all need to have a much greater discussion with the internet at large and not just on isolated web posts and subreddits.

For comparison, the internet mostly transitioned off of TLS 1.0 just fine, why can't we do the same for transitioning off ipv4? Maybe AI powered proxies for legacy code perhaps?

We have a saying in the industry… IPv6 is an academic solution to an engineering problem. The reality is it’s just too damn complicated to implement and maintain at scale while also retaining compatibility with v4… which is never going to go away because other than the address shortage, there are no problems with it.

It's just a lot of work/churn with little to no concrete benefit for many people involved. There is no IPv4 cabal.

We have no such saying in the industry. IPv6 is generally easier to implement and maintain. If IPv6 were the incumbent and someone came in proposing IPv4, they’d be laughed out of the room for its ridiculousness. “You have to run a stateful server just to assign addresses? Dynamic header length? A tiny address space? And tell me again about this NAT thing, LOL.”

V6 was designed by the engineers who realized what they got wrong in V4.

IPv6 is not actually hard to implement or maintain. A lot of people have repeated that meme, but it isn't true at all.

You still need a stateful server to assign IPv6 addresses for most use cases, through DHCPv6. SLAAC doesn't even give you a DNS server yet. And even if it did, many ISPs assign too small address spaces for SLAAC, or your networks isn't so simple that you can just auto-negotiate some address.

> For comparison, the internet mostly transitioned off of TLS 1.0 just fine, why can't we do the same for transitioning off ipv4?

This is a great demonstration of the advantages of the end-to-end principle. The reason the transition off TLS 1.0 (and earlier SSL 3.0) could happen so quickly is that only the endpoints (the server and the client) needed to be updated to understand the new protocol; nodes in the middle of the path (routers, switches, and so on) only needed to care about the IPv4 (or IPv6) layer, which didn't change with new TLS versions.

But that only works for layers above the network protocol; when updating the network protocol itself, every node is affected.

(And the TLS transition also took longer than it should, in large part because a lot of "middleboxes" violated the end-to-end principle by inspecting or even modifying the TLS connection, without taking part in the protocol negotiation. TLS 1.3 had to be modified to pretend to be a resumed TLS 1.2 connection to trick these middleboxes into not incorrectly rejecting the newer version of the protocol.)

1. You have been able to assign DNS through SLAAC for years 2. Stateless DHCPv6 serves most needs not covered by SLAAC 3. Yeah, some ISPs screw up and don’t assign enough address space. Most likely because they’re still in the address-poverty mindset of v4

> your networks isn't so simple that you can just auto-negotiate some address

I don’t understand what you mean by this…v6 afaik has every tool that v4 does for assignment. If automated assignment through SLAAC or either kind of DHCP doesn’t meet your needs, then there’s manual assignment, just like with v4.

Okay, then please reimplement the equivalent of the following code to work with both IPv4 and IPv6:

    int fd = socket(AF_INET, SOCK_STREAM, 0);
    struct sockaddr_in addr = { .sin_family = AF_INET, .sin_port = htons(1234) };
    addr.sin_addr.s_addr = htonl(INADDR_ANY);
    bind(fd, (struct sockaddr*)&addr, sizeof(addr));
    listen(fd, 128);
    int client;
    while (client = accept(fd, 0, 0)) {
        // ...
    }

Stop spreading misinformation.

> You still need a stateful server to assign IPv6 addresses for most use cases, through DHCPv6. SLAAC doesn't even give you a DNS server yet.

DNS now comes in Router Advertisement per RFC 8106. No need for DHCPv6 anymore.

> And even if it did, many ISPs assign too small address spaces for SLAAC, or your networks isn't so simple that you can just auto-negotiate some address.

Most residential ISPs allocate in /48, /52, /56, or /60. Even if they allocate in the smallest /64, it's still perfectly fine for SLAAC for most home users utilizing a single subnet.

> transitioned off of TLS 1.0 just fine

The difference is only the end client and server need to support TLS, all the middleware and networks between just see TCP packets and do not have to be privy to what TLS version is being used.

IPv6 on the other hand has to be supported by every middleware box between the client and the server and therefore its functionality is limited by the lowest common denominator.

Additionally TLS upgrades were largely drop in, whereas IPv6 changed too many things at once to be easily adopted.

Hindsight is 20/20, but I firmly believe that IPv6 should have only changed source and destination addresses to be 64 bits and that was the entire RFC.

I don't think anyone was talking about the difficulty of implementing IPv6 in software. I certainly wasn't. I meant the difficulty of implementing it as a network admin, which is not really hard.

https://beej.us/guide/bgnet/html/ section 5.6

The big problem is that there isn't incentive for old companies to migrate. They have addresses and the benefits are mostly for customers who don't know about it. Also, network engineering training is all about IPv4, and it works so they don't want to change.

I think what was needed was organization that could push IPv6. Boring technology needs someone promoting or grows slowly. They could have logo for IPv6 ready devices, and list of ISPs with IPv6. They could write network engineering training for the IPv6 way.

We missed opportunities for cloud computing, Kubernetes, and new companies to be primarily IPv6.