So I know that there are extensions to SLAAC in the works to enable DNS discovery via RAs (RFC 6106). But what was the original intent? How did the IPv6 designers envision things working without DNS? Why did multicast DNS get dropped from Windows? I can find lots of info on SLAAC, its lack of DNS support, and the SLAAC/DHCPv6 debate (and the proposed, and yet unsupported, extension) but no discussion of the original rationale.

3 Answers
3

The original (and still valid) idea is to combine IPv6 addresses with SLAAC/autoconf with Router Advertisements (RA's), combined with Stateless DHCPv6 for all other options like DNS. This makes the DHCPv6 server very simple because it doesn't have to maintain a leases database and things like that. It only needs to tell the client all the extra options like DNS domain and resolver.

The way I've read things is that DHCPv6 was a workaround introduced after the fact, and the ideal situation is to use "pure" IPv6 autoconfig.
–
babMay 24 '12 at 14:55

Not really... RA's contain routing and addressing information, and DHCPv6 contains all other options (and optionally also addressing). Later some DNS information was added to the RA (RFC5006/RFC6106). That was the after-the-fact addition, not DHCPv6. If you want maximal compatibility you can do both RFC6106 and (stateless) DHCPv6. Then the operating system can choose what to use, depending on what it supports.
–
Sander SteffannMay 28 '12 at 8:03

Maybe the rationale is that IPv4 wasn't going away any time soon, and that using a v4 resolver (which can return AAAA records) would be an acceptable solution until a workable RFC is ironed out for native v6 configuration?

The IPv6 design was pretty academic at its inception, I would look at the IETF IPng working group mailing list and doucment archives if you want the whole story. But the charter was to replace just the IP layer, leaving all of the higher-layer protocols to others. Remember that IPv4 didn't have DHCP, BOOTP, or even DNS until many years after deployment. Getting those things to work on IPv6 was left to other IETF groups.

The other IETF groups didn't exactly jump on the IPv6 bandwagon right away, nor did vendors, implementers, ISPs, network admins, or anyone else. So now we have a right mess on our hands.

I don't think SLAAC came in until later in the IPv6 development process, but even so it only deals with the IP layer, and nothing else. Additions to SLAAC that include non-IP information (such as DNS) are very recent
–
rmalayterMay 28 '12 at 0:23