> As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons.
The same is true for IPv6! Granted, beginner-friendly documentation is a bit harder to find, but I was able to set it up for my home network through OpenWRT in a couple of afternoons as well.
In the process, by necessity I also learned something about setting up local DNS properly, which in the end has been very beneficial also for IPv4 hobbyist use cases.
The comparison with HTTP1 vs. HTTP2 seems a bit unfair – it was never possible to write plain IPv4 packets to the network via Telnet/nc.
And if you're talking about the availability of tooling: Don't forget that IPv4 is several decades more mature than IPv6 :)
One could implement a rudimentary IPv4 stack in a couple of afternoons. There is not much magic in parsing Ethernet / ARP / IPv4 / UDP. For IPv6, a node needs to speak ICMPv6/NDP/MLDv2 which are all orders of magnitude more complex than their predecessors.
All your points are valid. I have to be honest, I was always scared off the sheer amount of protocols and ressources around IPv6. It felt that I have to deal with anycast, self-organized networks, anonymous embedding of MAC addresses, some NAT-replacement, etc. when I touch IPv6. It's probably not true and one can start with IPv6 also in a simpler fashion. Maybe I'm also just too much used to ifconfig and nat tables that the switch feels hard.
The comparison of HTTP1 vs. HTTP2 is in fact only valid on a level of complexity.
As an hobbyist, I'm actually quite excited of finally abandoning NAT and being able to reach my Raspberry at home from anywhere in the net. This dream is still far away, given that many places don't have access to IPv6 (without a tunnel).
Yes, firewalls are very much required for IPv6 home networks.
Default global reachability is definitely not advisable, but having the option for individual devices and/or ports is just great, and doubly so with not having to resort to using non-standard ports.
I've always despised the pattern of having device 1's SSH exposed on port 22001, device 2 on 22002 etc., especially for protocols/applications not supporting SRV records.
And for many client to client use cases these days, port forwarding isn't even necessary: UDP hole punching is just a breeze with IPv6 and works consistently and reliably without any STUN/ICE guesswork, as long as UDP is not outright blocked.
Home routers with IPv6 sensibly default to deny all from the internet, so you get the same security position as you would on IPv4 with NAT. As others have said the difference is you now have flexibility to open stuff up if you want to.
In theory. I very much want IPv6 to take over, but a firewall does not provide the same level of security as a NAT when a bug is found.
If a bug is found in a non-NAT firewall that prevents it from blocking a packet for some reason, you have a routable address from the outside that you can send packets to. If a bug is found in a NAT firewall that prevents it from blocking a packet, it's very difficult to tell the router which internal address to route the packet to since the IP header only holds 1 "TO" address and by necessity, that's the public address of the NAT firewall.
There are of course some edge cases (double-headers, being on the same L2 network as the firewall, etc), but for most cases, the fact that the internal network is on IP addresses that won't route to their public interface (the NAT firewall) is in and of itself a layer of protection.
Personally, I think this trade-off is worth it in the long run, but it's simply not correct to claim they are equivalent when router firmware bugs are still discovered on a regular basis and consumer network equipment rarely gets security updates (and it's even rarer for consumers to install them).
The same is true for IPv6! Granted, beginner-friendly documentation is a bit harder to find, but I was able to set it up for my home network through OpenWRT in a couple of afternoons as well.
In the process, by necessity I also learned something about setting up local DNS properly, which in the end has been very beneficial also for IPv4 hobbyist use cases.
The comparison with HTTP1 vs. HTTP2 seems a bit unfair – it was never possible to write plain IPv4 packets to the network via Telnet/nc.
And if you're talking about the availability of tooling: Don't forget that IPv4 is several decades more mature than IPv6 :)