I wouldn't put much stock into that article. Many of their points are IPv6 pros (and the sections seem to make that clear), and many of the cons simply boil down to IPv6 being different, often necessarily so--for example, PTR records for a 128-bit address space were always going to be long even if the delegation prefix chunks were larger (e.g. 8 or 16 bits instead of 4). And I don't see how any of those problems constitute a nightmare.
The only real pain point for IPv6 deployment IME is DHCP.[1] DHCPv6 was never even supposed to be a thing; the very fact that it exists shows that the alternatives can be replaced or supplemented. But either way this problem really comes down to tooling and operating system support. IPv6 deployment and the standards and software for deploying it will mature together, and complexity will ebb and flow as alternatives enter and leave the fray. It could never have been any other way. IPv4 was hardly without its hiccups. Heck, the switch to classless IPv4 addressing was somewhat bumpy and confusing even as late as the early 2000s simply because a lot of software, including standard tools like ifconfig(1), didn't make it ergonomic or even possible. Frankly the latent complexity is still annoying.
I think it pays to remember that a lot of these articles are written by people with an eye toward job recruiting, interviewing, and generally grooming their credentials. The conclusions don't matter, they're just an excuse to exhibit familiarity with the technical details. They're a sales pitch for the author, and that essay is a particularly good one--the author demonstrates a comprehensive familiarity with the issues, notwithstanding their framing and conclusions.
[1] The biggest pain point in earlier years was the need for BSD Sockets API support in application software. But it seems we're mostly over that hump, notwithstanding the regressions caused during the shift to cloud computing, where IPv6 support was and remains much more immature than in the wider ecosystem.
Why?
I don't know if DHCPv6 will win the day, or the vision of a leaner, more distributed addressing and routing infrastructure will prevail. And I don't have any opinions on which is better. I just know it's all rather confusing and still in flux.
I'm one of those. Say I connect my new Pi Zero to the network, and I want it to be a server of some sort.
In a IPv6-without-DHCPv6 world, how do I make sure I can always reach my Pi server?
With DHCP it's easy, I can assign it a fixed lease in the DHCP server and the DHCP server automatically registers the name in the DNS server for convenience.
How do I get the same when using IPv6-without-DHCPv6. Keep in mind my IPv6 prefix changes frequentl, sometimes multiple times a day, and this is out of my control (changing ISP is not an option).
Judging by the list of standardized IPv6 Neighbor Discovery Option types, https://www.iana.org/assignments/icmpv6-parameters/icmpv6-pa..., it seems like that's exactly what is happening. Not only does that list make it seem like RA/ND ICMP messages are being used/abused to mirror 1:1 their DHCP field counterparts, but several of those RFCs define RA/ND and DHCPv6 options together.
I'm curious: what sort of meaningful network management possibilities, beyond stateless addressing, are made practical with RA/ND that aren't with DHCPv6, especially considering that stateless DHCPv6 is a thing? At first I thought it might be easier to relay/passthrough specific extensions, but a cursory reading of RFC 4861 (Neighbor Discovery) makes me think you can aggregate these options in the same packet, in which case it would be no more easier (from the perspective of implementations) to selectively relay these configuration parameters than with DHCPv6. And if I'm also reading RFC 3315 (DHCPv6) correctly, ND is an even better DHCP as solicitors/requesters can selectively query specific options rather than the advertisers/responders having to send all options down in the same reply.
If RA/ND is already being used/abused this way, why would people dislike DHCPv6 on principle, as opposed to disliking DHCPv6 as unnecessarily duplicative (notwithstanding that it came before most of these ND options). If anything I would think such people would be advocates for DHCPv6 if they were afraid of ND becoming a dumping ground for extensions unrelated to fundamental addressing and routing issues.
At this time of writing the issue is 8 years old and it is still spurring discussion.
DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
> DHCPv6 does exist, but I don't really understand what it offers over RA+ND.
How does RA/ND solve the problem of client auto-configuration of services? Rightly or wrongly, DHCP has been traditionally used for service discovery ("Hey! Here's some NTP servers, a TFTP server and a SIP server") as well as config discovery (useful for autoprovisioning of many devices) and I didn't think you could achieve that just with RA/ND.
Has anyone managed to get netboot or PXE working on IPv6 without DHCP?
Edit just saw a sibling thread about DNS adverts in RA. I guess RA could do all these things, but if it doesn't support it today, DHCP is going to fill the gap.
Specifically I'm referring to:
- RFC4864 | Local Network Protection for IPv6,
- RFC6092 | Recommended Simple Security Capabilities in Customer Premises Equipment (CPE) for Providing Residential IPv6 Internet Service and
- RFC7084 | Basic Requirements for IPv6 Customer Edge Routers, which pulls in the other two by reference.
In fact RFC4864 is specifically about this "Perceived Benefit of NAT" and how to preserve the security benefits in the v6 world.
[RFC4864]: https://tools.ietf.org/html/rfc4864
[RFC6092]: https://tools.ietf.org/html/rfc6092
[RFC7084]: https://tools.ietf.org/html/rfc7084
Just as an example, OpenWrt, a more consumer focused router distribution follows RFC7084 and provides the default deny behaviour on IPv6 ingress from WAN much like IPv4-NAT would do.
Also note that IMO the author is simply conflating NAT as known in the IPv4 world with it's usual implementation of actual Address Translation plus Stateful firewalling. In fact prefix translation which he's going on about here isn't necessary at all to be exposed to this security problem.
Just plugging a IPv6 (and DHCPv6-PD) capable router into a WAN would do if it weren't for the stateful firewall.
I've been running pfSense for years, but it's clear that it just is not made with residential IPv6 in mind. Been looking at the NanoPi R2S, think I'll try out OpenWrt on that as a replacement.
I feel like I should point out that in IPv4 NAT you also still have a firewall to drop incoming traffic unrelated to anything.
NAT just happens to serve as a form of firewalling in IPv4 land because usually, the stuff behind your router has a private address.
Proper firewalling is a matter of policies; it's completely orthogonal to whether your devices have a globally routable address or not.
Until all firewall and router mfgs. re-QA every little feature added for IPv6, you don't really know what your equipment is doing.
The tech support team even confirmed that ipv6 firewall support is coming ‘soon’.
Meanwhile my ASUS router’s ipv6 support is broken as well for dns configuration.
So, yeh it is still early days for consumer ipv6 adoption.
I was actually referring to rack gear, but hey.
Are you IPv6 fanbois?
Have you audited all the firmware and software on your firewalls and routers?
Your comment contained no information above "I don't trust it".
Are you for real?
There's been decades of production experience with IPv4 and does mostly what's expected.
Of course IPv6 shouldn't be trusted.
New software has bugs. That applies doubly for networking code.
Get your fuzzers started ...
IPv6 version NAT - NPT
``` Remember, this will blindly just swap prefixes in and out. Gone are the days of “only the traffic I explicitly create a rule for can get in”. See, now, just adding that one step will, be default, expose your entire network! You now need firewall rules to block what you don’t want and add explicit allows, this time manually as an additional step. This is more of a “default pass” routing — unless I tell you not to, let it through. ```
This seems like a great security concern Would be good to know if this statement is accurate
I might consider disabling IPv6 if this is true