But would we have said the same in 1996 or 2000? Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4. And a good chunk of the complexity of IPv6 is that some of the early ideas are very persistent, both in some deployed systems and in people's minds

> But would we have said the same in we 1996 or 2000?

IPv6 the protocol supported NAT just as well back then as it does now, but the software probably didn't. Which goes back to my point [0] [1] that IPv6 is a great protocol with bad tooling and documentation.

> Part of the adoption curve seems to be that it took years to abandon some of the bad ideas around IPv6 and readopt some of the better ones from IPv4.

The only abandoned IPv6 concept that I'm personally aware of is A6 records [2], but I'm pretty young, so I'm sure that there are others that I'm just not aware of. My impression from reading the RFCs and Wikipedia is that IPv6 hasn't changed very much, but that doesn't really mean anything, since I wouldn't expect for current sources to talk about concepts abandoned 20+ years ago.

[0]: https://news.ycombinator.com/item?id=47814070

[1]: https://news.ycombinator.com/item?id=44773999

[2]: https://datatracker.ietf.org/doc/html/rfc6563

Just because it technically supported something in some RFC it doesn't mean you could get affordable and capable equipment supporting it.

> IPv6 supports NAT

You say that, but in practice it does not.

My consumer router, and every router I have configured, implicitly supports IPv4 NAT out of the box. But it will never NAT an IPv6 network. If I enable IPv6 then it operates by IPv6 rules, which means each device gets a Network ID and each Network ID gets routed directly and transparently. The router has no NAT table and no NAT settings for this protocol.

So if NAT is “supported” whatever that means, it simply isn’t possible for most end-users.

Consumer routers don't support lots of useful stuff though, so them not supporting NAT66 isn't very surprising. Enthusiasts are likely to use OpenWRT or nftables, both of which support NAT66 [0], and quickly Googling some random enterprise routers shows that they all support NAT66 too [1] [2] [3].

This isn't enabled by default because it's usually a bad idea, but it's certainly possible if you really want. (It's discouraged because NAT in general is a bad idea, but it's no worse with IPv6 than with IPv4; the only difference being that IPv4 effectively requires NAT.)

[0]: https://openwrt.org/docs/guide-user/network/ipv6/ipv6.nat6

[1]: https://www.cisco.com/c/en/us/td/docs/ios-xml/ios/ipaddr_nat...

[2]: https://www.animmouse.com/p/how-to-nat-ipv6-in-mikrotik/

[3]: https://www.juniper.net/documentation/us/en/software/junos/i...

IPv6 DOES support NAT.

If you've got a car that can't go 100, that doesn't mean nobody can, or that it doesn't exist. I don't care if you can't do it, it IS supported in the spec.

That’s an interesting analogy because there’s several ways you could easily dismiss it.

For example: if roads aren’t built to support cars travelling at 100 miles per hour then it doesn’t matter how much you argue that cars are can do 100MPH, because you’re still not going to be travelling at 100MPH.

Or

But if the only cars that can travel at 100 MPH are Bugatti Veyrons then it’s safe to say that 100MPH cars isn’t something available to even the average consumer of high end sports cars.

Or

Sure, some cars can travel at 100 MPH, but they’re so unstable at those speeds that it’s not even safe to attempted it.

…You get the idea.

That is the same argument with USB, USB support x, but 90% of USB dont implement it. In reality that is no different to not supported.

NAT is evil!