I think the core argument can be summarised as this:

1. IPv6 is flawed because it has 2 main layers, but it needed 3.

2. It understands physical addresses, and it has its own logical addresses.

3. But it really needed another layer in between them: a virtual translation/mapping layer.

4. Crucially, it lacks this. As such it is not better enough than IPv4 to ever totally replace IPv4.

5. But apenwarr proposes that it is, in essence, possible to fake this using QUIC.

https://en.wikipedia.org/wiki/QUIC <- note the diagram in that article.

6. Using this, it's possible to fake what IPv6 should have had but didn't, and get some of the benefits at the cost of more work.

7. However IPv6 remains doomed to never totally replace IPv4.

Boiling that down to 2 key points:

Point A: IPv6 is broken because it didn't go far enough; its mapping model is fundamentally inadequate.

Point B: It's OK, here's how we can work around that, but it doesn't fix the problem & never will.

And generalising from that argument, my take is this:

Butler Lampson said: "All problems in computer science can be solved by another level of indirection."

David Wheeler pointed out: "… except for the problem of too many layers of indirection."

The corollary of this is: it is imperative to closely track how many layers of indirection you have.

Too many is bad, but arguably, not enough is worse.

With too many, you get inefficiency, but you can nonetheless get the job done. But with too few, you might not usefully be able to do the job at all.

IPv6 did not have enough, and so failed to achieve its primary goal.

- The "mobile IP" problem isn't IP's job and should not be. IP should be as stateless as possible because this makes it cheap and easy to add capacity and redundancy to a network.

- IP addresses are assigned to interfaces, not people, computers, devices, applications, nodes, etc. If you want a fixed reference identifier associated to something across the wire, it is correct to implement that in addition to the state it requires on top of IP. If your application assigns or assumes identity based on IP address, that's a badly written application at this point.

> Y has no idea what that means, and throws it away.

X should have sent Y a session ID? The client and server should maintain session IDs and not the IP layer (imagine the security issues)?

- I think the author mostly has a problem with TCP. QUIC may become the next TCP. And that's fine.

But, to be clear, many implementations of IP (both IPv4 and IPv6) do already have "mobile IPs." There's nothing stopping you from having "mobile IPs." They're just complex, and only work when everywhere the IP can move between all exists within a single AS.

• You can move between multiple wireless APs in a conference hall, and have a layer-3 address that follows you as you switch network segments and thus acquire new layer-2 addresses (which means that the packets destined to that address are being dynamically re-routed at some upstream switch, as the address assignment changes.)

• You can move between cellular antenna and frontend infra (think: WiMax or 5G APs) at different places in a city, while remaining connected to a single cellular backend infra (what you'd think of as a "cell tower") and thus holding a single persistent L3 address.

Is it possible to implement this at home, without paying a lot of money? I've tried it with UniFi AP (with software controller) and no luck :-(

If you really want to do an "enterprise" wireless setup, and you want it to be cheap, well... you can buy the relevant equipment (802.11 enterprise wireless APs) used, often in bulk. Sometimes computer recyclers even have them!

Make sure you buy the stuff intended for office buildings, though, not the conference-hall open-plenum equipment. The conference-hall stuff is like studio lighting: powerful at a distance (five-storey hall ceiling down to you on the floor) at the expense of guzzling power and dumping tons of heat.

Also, obviously, unlike the home stuff, with the enterprise hardware, you do need to be able to run an Ethernet backhaul back to a switch somewhere, to join all these APs' L1 collision-domains into a common link-layer network segment. And that switch has to understand what it's doing, so you'd probably need something enterprise-y there, too, unless the state of open-source consumer router firmware has really caught up with enterprise.

Now I have one AP per room already, but can not implement seamless transition - when phone/laptop switches to other AP it requests DHCP again and drops all connections. It is very inconvenient.

I know "Buy Cisco's APs for $700/piece and controller for several thousand $$$", I wander why there is no open-source solution (hostapd & Ko), which "secret source" these enterprise solutions include, is it private technology or some open industrial standards, like 802.11[some obscure letter]?

Many expensive APs are built with Linux and hostpad inside, and still doesn't support this feature.

Which kind of makes it sound like IPv6 already has the feature the article thinks it should have had.

Not an expert here, but my understanding of the argument is:

For constructing virtual networks, which may be distributed across the real Internet, the new protocol needed a virtual translation layer. It doesn't have one. Instead it just had a vastly larger address space, which doesn't help with this.

As it is, I am seeing a transition to either non-IP or LISP/HIP based methodologies due to security and attestation concerns.

    $ ping 64:ff9b::1.1.1.1
    PING 64:ff9b::1.1.1.1(one.one.one.one (64:ff9b::101:101)) 56 data bytes
    64 bytes from one.one.one.one (64:ff9b::101:101): icmp_seq=1 ttl=54 time=10.4 ms
    64 bytes from one.one.one.one (64:ff9b::101:101): icmp_seq=2 ttl=54 time=10.0 ms

Also I don't have NAT64... The fact that ISPs don't provide NAT64 by default is kind of my point.

How else could this work?

How would that even work in theory?

How would a ('legacy'?) host that only understands the 32-bit data structure of IPv4 addresses talk to a >32-bit data structure IPv6 addressed host?

Endpoint dvices should not be direct peering (security). Always go through either a passthrough inspection device or router.

And then we are back to NAT...

That's the crux of it.

Sometimes I think we'd be better off forgetting about IPv6, and starting afresh with an IPv7 - something that provides a meaningful incentive to upgrade.

The next available version is IPv10

Which is fine, because it is IPv2 in human readable form after all.

[1] - https://www.noction.com/blog/ipv10

[2] - https://datatracker.ietf.org/doc/draft-omar-ipv10/10/

Note: This post is a joke and not expected to be a normative RFC and not under any sort of conformance with Internet Drafts under the IETF.

Totally. I only suggested as a means to avoid conflating a real RFC with a joke RFC. And I only did that because half of the things I have joked about resulted in having to say "No, wait, I was kidding, what are you doing?!?" and thus I learned to minimize joking about things.

I think smarter people than me can handle all the technical underlayment, but when it gets to the point of where the techs and sysadmins are using it, it should have an 8 digit hex key at the start and then an IPv4 "alike" address at the end, and 0000:0000:-whatever should encapsulate the current network schema for backwards compatibility.

Then new systems would get 0000:0001:- and on. That would add 4 billion entire internets to the system and still work at the fundamental level like the current one. Your IPv11 layer would only be used at the edges where the systems leave your wlan, and they could send your mac address as the swapover key or use it as part of the key when sharing security data, and the best part is that end users and clients would not need to know anything more about the network to make it work than that 8 digit string, and most of them, especially home and mobile users, wouldn't even need to know that. It would stop at your modem and be handled by the cell carriers and your home internet providers.

  $ ping 64:ff9b::8.8.8.8
  PING 64:ff9b::8.8.8.8(64:ff9b::808:808) 56 data bytes
  64 bytes from 64:ff9b::808:808: icmp_seq=1 ttl=113 time=8.75 ms

https://www.akamai.com/internet-station/cyber-attacks/state-...

Making a new system that will automatically go live, work transparently to the current system and is on by default as hardware is updated and replaced is a strong pathway forward to unsnarl the internet when you're stuck in this predicament.

Pedantics won't solve the problem and just ensure that nothing ever gets better.

Computers are the worst pedants in existence, so if it's not possible, you're not going to be able to do it... which means that not only is it not a useful suggestion, but it drains time and energy away from doing things which will work.

So 0000:0000 local network, 0000:0001 legacy internet.

Even for tech support purposes, people shouldn't have the ability to directly test my appliances firewall capabilities.

Actually, now that I've done the math, why not just extend IPv4 into hexadecimal?

Once again, none of the current addresses would change with this change, but it would turn 60 billion possible addresses (12^10 = 61,917,364,224) into 184 quadrillion addresses (12^16 = 184,884,258,895,036,416).

I feel like that would give us plenty of wiggle room. Sure, it's not on par with ipv6's ability to assign a unique address to every atom on the planet 100 times, but I think it would be enough for the next 40 years or so, right?

And it's inherently backwards compatible, what's not to love about it?

hexadecimal, unironically. the url of

http://[2002:914b1:::1]

is one of my major sticking points for IPv6. i'd rather just have it be 16 octets or even 8 decimal quartets where each thing is required.

http://0.0.0.0.0.0.0.0.0.0.0.0.192.168.1.1:14246

would've at least looked a bit better than it is. would've been super easy too. imagine the convo:

"what's google's DNS IP in IPvX?"

"oh it's just 8.8.8.8.8.8.8.8.8.8.8.8.8.8.8.8"

But then so would AE1.224.78.BC2

Sure, a little harder to remember maybe, but adding nearly a billion times as many IP addresses would alleviate the strain on the internet, be backwards compatible with IPv4 (but not forwards compatible, so most interior/home networks would use either a NAT or have a software ipv4-4.1 bridge software)

It would also be much more similar to IPv6 which would ease transition to full IPv6 if the human race survives long enough to ever make the jump. IPv6 is just more hexadecimal after all.

I don't know why you think this is "inherently backwards compatible" yet think v6 isn't. It's just as backwards-compatible as v6 is.

I think what you are saying is that it should be turned into a jingle so everyone can dial it fast. [1]

[1] - https://www.youtube.com/watch?v=5m6qutSER9Q [video][11s]

You know what? That sounds like the RFC isn't being followed, but if it's a large enough pattern, then the RFC doesn't matter. It is the standard.

I would say:

1) gather all the engineers from the major switches and networking companies, the Linux network stack, and apple and microsoft, and sure the mobiles. And ask them the easiest way to change the code to support a vast expansion of addresses in the general format of the IPV4 header: options section? Magic IPV4 address that triggers a IPV4r2 packet?

2) as a carrot, maybe you make some way that NATs / VPNs / bridging / whatever works BETTER in the IPV4r2 packet? If the packets had more information in them about the mapping/bridging so external polling was easier and numerous other use cases, then that would spur the vendors to change.

3) accept that NATs, Bridges, etc exist and will continue to. They are now established as a way to think about networking, and there are likely millions of people that think about networking in these ways, even if they are superfluous / unnecessary in the utopia of IPv6 universal adoption. So put them in the protocol. If universal addressing with firewalls eliminates everything, then they will wither on the vine over the course of a couple decades.

So, what's wrong with this? It's obviously naive.

Also, NO SLASHES NO COLONS in the notation. And ... can we increase the number of ports to 32 bits or more?

If there is that magic IPV4 and an unupgraded router encounters that packet, it ROUTES IT TO THAT MAGIC IP.

... that magic IP isn't a ghost IP. It's a service that takes the packet and routes it using IPV4v2, and NAT translates it back to the legacy router on the return path.

... that might not work ... or maybe it will?

My only experience with IPv6 was converting an IPV4 distributed database to IPV6. It wasn't... fun. Looking up separate flags and settings, weird errors (thank the gods for stack overflow), frustration.

Nowhere was it suggested, demonstrated, or detailed such a backwards compatibility / migration strategy.

> My only experience with IPv6 was converting an IPV4 distributed database to IPV6

I assume you mean patching the software to handle it... there are basically two socket APIs, the old one which was v4-only and the new one which works with any generic IP family. v6 had to add the second one because the first one was v4-only, but any replacement protocol for v4 would have had to do the same.

CIDR notation I think is fine, but hard agree on the colons holy crap. Also not being clever with the things, remove the "empty dot" thing.

> And ... can we increase the number of ports to 32 bits or more?

That requires a TCPv2 or UDPv2 or whatever, it happens at a higher layer than the IP layer.

Alternatively, it failed because it went too far. When you have an established system which is used everywhere, it is immensely difficult to replace it.

Something like IPv4, with 64 bit addressed might have been easier to push through. Eg, addresses like 123.123.123.123.123.123.123.123.

We have jumbo frames, why not jumbo addresses?

You still need to update every router and application. Network admins still need to learn something new. The two protocols still don't interoperate. If you're going to go through all of that trouble why only do a half measure. IPv6 is supposed to be the final version of IP.

On the contrary, they would, the behavior's and quicks would be the same. And if we define, say, that if the last four components are zero, then the addr is the same as normal IPv4 address, then you could deploy the whole thing without having anybody assigning new addresses. NAT's/configs/etc could keep working.

The big problem with IPv6 is that everything has to be double-configured to support both IPv4 and IPv6. Two addressed for all. Different semantics. No backwards compatibility.

If you imagine that all network HW is recycled, say every decade, you could roll the thing in without having anybody to reconfigure everything. Eventually coverage would be complete. This cant happen with IPv6, because the double configuration problem. Extending vs replacement.

This is of course a pointless though experiment, because IPv6 is the route that was chosen.

How does a device that thinks that addresses fit in a 32-bit address space send a packet to a device with a larger address?

It could possibly be known as IPv5 considering Internet Stream Protocol was never really used.

Or simply IP64.

Because a "half measure" would have been easier to adopt, therefore would have been more likely. The strategic error IPv6 made was, I think, taking the point of view that as long as a breaking change is necessary, then increasing the scope of that change doesn't bring greater cost.

But it does, quite a lot of it, and that greater cost is the primary reason why IPv6 adoption has suffered.

IPv6 supports dotted quad notation, if that is your problem with it. You can absolutely write a 128-bit IPv6 address with the last 32 bits in 123.123.123.123 notation if that makes you feel happier. ::ffff:123.123.123.123

Technically, there's nothing stopping you from building a quick library that translates 128-bit dotted quad to IPv6 addresses. Use something like 123.123.123.123.123.123.123.123.123.123.123.123.123.123.123.123 if you really want to. The 4-hex digit, colon-separated notation for IPv6 wasn't designed to make it "weirder than IPv4", but to make it easier to write/mnemonically remember than just accumulating dotted quads.

> We have jumbo frames, why not jumbo addresses?

Because there's no room. IPv4 has a fixed header size (period) and almost every field is used. IPv6 had to break compatibility in some way, no matter what, to get "jumbo addresses".

Unless I'm mistaken, I would not say it's fixed due to the rarely used IP options field that varies depending on the IHL field. It has a variable size within a range. There might be a way to get "jumbo addresses" but it would have to be terribly hacked onto the design of the header as it is, which is one reason for IPv6's existence.

https://en.wikipedia.org/wiki/Internet_Protocol_version_4#He...

That also gets back to the point that almost all of IPv4 is too "known" as a design and every field accounted for in some router and/or firewall logic somewhere by the time IPv6 was designed.

Even having them be 16-bit integers would've been find imo

The obvious other notations for numbers that large to compare to are the various notations people use for UUIDs/GUIDs.

I personally find IPv6's designed notations one of the easier ones to use, especially because of that :: fill with zeroes shortcut to focus on the easier separation of prefix versus suffix. (For a network you control you likely only need to remember the prefix, and then suffix is whatever numbering scheme you want to implement so it may be algorithmic and simply ordered ::1, ::2, ::3, etc. Also, the regular pattern of a colon every four hex digits versus say the strange group order of UUIDs is nice. Trying to write the notation of a UUID without software help is much more painful than IPv6 address notation, I think.) But also, I have a bit of dyscalculia (my brain catches all the individual digits in a number but not always their correct order) and hex works much better for me at remembering or visualizing long numbers.

I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design.

And now it's been ... almost ... 30 years.

Which means what is really necessary is a new IP protocol that will somehow, SOMEHOW (don't ask me how, I don't effing know) speak seamlessly to IPV4 and IPV6, and be so irresistible that people will want to migrate off of both.

I almost wonder if what is necessary isn't a formally predesigned protocol. What is needed is someone, somewhere, to come up with an approach that becomes a grassroots, and the industry rushes towards it. I don't even know if such a thing is possible anymore, IPV4 land may at this point be complexity theory/mathematically impossible to make a N+1 umbrella protocol of any real "elegance".

You don't know how, and nobody knows how, because it's not possible to do. v4 simply does not support addresses longer than 32 bits. If it did, we wouldn't need v6 in the first place.

Choosing not to do something that's impossible isn't hubris. Hubris is criticizing the people who knew what they were doing without realizing how little of the problem domain you yourself understand.

I think you misunderstood the comment, but at first reading, I did too.

But on consideration, I do not think @AtlasBarfed meant that this hypothetical IPv12 or whatever (7 through to 10 are taken) would be able to talk to both in one protocol.

It's well established that no seamless extension of the IPv4 4-octet address space was possible. I know, a lot of people still don't get that, but honestly, to the majority of people working in tech today, all this stuff is black magic that just happens. Either they learn, or they don't and can be ignored. That's OK. We have to live with that and move on.

The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half the IP market. That is not just "not good" - that's terrible.

What IMHO apenwarr's blog post was trying to get at was the complexity of connection schemes needed, and how a new protocol with an integral way of of constructing virtual networks, connected over the public internet into cohesive wholes via some form of built-in redirection or mapping layer, would have made it a far more compelling offering.

I have seen others saying this, but I can't find any links any more. I welcome other pointers to articles not merely pointing out problems -- there are lots of those -- but proposing solutions.

> The real, the big question here is: was there some single obvious thing that IPv6 failed to do or failed to include that has made its uptake so slow? It's taken some 30 years to reach approximately half the IP market. That is not just "not good" - that's terrible.

Is it terrible though? Obviously it would be nice if it were faster, but what's the expected deployment time for something like v6?

There are about 30 billion network devices, arranged in hundreds of millions of separate networks managed by as many separate people. Noone has authoritative control over all of them. There's no hard deadline for v6 deployment (we saw with Y2K how much a deadline helps). Network effects work against it, and that's unavoidable because of v4's 32-bit limits.

I don't think humanity has ever tackled a migration project of this scope and scale before. So how can you know that it's going terribly?

I don't think there's an obvious thing we missed either, at least not in the set of things which work and are actually possible to do. I've talked to a lot of people about this, and their suggestions are basically either: not possible ("just get everyone to switch over all at once"), broken ("just pad v4 with some zeros"), or something v6 already did (frequently NAT64 or 6to4 but described in weird terms). Either there's a big conspiracy to keep the obvious thing a secret, or it doesn't exist.

> I welcome other pointers to articles not merely pointing out problems -- there are lots of those -- but proposing solutions.

Sigh... yes please. But solutions are hard, especially to unsolvable problems. Making a clickbaity article that points out the problems and says "somebody should have solved them" is easy, and as you can see from the response to this article and djb's each time they're posted, that's all people are interested in anyway.

I am not a network engineer (any more, thank the hypothetical deities) so I have no skin in this game.

But in the 1990s, I moved networks from IPX/SPX, or NetBEUI, or AppleTalk, or DECnet, and almost any combinations thereof, to IP. I added IP on top of existing networks. I migrated systems from 10base-2 to 10base-T to 100base-T. I stitched together WANs. Then I moved IP networks from static to DHCP, from no name resolution to DNS to WINS, and so on.

I am not a total rookie to this stuff.

So when you say

> I don't think humanity has ever tackled a migration project of this scope and scale before.

I have to disagree.

The IP rollout itself was bigger, and yet, it happened much, much faster.

We moved the networked world from a dozen protocols to IP, then we totally re-architected how IP worked, from static networks to `hosts` files to name resolution to dynamic IPs and dynamic name resolution.

Then we rejigged it all again for a world of proxies and gateways, and firewalls, and NAT.

You make out like this is some vast super-hard thing, but in fact, the world of networking is way older than many people in the modern IP-only world realise, and we've rebuilt it over and over and over again repeatedly.

When a new technology comes along that offer compelling advantages, then the world moves to it, not in one smooth operation but incrementally and piecemeal, but it happens.

It hasn't happened to IPv6 and my argument, and much more importantly the arguments of the Avery Pennarun here and of Dan Bernstein, are that it hasn't happened because IPv6 isn't good enough.

It's good but it only fixes 1 problem and that one, while big and important, is not the whole problem and it's not even the most important problem because there are workarounds for simple IP address starvation, and the workarounds are _good_ workarounds with their own advantages, and some of those advantages are compelling.

The world has, overall and on average, decided that IPv4 is good enough to mean it's not worth the pain of moving. It's better to fix what it already has.

It is the same issue as Plan 9 vs Unix.

Plan 9 is better by almost every objective measure, but Unix is good enough, so the world decided to stay with Unix rather than the pain of moving.

For me, what is an interesting question here is "could we fix Plan 9 to make it worth moving to?" The Plan 9 people don't care, though.

Similarly, although it's not my area, it's an interesting line of questioning to ask "what is wrong with IPv6 that the world didn't move to it, and can we fix that?"

But when someone proposes it, the IPv6 proponents treat it as heresy, not as a simple, relevant question.

That in itself is interesting too, IMHO.

As a result, network effects [in the economic sense of the term] worked in favor of deploying v4, but they work against deploying any replacement to v4.

You could argue that it required migrating local networks, and it did, but migrating from IPX/etc to IP is fundamentally simpler than migrating v4 to v6, because you only need to worry about your local network -- which you have full authoritative control over and can mandate a migration deadline for. You didn't need to worry about maintaining compatibility with the IPX Internet either, because there wasn't one.

Note that I'm drawing a distinction between a network and an internet. IPX/etc only did the former, IP does both. The level of challenge in migrating a network (even multiple of them) is very different to migrating an entire internet, due to the interconnectivity or lack thereof between the networks.

You're also talking about a time when there were three orders of magnitude fewer networked computers, and relatively little networked software except for the vendor software that came with the network stacks in the first place, which wasn't expected to be compatible with any other network protocol.

Moving from static networks and hosts files to DNS and DHCP, is all L4 stuff, and could be done without changing L3. Similarly with firewalls and NAT: there's no need to change L3 to implement those and their deployment is a local-network-only project.

You make a good point that the 90s had far more technological change -- it must have been interesting to live through. But it was technological change that was fundamentally easier to deploy because it only involved making local changes on each network, not changes on all networks. v6 doesn't have that luxury because v6 is replacing the IP address, which is the one thing that goes end-to-end through all of the networks.

So yeah, that's my argument for not agreeing that the original rollout of v4 was bigger or harder than v6, even though it involved more technological changes. It's not the technical difficulty but the sheer scale of the deployment -- v6 needs to deal with far, far more software, devices, networks and involved people than anything v4 had to deal with in the 90s -- and the strength of the network effects that worked in v4's favor but which are working against v6.

> Similarly, although it's not my area, it's an interesting line of questioning to ask "what is wrong with IPv6 that the world didn't move to it, and can we fix that?"

I don't think it's fair to say that the world didn't move to v6, because the world is moving to v6. It's gone from 50 million users to 2.3 billion users in the last 10 years. That's about the number of people that were using v4 at the start of those 10 years.

I'm not treating these questions as heresy, it's just that we keep seeing the same broken takes over and over and it gets very tiring. Things like "v6 would have been deployed in 5 years if they had just added some zeros to the beginning of v4 addresses", from somebody who doesn't have a clue how to make that work and who doesn't know enough to realize that it can't work. There are dozens of people like that just in the comments to this article alone. You can't expect posts like that to be taken seriously by anyone that knows what they're talking about.

> It's good but it only fixes 1 problem

It's interesting that you say this, because the person I replied to above said "I think it was protocol design hubris: we are fixing SO MUCH STUFF that people will flock to this irresistible shining trophy of protocol design."

Is it fixing too much stuff or too little stuff? You guys can't even agree on that!

Networking in the 1980s and early 1990s was all small LANs, for the vast majority of users, and for PC-type kit.

But there were internetworks, yes. DEC ran a global network; DEC tech support was my first experience of true worldwide follow-the-sun support, where the techs on 3 different continents could pick up my case from a single shared database and help me move it forward.

I was sysadmin of the London node of a DECnet internet that spanned Oslo, Copenhagen, Stockholm and Helsinki. No IP links between the sites, just DECnet.

Companies were running global IPX internetworks: that is how the problems with scaling Netware 3's bindery database arose, which is why Novell developed NDS and Netware 4.

Yes, it was a thing. Updating and modernising it was hard.

> No, I'm not switching sides. IPv6 is just as far away from universal adoption, or being a "good design" for our world, as it was three years ago.

Eloquence for the ages.

- I started on one side of the IPSEC, where I have an OPNsense

- there were like 5 updates of OPNsense in the last year where different IPv6 issues were fixed (and others have been introduced).

- my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult

- a number of times I had to turn off IPv6 because different parts were suddenly not working anymore, mostly based on software issues in my stack

All of that over 20 years after IPv6 was introduced makes me wonder if it is the correct technology, if it is so difficult to implement.

IPv4 (as used in practice) has 48 bits of addressing, we don't need more.

What we do need is a standard way to do address translation for routing decisions, to replace the 1001 half-baked solutions for VPN and overlay networks that are used today. (Linux has something like five or six "standard" ways to tunnel IP over IP. WTF?)

IPv6 has 48 bits for allocating network prefixes.

People wanted a DynDNS kind of solution.

Do you mean an entire address space of NATs?

That's a bummer. I've been using FreeBSD + pf at home for years now, and it's been smooth sailing.

> my ISP only hands out /64-Prefixes, and these are also dynamic, which makes configuration more difficult

Comcast/Xfinity hands out a /60, which means I get 16 x /64 subnets. And they haven't changed my subnets in at least four years. Pro-tip: when you change firewall hardware, keep the same MAC addr to keep the same IPv4, keep the same DHCP Unique Identifier (DUID) (/var/db/dhcp6c_duid on FreeBSD) to keep the same IPv6 subnets.

If you start with a solid base (having a fixed IPv6 /56 delegation for example), or at least a dynamic allocation with IPv6-PD, then you'll see that it's way easier than IPv4 in the long end

It is only thanks to "happy eyeball" algorithms in the browser which prefer v4 when v6 is broken or non-performant that mitigate end user complaints to the point that people can just kind of turn it on in some state of broken and forget about it.

There are entire ISPs that are IPv6-only at the CPE and have to deal with brain-dead software that can't handle it and so have to spend enormous amounts on CG-NAT:

* https://community.roku.com/t5/Features-settings-updates/It-s...

* https://news.ycombinator.com/item?id=35047624

You still can't talk to Hurricane Electric from Cogent over v6. Lots of v6 links are still tunnels. v6 PMTU Discovery was a massive mistake that introduces latency.

It isn’t possible on the UniFi system that replaced it. Who needs basic core functionality anyway.

    [1]: https://redmine.pfsense.org/issues/6626
    [2]: https://github.com/opnsense/core/issues/2544
    [3]: https://github.com/opnsense/core/issues/6158
    [4]: https://github.com/opnsense/core/pull/5574

We could have done a lot of good by adopting proposals to extend v4 like 0/8 and class D, but instead the decision was made to collectively drown the babies in the bathwater and insist on v6 at all costs.

People like to complain a lot about the new features in v6, but they don't make it any worse as a v4 replacement.

https://web.archive.org/web/20210122043401/https://blogs.aka...

There are entire ISPs (in the US) that are IPv6-only for CPE because IPv4 is unavailable and they have to use expensive CG-NAT boxes to deal with IPv4:

* https://community.roku.com/t5/Features-settings-updates/It-s...

*https://news.ycombinator.com/item?id=35047624

Meanwhile India was 80% IPv6 as of a few months ago:

* https://news.ycombinator.com/item?id=32798003

The fact that the US and EU just happened to get a bunch of addresses first doesn't mean the rest of the world has the same options available.

More addresses are needed if everyone on the planet is to be able to connect.

The only thing that will make corporate environments change is if something they need starts requiring it, and not a second before.

Cloud is slowly getting it. Slowly. GitHub still doesn’t have it though, which makes pure v6 nodes annoying for a lot of use cases.

I'd love to be at a point where everyone just dual stacked everything so that one day we can flip off the IPv4 switch.

Kubernetes didn't get IPv6 support until later, and it sounds like it isn't reliable yet.

Heh. Kubernetes as a whole was a failed project at Google that got open sourced.

So in the end you are looking both at capex, increased opex and for what? You have ipv6? Congratulation, now you go to your C-level bosses and explain to them why it was worth it. Good luck.

I'm worried that the time when we can start removing v4 and therefore see the actual advantage of v6 won't be here for at least a hundred years, optimistically.

v6 advantages:

* If you're an ISP, you need more complex hardware for CGNAT-v4 if your traffic is huge. If you do support v6, netflix, youtube and majority of your traffic is already on v6, you can get by without upgrading your CGNAT Infra.

* I suspect v6 should have faster initial connection - time to first byte, because of no NAT. I assume NAT is implied in v4 because if you're an ISP say in India where you have 1.2B mobile devices, you cannot buy 1/4th of all IPv4 addresses.

* Because of more IP addresses you can run VMs with public v6 addresses. It's not common to have ISPs give multiple IPv4 to a single customer, but with v6 that's always the case.

* I really don't think NAT could possibly make a noticeable difference in the time to first byte. My guess about what's "barely noticeable" would be a few hundred added milliseconds, my guess at what NAT would add would be a few milliseconds. Happy to be proven wrong though if there are any studies or experiments on the topic.

* I'm not sure what benefits there are to giving your VMs public v6 IPs when you still need to support incoming v4 connections.

(Also, doing things like loading a webpage requires many round trips, so even a small RTT difference multiplies to a bigger delay for total load time.)

You don't need to remove v4 to get benefits from v6. For example, you can handle inbound v4 on your load balancers to avoid needing to mess around with it on your entire VM fleet.

That was the work of a few people on the YouTube team, not the company itself taking a stand:

https://blog.chriszacharias.com/a-conspiracy-to-kill-ie6

- $55/mo. 3 Mbps DSL

- $80/mo. 300 Mbps cable (or even more expensive, faster cable)

- $120/mo. 100+ Mbps (if you're lucky) Starlink

- A few other heavily restricted, very expensive satellite options (e.g. HughesNet), to which the aforementioned fleet of ill-trained carrier pigeons might be preferable

Only one of those is practical and (mostly) reliable for anything remotely approaching something like remote work.

Back home it's such a luxury to be able to choose DSL, cable, or fiber. I can only dream that all markets will have an actual choice between Internet service providers someday.

For services at home, where I do need IPv4 support, access over IPv6 is simpler and more robust. We can expect more of that in the future. Increasing prices of IPv4 addresses, certainly if for routing purposes you need a /24, may result in worse traffic engineering for IPv4.

Kubernetes is comically bad at IPv6. Docker is comically bad at IPv6.

GitHub is comically bad at IPv6.

Like I said, pricing IPv4 at all, is at least a start, a baby step in the right direction. Even if it is a drop in the bucket compared to the rest of the cloud invoice, it is still at least a line item that corporate accountants are going to notice. It is now an obvious cost to cut. Maybe that will put pressure on fixing how comically bad the above offenders (and more) are actually supporting IPv6, because corporate accountants may start asking hard questions.

End user facing apps also use it in gradual way when available, eg with WebRTC it lowers service ops costs and gives better latency.

(Which we could have had with a minor tweak of IPv4 instead.)

In fact v6 mostly _is_ a minor tweak to v4; most parts of it are lifted directly from v4 but with a longer address.

This kinda a problem for motivating people to move to v6 because as implementations of v6 grow there's going to be less and less pressure on the v4 address space.

Corporate networks were the last to drop XP, the last to drop IE, and will be the last to adopt IPv6.

IPv6 has issues but it hasn’t failed.

One question I have about this statistic (and also about Google's IPv6 statistic) is, does traffic mean raw bytes? And in that case, is this just a reflection that like 75% of all internet traffic is just YouTube and Netflix due to video being a bandwidth hog?

(I'm a huge proponent of IPv6 - I just wish we had more useful statistics!)

I guess you're thinking that the number of v4-only websites is much higher than the traffic numbers represent -- which is true but that's actually fine because v6-only clients can still reach those sites easily via NAT64, so having a lot of v4-only websites isn't blocking deployment of v6 or undeployment of v4. The only real problem it causes is that people use it as an excuse to not do v6...

As for Google's stats, they're probably percentage of either connections or users as measured by their frontend load balancers.

I think the only way that we will move to IPv6 is a law (probably from the EU) that imposes to every provider to give its consumers an IPv6 address.

I still don't understand why IPv6 is a thing. End users can use NAT just fine. Servers can use CDNs and reverse proxies, sharing single IPv4 address among any number of hostnames. But it is a thing, so it's hard to imagine any other protocol to take over.

There’s plenty of numbers out there. Ipv6 lets my house have a whole subnet of them. It’s good.

being behind their NAT caused all sorts of issues that i didnt realise they were causing... stuff like UPnP didnt work right, opening ports wasnt working right... everything was all over the place.

Running servers at home is a good thing to have, but I doubt that ISP cares much about users running servers at home. Users watch youtube and netflix. That's what they optimize for.

So you want all computers to be behind at least a single layer of NAT. And you also want people to not only have to purchase a domain but also have to pay their NAT operator to add their domain to the reverse proxy

They're very different precisely because of hacky nonsense like NAT.

Now, CGNAT is a different beast and more worrisome from that point of view.

ICE/TURN/STUN: the address that your software sees on your laptop, desktop, home NAS is not the address that clients can connect to.

In both NAT and non-NAT you have to use UPnP/PCP to do hole punching, but with NAT you have to do a bunch of address-y stuff as well.

NAT requires stateful tracking of stateless protocols. It's a hack much larger than anything related to ipv6.

IPv6 would have worked better if they had made minimal changes to the support protocols. But it was have had slow adoption because there was no incentive to switch until addresses ran out.

- changed arp. Ok, new design is better but that didn’t need to happen. Shouldn’t be a problem for anyone?

- prefixes are an addition but there are really good arguments for them and not much downside. This can be argued I think

- fusing the end system identifier in the public address was a mistake, and I thought so at the time, and I guess it’s been mostly rectified.

So what is so tragic here? ISPs just didn’t care for 20 years because the crunch was delayed. Now they do. So where did Steve screw up?

IMHO the biggest problem is that IPv6 address autoconfiguration was half-baked. There is no mechanism to inform anybody about which address you have configured for yourself, unlike IPv4's DHCP where a central server knows everyone's address and can do things like update DNS entries and configure security devices. Autoconfiguration also didn't include critical details like "Who provides DNS for the local network?" and "What's the NTP server?". There isn't even any way to authenticate that the Router Advertisement your machine receives is valid, although this problem is shared with DHCP. The committee seems to have put a lot of faith in anycast routing, which has never been a good idea outside of toy networks.

Indeed. I thought I was being an idiot and just not understanding how this was supposed to work, until I learned that it just doesn't do a lot of important things. So when the day comes that I have to move my network to IPv6, I plan on continuing to use DHCP because I want the omitted functionality.

Of course, I still might be being an idiot and not understanding. Getting a solid picture of how IPv6 is supposed to work is genuinely hard to do with any confidence.

The more I learn about IPv6, the more I dread it.

The one thing that mattered was more address space. 4 billion addresses are not enough for the world. Anything else in ip6 is nice to have but falls off a cliff of importance and naval gazing that, if really of even nearly comparable significance, would be better directed to ipX or whatever's next.

IP6 is already facilitating connectivity for billions. Globally. That's a pretty major thing, more so than renditions of doing it my way.

Early Stanford and PARC routers could route XNS packets, but this died out some time in the 1980s.

Things I would change:

1. Use 72-bit addresses. 56 bits for the network address, 16 bits for the end-user networks.

2. Just use the IPv4 "local subnet" prefix logic for broadcast domains. No "on-link" nonsense.

3. Replacing ARP with neighbor discovery via multicast messages to interface addresses is... ok? But it's not necessary.

4. Remove SLAAC and stateless DHCPv6. Statefulness is helpful for network management.

5. Reify the MTU into the IP layer. No more ICMP nonsense for PMTU.

6. Rework extension headers to be actually useful. No more "next header" bullshit.

16 bits is just way too small. The article clearly states that network operators just love to bridge together larger and larger networks due to the mobile IP problem. In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

And once you go over 16 bits, you really need to start dealing with routing.

> In the IPv4 world they can even have 24 bits (10.0.0.0/8) why should IPv6 have only 16 bits? It's definitely not enough.

This is not a fair comparison. You won't have a 10.0.0.0/8 network in IPv4 that has 16 million computers in the same broadcast domain. You'll likely have multiple /8 or /16 networks, with routing between them.

And in my hypothetical world, you'll have 56 bits for that routing. Your ISP can delegate you a /32 prefix, giving you 24 bits for your own routing hierarchy.

This is not dissimilar from the current situation. You have just 64 bits of the "network address", because the lower 64 bits are needed for SLAAC.

For a 16-bit network, you can enumerate all active public servers by exhaustively port-scanning it; it takes something like a few hundred gigabytes of traffic, which is nothing these days. For a 64-bit network, it takes quadrillions of gigabytes of traffic and just isn't feasible.

64 bits is enough space to fit a small public key, which v6 uses to secure neighbor discovery.

There are anonymity benefits too: privacy extensions wouldn't work as well on smaller subnets.

As an added bonus, having extra bits to spare is useful if it ever turns out that we need them. If we run out of space in 2000::/3 then we can start over in one of the five other unused /3s using tighter allocation policies. L3 protocols are incredibly hard to deploy and it would really suck to deploy a bigger one only to have to deploy another, even bigger one again soon after.

I don't think there's a good reason to give up all of that. Smaller addresses break compatibility with v4 just as thoroughly as bigger ones do, so it wouldn't even help deployment much.

Disagree. you don't want to be routing unless you actually have to. A large flat network is more desirable a lot of the time (e.g thousands of devices in a DC) than a bunch of artificially carved up subnets.

The reason you don't see them very often is because people have had to use IPv4, which means ARP, which just doesn't scale. At some point in size, ARP chatter becomes the majority of the traffic on your network, which isn't great.

ND fixes this, and allows for ridiculously large networks (the way our good maker intended).

First, a /16 network is 65536 devices, which is pretty big as-is. And like in V4, you'll be able to disregard recommendations and choose a larger local net size (just change the netmask).

But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...

> ND fixes this, and allows for ridiculously large networks (the way our good maker intended).

ND doesn't solve it. It works in practice using the same old broadcast, just like ARP. Some switches might do ND snooping, but if you have thousands of devices, they'll overflow their internal tables and fall back to regular broadcasts.

ND also has unsolvable issues, like the neighbors cache size problems. Since you have a freaking /64 for your local network, you can't easily store the mapping for ALL hosts, and you're susceptible to various cache exhaustion attacks (including negative entries).

"big" is a relative term. For some cases, that's a really annoying restriction.

> But it's a bad idea. You will have a shared media that can be brought down by erroneous broadcasts or devices. This is a classic story: https://www.computerworld.com/article/2581420/all-systems-do...

IPv6 doesn't have the concept of "broadcast".

> ND doesn't solve it. It works in practice using the same old broadcast

No, ND uses multicast.

Running any network with >100k hosts has its challenges, but these are surmountable with IPv6, and not at all with IPv4.

Indeed. It has magic fairies delivering multicast packets to the right interfaces.

> No, ND uses multicast.

How do you think multicast is implemented in Ethernet?

Via MLD snooping on switches that support it. Yes, some switches will fall back to broadcast, but only if they're not multicast aware.

It's not a good outcome either way.

Unicast MAC table space is scarce, too, and suffers the same failure modes when filled. You don't see people claiming this makes IPv4 over Ethernet infeasible. Do proper capacity planning, and this isn't a problem. Oversubscribe your network, and this is a problem even without multicast in the picture.

Yup.

> You don't see people claiming this makes IPv4 over Ethernet infeasible

Actually, people DO claim that. Flat Ethernet doesn't scale, and you need to use routing to break up broadcast domains.

This has nothing to do with unicast MAC table limits, and everything to do with ARP's O(n^2) scaling property. You use just as many MAC table entries in a network with 10 VLANs of 100 hosts as you do with 1 VLAN of 1000 hosts. Ethernet scales fine; ARP doesn't.

Due the mass use of encryption and overlays, you can't trust any process or device any more.

But what about thinking about the next step, neurons in the home. 65k's on the low side for home neuron count.

I don’t even think it’s really ok. ARP was layered correctly: IPv4 runs on Ethernet+ARP. Or it can run on other things that aren’t Ethernet+ARP. IPv6 uses IPv6 messages to make itself work on Ethernet, thus baking knowledge of Ethernet into the IPv6 neighbor discovery logic.

If multicast neighbor discovery is useful (which it may well be), then ARPv6 could have used multicast.

On one hand, V6 addresses are big enough to represent hardware addresses directly. So you don't _need_ a low-level protocol like ARP to resolve V6 addresses to hardware addresses, you can represent it as special messages in IPv6 itself.

It also allows some interesting tricks, like local network applications using interface addresses to communicate normally without setting up global connectivity.

On the other hand, interface addresses in V6 cause no end of confusion ("what the heck fe80::88a:fd34:d1b:2de7%en0 means?!?"). And V6 also has no clear distinction between the local network and the Internet, and the easy ability to use broadcasts (just send a packet to the network address).

And it's not like many applications actually use interface addresses anyway. So this is kinda a moot point.

If the MTU is fixed, you can't have VPNs, or any other protocol that encapsulates IPv6 packets and then sends them over IPv6. There needs to be some way for a middlebox to communicate that the MTU is lower than normal on a specific path because it is taking up a bit of every packet for overhead.

This statement then implies that we would need to have NAT66. Why? Stateful DHCP then implies the possibility of an endpoint having only a single assigned address. But what if the endpoint needs to have multiple addresses such as tethering or running VMs? With SLAAC the endpoint can just get multiple addresses. Now, just because today stateful DHCPv6 is a possibility, hypervisors need to have NAT66 built in. So the status quo is strictly worse than either only SLAAC or only stateful DHCPv6.

And if you don't want/have prefix delegation, you can just use multiple DUIDs to get several leases for one endpoint. Unlike in V4, this is fully supported in V6.

Your VM hypervisor will need to request an address during the VM startup, but I think it's actually better from the management standpoint. The network operator will be able to see VMs as the first class citizens in the network management console.

> But what if the endpoint needs to have multiple addresses such as tethering or running VMs?

Android developers are actually adding support for stateful DHCPv6 for exactly that reason :) They want to support tethering for V6 without doing NAT or bridging.

I love that (almost) every IPv6 subnet is a /64. Just this morning I assumed an IPv4 subnet was a /24, only to discover it was a /20, causing me to spend a couple of minutes re-working.

I love that (almost) every IPv6 is a /64 because you'll never have to widen a subnet because you started of with a /24, but then after your office grew to 200 people you had to switch to a /20. And no matter how automated you are, there are always some important devices that have static IPs and that you have to reconfigure manually.

I love that every IPv6 client gets a routable IP. This means NAT isn't necessary. NAT is a clever hack, but we've grown so accustomed to it that we've become blind to its failings. I've had to trace packets coming out of a corporate NAT, then into an AWS ELB (Elastic Load Balancer) back into a different NAT. With the IP address remappings, it's awful

IPv4 NAT can also lead to IP address collisions. Your home subnet is 192.168.0.0/24? And so's your work? Good luck VPN'ing in.

I like that IPv6 has an abundance of IPv6 addresses—I don't need to share the ports on my sole IPv4 address to 5 different machines.

I wasn’t there (sounds like Apen was?) so I could be missing context, but I was under the impression that there were loads of layer 2 protocols at the time IP was designed (token ring, frame relay, etc) and so IP needed to be agnostic to the L2 protocol in order to be adopted.

The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=25568766 - Dec 2020 (131 comments)

The world in which IPv6 was a good design (2017) - https://news.ycombinator.com/item?id=20167686 - June 2019 (238 comments)

The world in which IPv6 was a good design - https://news.ycombinator.com/item?id=14986324 - Aug 2017 (191 comments)

Not super common but there's Infiniband. Latter versions supported encapsulating ethernet frames (Ethernet over InfiniBand) but not all hardware supports it. Otherwise it's straight IP over IB. There must be other niche networking technology that does IP without Ethernet.

https://stats.labs.apnic.net/ipv6/XA

US on 50%, India on 70% and China just shy of 40% -As China continues to grow (and it will) the likely outcome is > 50% IPv6 Capable. I doubt any new Mobile deployment will be single stack, the most likely is pure IPv6 with CGN for 4. So Africa which is still in growth, the most likely outcome is dualstack preferring 6

It may not be ideal, there may be significant issues with EH for instance, but at scale its alive and kicking.

Now, if only we could get jumbogram more widely deployed. Thats older than V6 is and still struggling to break the 1500 byte MTU limit.

Solving PMTU problem would have required reifying the MTU to the IP layer. It could have been done like this:

1. Use a 16-bit field in the non-checksummed portion of the IP header. Initially this field is set to the MTU of the link that originates the packet.

2. Each router inspects this field, and sets it to the MTU of the next hop link, if it is lower than the MTU already in the packet. This will be cheap, as the field is not checksummed.

3. If the packet is bigger than the MTU of the next hop, just truncate it, and set a special bit somewhere in the packet header to indicate it. No need to recalculate the checksum either, the packet is going to be corrupt anyway.

4. The destination host gets the discovered MTU of the forward path, and sends it back to the originating host in the header of the next packet (in a checksummed part).

That's it. Easy, continuous MTU discovery, with robust handling of failures, that doesn't require any smarts from the routers (a comparator to update the MTU can be done in a few logical gates!).

Alas, nobody had the presence of mind to think about this back then.

For example, the NBN in Australia uses a 2000+ layer-2 frame and nothing like 500 bytes is consumed to mark the upper carrier. They COULD have gone higher than 1500 and I would be surprised if there arent customers using 1300 or less because of the ADSL configuration they brought over when they uplifted from a real modem.

A lot of people do 9000 in their filestore network. They know it works on the local segment. Reducing the forwarding burden in header-TCAM-routing by a factor of 5 is a significant win, if you have a lot of packets.

People continue to discuss mechanistic approaches to finding your MTU in the IETF but I think you're right: its 1500 or less pretty much forever unless somebody makes a move here for product differentiation reasons. Given the embedding of content inside the ISP or at the IX, I suspect it COULD happen, if e.g. Netflix said it was a better overall experience? The ISPs would do it.

And even then, I got slapped by WiFi. Its PHY MTU is limited to 2304 bytes, and that's a hard limit.

Even for the plain old wired Ethernet, I had to experiment a bit because the first multigig USB-C adapter didn't support Jumbo Frames.

If the destination gets a packet that isn't as big as it says in the header, it was truncated, and the MTU is the size of the packet it received.

Even easier!

You still really should occasionally probe up, in case the path changed, but that's not very well done today either.

Really, we barely hit 1500. Look at mss for popular websites, most people drop from 1500, because 1500 has problems in enough places. Does http/3 even send 1500 byte packets ever?

One major problem is most servers (Linux all versions, I think, FreeBSD before about 2000 and after something like 2019) always send the interface mss with a syn+ack. You get meaningfully better results by sending the lesser of the interface mss and the received mss; there are enough broken systems out there that don't communicate the real MTU to end systems[1], don't send enough ICMP needs frags, try to cover it up by manipulating mss in syns, but don't manipulate mss in syn+ack. Windows and iOS (and presumably mac) do a pretty good job of detecting pmtud blackholes, but it's often disabled on servers and I can't remember where Android is these days; I know it used to ship with the option compiled in but disabled and no way to enable.

Of course, packet sizing is actually a hard problem. Larger packets are good for faster links but bad for slower links.

[1] which is hard, because I don't know how you get windows to use MTU from dhcp; it doesn't request it, so it won't use it. This is a problem too.

The maximum permitted size is 65527 (max_udp_payload_size).

We found out much later that the reason was that Opera had broken RFC3484 handling and prioritized 6to4 way too high (which skewed the results), and Opera was popular in Ukraine at the time. :-)

A few websites without v6 aren't a blocker to either deploying v6 or undeploying v4.

I interpreted the article as inferring that "every device should only speak internet, and we shouldn't have non-internet hacks to allow devices to connect to the internet."

But, if we interpret the internet as a network built on top of other networks, it negates the thesis (as I interpret it) of the article. It also locks us into networking, as understood in the late 1990s, and designed into IPv6.

IMO: It seems like IPv6 suffers from second system syndrome. The authors lost sight of the purpose "network built on top of other networks" and tried to add lots of features for the "other networks" that really aren't needed.

Maybe it's time for IPv7? Really, all we need is IPv4 + larger address space. I'd even argue that NAT is a good thing (security feature,) because allowing devices on a private network to automatically open ports on the public internet is insecure.

Any router that I’ve come across already blocks incoming IPv6 traffic by default, so I’d have to disagree. NAT was designed for a very specific purpose and keeping it in a new implementation makes no sense if it’s not necessary, which it’s not if the hardware requires you to open incoming ports.

No NAT would make it a lot easier to understand what’s happening too, since the process would be “allow traffic from the internet to this device” rather than creating a translation for an internal address, possibly having to set up a MAC reservation to ensure the DHCP lease doesn’t expire etc.

There are a large class of people out there who do not understand the end to end argument in system design and who never saw a piece of bloatware they didn't love. For them IPv6 will happen tomorrow. They are to internet like maga people are to democracy - caustic.

In 2004 IPv6 was hyped as solving the impending IPv4 address shortage. NAT had already been invented and there was no shortage as IPv4 addresses were allocated as inefficiently as possible and there was no market to buy and sell IP addresses nor was there any rental cost for owning ipv4 addresses. So it was solving a non problem.

My employer Qualcomm eventually proposed using IPv6 for cell phone handsets in an overlay network called openran. This was a convenience and not a necessity because there are more than 4 billion cell phones in the world.

You just don't need these bloated addresses in IPv6. You need banks of addresses mainly for the server. The client never needs 65,000 incoming or outgoing connections. The number of client computers in the world that are running as servers and that need open datagram accessibility from anywhere in the internet is virtually zero. Want it? yes! Need it - meaning impossible to do without it - No! There are always bridging workarounds to avoid giving client machines dedicated IP addresses!

IPv6 is not respectful of small system design and hardly provides usable improvements to IPv4. IPv6 was a marketing tool invented by Cisco to sell bigger more expensive routers, not to solve a problem with any economy ... It is especially detrimental to IOT.

Not sure why the author is so sniffy about DHCP. To me it seems easy to understand and configure.

Having said that, I appreciate the author's remarks about DHCP being a 'fake' IP protocol, and in reality being an ethernet protocol; I hadn't seen it that way before, but it's a reasonable way to look at it.

https://djangocas.dev/blog/huge-improve-network-performance-...

https://atoonk.medium.com/tcp-bbr-exploring-tcp-congestion-c...

The problem is that the API is too low level, or more specifically there is no high level API for it. Ideally it would have a function that looks like:

    int sockfd = connect_to(hostname, port, SOCK_STREAM, options_bitfield);

You can't make a backwards compatible "IPv4 with more bits" like people dream of. L2 routers and middleboxes would still need to be replaced, software would still need to be rewritten, nothing would be different. IPv4 changed how private networks worked because its first attempt at private networks failed.

People are stuck with the IPv4 mindset through a combination of lacking education (who even taught IPv6 when our current sysadmins were in college?) or assuming IPv4 is normal and well thought out. There are free guides, books, and playgrounds out there if you want to learn IPv6, so the education problem is one you can solve yourself. Realizing the flawed nature of IPv4 is harder.

I've come from IPv4 networking, but learning IPv6 later made me realize how silly old networks really are. DHCP is a hack to solve a design failure in IPv4 and SLAAC is a much better solution. Companies have started relying on awful hacks originating from when companies decided to staple features to a side effects of a generic address distribution protocol. ARP feels more like a placeholder that should've been included a layer lower or higher in the network graph, put in its own little place to solve the theoretical "what if we don't run IP over our switch" problem that stopped being relevant decades ago.

As annoying as it may be, we live in an age where the OSI model with seven layers of networking protocols don't exist. Token ring is dead, SCTP died in the womb, Ethernet II exist purely in theory. The world now runs on HTTPS on top of UDP or TCP on top of IPv6/4, on top of some kind of wire that carries ethernet.

Ethernet now exists to support IP and vice versa in 99% of all use cases. TCP and UDP exist to serve HTTPS, or some legacy protocol that will be rewritten into HTTPS in the next ten years. WiFi and high-speed data networks came in as a whole new networking system and have turned out to be "what if ethernet, but wireless" with some control logic to make the wireless antennae talk. The OSI model and all the expansion and flexibility it provided simply died over a decade ago. Anything on top of the data link exists purely to support Ethernet + IP + HTTPS.

The migration path to IPv6 is now blocked by excuses. People pretended to care about servers not supporting IPv6 as the reason not to use but, but three or four different ways of providing backwards compatibility to all IPv4 clients were thought up and nobody actually asked for any of them. People complained that their data center provider didn't support IPv6 but now that enabling IPv6 is just a single click in a web UI they don't enable it anyway. People cared about the IPv6 privacy risks but never let go of that concept even after rfc4941 fixed that oversight. Companies like Microsoft and Github, too incompetent to set up a network that their dollar store competitors have supported for years now, have become something to point at and go "see? we need those!" as if NAT64/DNS64/464XLAT/SIIT/whatever haven't been providing IPv4 compatibility for years now.

"I don't know enough about it" and "I don't like it" are perfectly good excuses not to enable IPv6 in your home network, but they're not design flaws or protocol problems. If you're willing to accept the packet maiming we have nicknamed "NAT" or even "CG-NAT", you should feel refreshed at the sight of the plain and simple protocols IPv6 provides you with.

The way people talk about IPv6 now reminds me of the way people talked about HTTPS back when Let's Encrypt started gaining popularity, and the way people dealt with systemd reinventing a better Linux management system. Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment. You can be like the Dracut people running ipromiseiwillneverrunssl.com if you want, but it's a losing battle.

If the people who would use IPv6 don't like it and don't want it, if they think it's bad, then it's bad.

When forest rangers observe hikers repeatedly deviating from the official trail at certain spots, the ranger understands this to mean the trail is wrong, and he re-designs it to accommodate the hikers. The forest ranger is able to do this because he understands what the trail is for: it's for the hikers, and he empathizes with and adapts to the hiker's needs, not his own needs, not his ego, not his whims. Never does the forest ranger defend a bad trail. The forest ranger takes feedback without ego, and he is able to do so because he does not personally identify with the trail, he identifies with the needs of the hikers.

Engineers would do well to become more like the forest ranger. Many engineers seriously lack empathy for end-users, which results in the engineer creating inadequate products/services that don't meet the user's real needs. Even worse, when the product/service is criticized, when the engineer is given an opportunity to improve the product, the engineer instead blames the user, rather than himself, rather than adapt and recalibrate to the user's needs, he submits to his own ego, his own pride.

It's this lack of empathy and user-blame that yields poor results, results like IPv6.

It can be difficult to design for people, though. People tend to over- or underestimate the frequency and severity of rare events, are susceptible to the normalization of deviance, and due to their finite nature, fail to consider wider or longer-term implications of their decisions. Going along with the analogy: forest rangers also have a duty to protect the forest (and in fact, I think this ought to take precedent over accommodating hikers) and they also want to guide hikers away from dangerous terrain or wildlife that underprepared hikers may be tempted to visit.

I think the core idea here is "design around the way users actually behave, not the way they ought to behave".

Ain't that the truth. Modern operating systems are getting worse by the year.

That said, IPv6 has been significantly altered. SLAAC was fixed with two RFCs, one a decade IPv6 was designed, and another in 2015 for fixing oversights in duplicate address detection. DHCPv6 got updated with all kinds of options and it was already late to the party. RDDNS got added in 2007 and updated with more options in 2017. IPv6 Privacy Extensions got added when people brought up the privacy issues with SLAAC. People set up their own weird 4-to-6 translation mechanisms so various standards were introduced to cover any use case you may need.

IPv6 as it was originally designed is practically unusuable today. The trails have since been adjusted and the hungry mountains lions are gone. The hikers don't even notice the difference from their old paths.

However, park management decided that hikers should never go down the new and improved trail because they heard a story from their friend once that someone got lost there fifteen years ago, and some of them have lost the map to the start of the trail.

I'm also working on a project to reclaim some IPv4 address space, which people often object to on the grounds that people should "just use IPv6". So I have to defend the legitimacy of the demand for IPv4 address space.

In connection with this issue, I recently ran some DNS lookups against lists of top 1,000,000 domains (the last Alexa one and the Cisco Umbrella one). What we see is that only dozens to hundreds of "top million sites" (depending on one's definition of "sites" and so on) are IPv6-only. That is, less than 0.1% of Internet sites currently have an AAAA record without a corresponding A record, notwithstanding things like Mythic Beasts's offering to sell this configuration to them.

The over 99.9% of sites that still have an A record have it for a very good reason, which is that somewhere around half of all of their users (of course, quite a bit more in some regions and markets, and quite a bit less in others) would be unable to reach them at all otherwise. This is probably going to be true for a long time, even if that fraction keeps creeping steadily downward, and there's not much the site operators can do about that.

On the other hand, maybe you're talking about things like the "A record but no AAAA record" case (sites that don't offer IPv6 support). This is around 45% of FQDNs that have any form of address record, according to my scans using recent Cisco Umbrella data. I don't particularly have a defense of this; in fact, I find it really unfortunate. I happen to also be involved with Let's Encrypt, and I've often seen a pattern where smaller site operators, at least, show no awareness of what IPv6 is and no desire to debug it (e.g. if their certificate request fails because their old AAAA record was broken). I think Happy Eyeballs has been kind of bad on this particular dynamic: small site operators will themselves perceive their sites as working fine with completely broken IPv6 configurations, and it can be hard to convince them otherwise!

I'd love to see some kind of tool, messaging, initiative, or whatever that would encourage the long tail of site operators to be willing to spend, like, three minutes learning that IPv6 is a thing and that it's good if they have it set up correctly rather than not having it set up correctly. I still don't know what that would look like. I've seen dozens, if not hundreds, of forum posts telling people various forms of "it looks like your AAAA record is out of date; maybe you should delete it".

A records work on v4 and v6, so they'll probably stick around for a while. Perhaps they'll end up being concentrated around 4-to-6 forwarding NAT-as-a-service companies, but they're the fallback mechanism. I don't think anyone is advocating for dropping A all together unless you're really trying to pinch pennies.

> I'd love to see some kind of tool, messaging, initiative, or whatever

If Google and Microsoft decided to put even the slightest bit of preference towards IPv6 capable websites, I think SEO hacking would do the rest for us.

> like, three minutes learning that IPv6 is a thing and that it's good if they have it set up correctly rather than not having it set up correctly

Learning to set up IPv6 properly will take more than three minutes. As much as I think IPv6 is a better designed protocol now that the necessary RFCs have come out, there's still a huge difference with legacy IP stuff. The concept of link-local addresses needs to be conveyed or people will put fe80:: addresses in their DNS records, and concepts like /48 or /64 subnets representing customers needs to be explained to prevent bots and spammers from taking over. Unlearning NAT and realizing NAT≠firwall is also something that can take surprisingly long. Enabling IPv6 may take five minutes, but the required background knowledge can take a day or more of learning and experimenting.

Internet forum posts about deleting AAAA records are a great helpfulness thermometer for a forum. I treat them the same as the "just disable SELinux" posts; if that's a popular opinion, the forum probably doesn't know what it's talking about so all advice that gets upvoted there needs to be taken with a grain of salt. They're a problem, but also a warning beacon.

NAT is certainly not a firewall, but it is a very useful router function. I still don't understand how IPv6 makes NAT a thing that isn't useful to know.

I want to expose my servers to the internet through a single shared IP address, and to be able to have those servers exist on different IP addresses inside my network. How does IPv6 allow this without NAT?

But what if you insist on not using a proxy for whatever reason?

When people say "NAT", they're usually talking about SNAT/MASQUERADE, i.e. NATing outbound connections. What you're asking for here is port forwards/DNAT, i.e. applying NAT to redirect an inbound connection.

If you want to NAT inbound connections, you can do it without NATing outbound connections. Essentially: you don't need to "NAT", you just need to port forward.

Honestly, I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running -- it only takes scanning 65k ports on one IP to find them all, rather than 65k ports on 2^64 IPs. That's the difference between megabytes and yottabytes of port scan traffic.

(If you NATed outbound connections to also come from this IP then things get even worse because every outbound connection from any of your machines immediately informs the server of the IP needed to make an inbound connection to you. That's a completely unnecessary security sacrifice.)

But if you're going to run everything on one IP without proxying, you only need port forwards to do it, you don't need to run the network on some local IP range too.

> I think you should just suck it up and use different hostnames for different services, because running all of your services on one IP is really bad for security since it makes it much easier to enumerate every service you're running

I really, really don't want to do this for a ton of reasons. Port scanning isn't high on my security worries, to be honest. I've been dealing with that for decades and am well-protected, so that's not a compelling reason for me.

Am I misunderstanding what you mean by "the world" here? Most of the networks I work with are not HTTPS on top of UDP or TCP.

> Grumpy people, clinging to what they know, delaying unavoidable change until the very last moment

This seems unrealistically broad. For all of the things you cite, there are downsides along with upsides. For all of them, we lose something as well as gain something. That means there's a cost (even ignoring the cost of making the change itself) as well as a benefit. That means a cost/benefit calculation takes place, and the results of that calculation are not guaranteed to be in favor of the replacement tech.

In my own experience in our household, IPv6 destroys privacy.