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