It will be interesting to see what the Moonv6 work may have to say in this area, as the issue I'm sure will have been encountered there. There are still very few people working in networks where IPv6 transport DNS lookup is a requirement, hence this issue has seen slow progress.
I know, and in practice there won't be many hosts that run just IPv6. But what good is a new protocol if it can't stand on its own two feet and needs its predecessor to provide crucial functions?
At least the new MacOS that's coming out tomorrow supports DNS transport over IPv6, making it possible to run IPv6-only. This is pretty cool.
I am in the RA camp, but I agree DHCPv6 will be used for other things
(e.g. NTP server), so in cases where a DHCPv6 server is present it will be able to be used for resolver discovery. But I believe we should have a RA based method also.
A strong argument against using DHCPv6 would be that stateless autoconfiguration definately has the edge over DHCP so we can expect very many people to continue using autoconf even when DHCP implementations become available. Requiring DHCP in addition to stateless autoconf for just one thing that can also be done using mechanisms that autoconf uses would mean unnecessary complexity and delays.
But it shouldn't be one or the other. We want/need both.
The general thrust of the DHCPv6 camp argument is that in any situation where a router is configured to pass DNS info in a RA extension it could equally be configured to do so using DHCPv6 (Lite), or could forward to a DHCPv6 server using the DHCPv6 relay agent function.
I doubt that many people will be using DHCP servers with IPv6. The reason to use them in IPv4 is so you can have stable addresses across reboots. Stateless autoconfiguration already supports this much better than DHCP ever did. And let's not forget that autoconf has been available for years while DHCPv6 is just now becoming somewhat available.
The second argument used by the DHCPv6 camp is that having two methods may lead to complexity, and problems in troubleshooting.
That would be a good argument to kill DHCPv6 altogether. Having to run autoconf for the address and DHCP for nameservers is exactly the complexity we should avoid.
The third is a fear of creeping featurism - where is the line over which you don't step for RA extensions? DNS resolver? Search path? NTP?
When was the last time your browser couldn't load a page because the NTP server wasn't found?
-------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
