Note that in the absense of DNS resolvers reachable over IPv6, either due to failed discovery and/or lack of configuration, DNS resolvers reachable over IPv4 may be used, if available.
This is exactly the intent. As long as you're dual-stack, there is no hurry to worry which mechanism you start use to discover v6 resolvers.
There is no hurry on the part of operators, they get to do what they like. However, implementors must supply operators with the tools they need.
This is another obviously bogus so-called "show-stopper" (compare to the request of waiting for root DNS servers to be dual-stack; another unnecessity).
These are religions/policitical reasons only, and I'd like to keep that part of the debate out of here.
None of this is bogus. Running dual-stack has almost no advantages over running IPv4-only, it is imperative that we make it possible to run IPv6-only, as this is the ultimate goal. Implementations that require IPv4 for critical functions, even if it's only for a small set of such functions, are useless in the long run. And just because we update a spec doesn't mean people get to have implementations that conform to the new version any time soon, so we have to get it right from the start if at all possible.
Therefore I'm reluctant to change the tone of the text.
If you prefer to duke it out at IESG last call that's fine with me.
BTW: how does a dual-stack host know whether to use v4 or v6 resolvers?
Depending on the ordering of resolv.conf.
Well, if a hand-crafted resolv.conf is authorative here, why are we wasting our time on all these discovery and autoconfiguration issues??
. dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
