Really, if you look back at the archives of this list these arguments are starting to get "silly" as you put it.
Yes and no...
It seems that every few months, as people discover that IPv6 isn't going away and they should brush up on it, people go through this process of debating the way IPv6 was designed as if it were 1998, and ultimately make posts like this.
This may apply to some fraction of posters, but, I think many of the posters in this thread are actually fairly knowledgeable on IPv6.
IPv6 is simple, elegant, and flexible.
Parts of it are. Other parts are rigid, inflexible, and represent design decisions only theorists could love.
DHCPv6 was always a core component of IPv6 (just like ICMPv6 is a core components of IPv6, or should we throw ping and traceroute into RA as well...)
The intertwining of RA/DHCPv6 as it currently stands in IPv6 is an example of a design decision only theorists could love. In the real world, you have organizations where the people that manage hosts and host policy are not the people that run routers. In such environments, creating this kind of cross-organizational dependency that requires a constant coordination of even trivial changes on either side is far from optimal.
This is why we have flags in RA to signal how addressing is done on a network for a prefix:
A - Autonomous Flag, allows hosts to perform stateless addressing for a prefix. O - Other Flag, signals that additional configuration information is available (such as DNS) and DHCPv6 should be used. M - Managed Flag, signals that hosts should request a stateful address using DHCPv6.
That's all well and good, but, when you consider the real world implications, it starts to break down in most organizations... Now, the people that run the routers have full control over the selection of addressing schemes for the network. The people who set host policy have no control short of statically configuring the hosts or getting buy-in from the people that run the routers for their particular preference in address selection methods. Yes, in a theoretical world, everyone gets along and cooperates easily and stuff just works out with whatever decision is agreed upon. In the real world, this becomes a constant source of tension between the two groups and increases workload on both sides of the equation unnecessarily.
The real point, initially at least, for stateless addressing was to make the Link-Local scope work. It's brilliantly elegant. It allows all IPv6 configuration to be made over IPv6 (and thus use sane constructs like multicast to do it).
All well and good, but...
Router Advertisements shift gateway and prefix configuration to the routers (which are the devices that actually know if they're available or not) rather than a DHCP server. If you set things up right, making a change to your RA will be seen by hosts almost instantly, and you won't need to go through the headache of waiting for DHCP leases to expire before hosts see that a network isn't available and let go of that route.
Which also means: 1. Multiple subnets on the same media that are intended for different hosts and have different routers are no longer feasible. (Yes, you can argue they're less than desirable in IPv4 and I would agree, but, they exist in the real world for a variety of layer 8-10 reasons and re-engineering an organization to make it fit into IPv6 is non-trivial). 2. RA has the problem of treating all routers claiming to have the same priority are of equal value to all hosts. Routers are considered fully interchangeable units and it is assumed that all routers are a viable path to everything. DHCPv4 actually provides facilities for dealing with more complex topologies where different destinations may be in different directions from different hosts. It also allows for providing different default gateways to different hosts based on policy decisions. Yes, in the most basic cases, RA can be superior to getting routing information from DHCP. However, in the real world, there are many cases where it simply breaks things and is a step backwards from capabilities in use in IPv4.
One thing to keep in mind is that even though DHCPv6 and DHCP have a similar name, they're still pretty different. DHCPv6 was designed as part of IPv6. DHCP was an afterthought. Like many things in IPv6, they have been re-designed and included as a core component of IPv6. Don't go making assumptions that DHCPv6 was "added" to IPv6 to turn IPv6 into IPv4, and don't try to modify DHCPv6 to make that the case, please. What is needed now is protocol stability, and implementation of the current standards, not the re-writing of them mid-deployment.
While you have some things right in the first half of that paragraph, there are real world problems with the approach in the second half and there are changes that are needed. RDNSS is a positive step in the right direction (making router-centric host configuration more viable). Making server-centric configuration more viable is also necessary.
RDNSS is what I would consider "silly". IPv6 already allows for an environment in which stateless is used and DHCPv6 only provides DNS (and other) information. This is because none of the flags are exclusive. In fact, you can use both Stateless and DHCPv6 on the same network, and host will get two IPv6 addresses (for example to configure servers with pre-determined addresses). This was the design intent.
That's all great in a purely theoretical world or a small organization. In the real world, there are many organizations for whom that set of tradeoffs and combination of dependencies is far from optimal.
If you don't use DHCPv6 to assign addresses and are using SLAAC, you can still use DHCPv6 to provide other information only, or "DHCPv6 Light", and this is already supported in most routing platforms to be configured right on the router.
Which is a major change in the administrative boundaries for the vast majority of enterprises. Such changes may not be so welcome at the layer 8-10 levels of the stack and may, indeed, create substantial resistance to deployment.
Implementation-wise, DHCPv6 Light and RDNSS have almost no difference. What RDNSS manages to do is embed DNS into RA (where it doesn't belong IMHO) seemingly for the sake of not calling it DHCPv6.
Only in theoretical implementations or implementations where the routers and host policy are administered by the same organization.
Keeping DNS information out of RA is a Good Thing (which makes RDNSS a Bad Thing). Why? Because DNS might not always be the method we use for mapping names to addresses; it might see a rewrite like IP itself has seen, and there will likely be a desire to provide hosts with more configuration information. Looking DNS information into RA is a slippery slope. What's next, another option to RA for next-server information?
Which is why it would be better if RA supported a more flexible set of host configuration options rather than just cobbling DNS onto it.
DHCPv6 is separate from RA because they know that the needs for host configuration are more likely to change over time than IPv6 itself, and keeping them separate keeps IPv6 stable.
I guess that really depends on your perspective. In the real world, it does a better job of keeping IPv6 from getting deployed in the enterprise.
The question isn't "Stateless or DHCPv6". The question is "Why are people implementing IPv6 without a core component?" That's pretty much like saying you support IPv6 but not including ICMPv6 or MLD.
This framing of the issue utterly ignores the reality of how things are handled in the real world and what happens in the enterprise environment across organizational boundaries.
This isn't a war of Stateless vs. DHCPv6. They're both the same thing. They're both core components of IPv6, and they both provide specific, non-conflicting, functionality. The argument of "Having to implement DHCPv6 is more work" is "silly" for these same reasons. "Well I'm not going to support address scope because that's more work."
It certainly was such a war for some time in the IETF and it was carried out in a way that much damage was done to both sides of the equation. The end result is a construct with a very limited set of choices for implementers almost all of which include cross-organizational interdependency in most enterprise environments that will create continuing friction and exacerbate the usual level of dysfunction.
Thankfully, with Apple seemingly supporting DHCPv6, that means Windows, Linux, Mac, and BSD will all have full IPv6 implementations, and if you don't want to use DHCPv6 for addressing you don't have to.
However, if you want to put host policy completely in the hands of the host administrators, you still can't. If you want to have the router administration group provide a complete set of host parameters, you still can't. The only way to provide a complete set of host configuration information through automated processes is to get some fraction from the routers and some fraction from other servers. This should be improved.
If the goal was really to keep DNS simple for IPv6, rather than RDNSS, they should have written an autonomous anycast or multicast DNS spec rather than cluttering up RA with DNS server messages. RDNSS is a cancer IMHO and I hope we don't see it implemented.
We can agree to disagree.
DHCPv6 has nothing to do with "wanting to do things the way we always have". It has everything to do with "we might not always do things the same way we do today, so lets split this from being in RA". When it comes down to it, for hosts that provide content (servers) you'll always need a way of knowing that address. I'm sure manual IPv6 configuration works fine for you, but in something significant, say a VM cluster, I for one would rather not go back to the dark ages of manually configuring IPv6 addresses on each host.
True, as far as it goes, but, there is also an issue of not wanting to completely redesign the org-chart because IPv6 is utterly dysfunctional with the current organizational boundaries. In some organizations, you have to get up to the point of a VP before you find common management shared by the groups that have to cooperate in the current implementation. The average VP regards the details of host configuration relatively below his pay grade and will likely consider any protocol that requires major changes to his org chart to be, well, broken.
Privacy addressing is more to mask the MAC address of a host than to provide "privacy". This is because some systems are easily identifiable by their MAC address, such as Apple computers, and embedding that into the source IP provides potential attackers with a guess as to what the device is. That said, host that use both DHCPv6 and Stateless addresses will use their stateless address for new outgoing requests, by the way, effectively making the stateful address an alias. So I'm not sure what the issue is here.
Uh, no, it's more to mask the MAC address of devices that move around so that you can't track their movement easily by matching up the last 64 bits of their IPv6 address and using the first 64 as a location identifier.
Apple is probably cringing at this thread going on for so long and not getting berried because of the inaccurate topic. :-)
Whether or not Apple is cringing, this thread (or something like it) will probably continue until theory and implementation in IPv6 advance to the point of matching reality. Owen