Hacker News Reader

> 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 :)

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

Eek I wouldn’t want to be able to reach my at home devices from anywhere like that. If I can, anyone can.

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

Couldn't one implement NAT for IPv6 too? Is there a reason why not?

You should sit down and just do it. It's really not that complicated.

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.

IPv6 is relatively simple. However it is hard to learn if you are coming from IPv4 and you try to relate everything back to that.

If you approach IPv6 as "oh so this is how IPv6 does X" or "this is the IPv6 name for Y" then it's going to be confusing. It's not just IPv4 with bigger addresses, its a new approach to addressing and sending information between endpoints.

See, a general problem I see with IPv6 and all the protocols around is their enormous complexity. As a hobbyist in the last decades, you could learn about IPv4 and DHCP in a couple of afternoons. It was simple the same way as HTTP1 was simple compared with HTTP2. Complexity means the learning curve is enormous and in the end only a fraction of experts will understand.

That's not really the real internet, though. How much did you learn about MPLS and BGP and ISIS from working at home as a hobbyist? I didn't know much of anything about that stuff before I started programming routers and switches (real switches - like the ones your ISP uses).

IPv6 is so ridiculously similar to IPv4, it's a bit funny reading about people complaining about how different they are. Seriously - go to wikipedia and read about something like ATM and how crazy different that is. Compared to the stuff you actually need to know and should know about if you're a network admin, IPv6 is easy-peasy.