To:
Jun-ichiro itojun Hagino <itojun@iijlab.net>
Cc:
"Tony Hain" <alh-ietf@tndh.net>, "Nathan Jones" <nathanj@optimo.com.au>, ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From:
Johan Ihren <johani@autonomica.se>
Date:
15 Aug 2001 11:57:01 +0200
In-Reply-To:
Jun-ichiro itojun Hagino's message of "Wed, 15 Aug 2001 17:57:32 +0900"
Sender:
owner-dnsop@cafax.se
User-Agent:
Gnus/5.070095 (Pterodactyl Gnus v0.95) Emacs/20.3
Subject:
Re: (ngtrans) Joint DNSEXT & NGTRANS summary
Jun-ichiro itojun Hagino <itojun@iijlab.net> writes: Hi Itojun, > >I'm pointing out that due to the configuration change that will follow > >from deployment of v6 roots it will be comparatively easy to reach all > >the caching resolvers (i.e. name servers) on v6 transport to ensure > >that they all do AAAA synthesis. > > isn't it just a root.hint change, not a server replacement? Well, if you are running in a forwarding configuration *with your present server* and replace the root.hint file with one that includes v6 glue for one or several roots not much will happen. So there is no point to it. Because you are using a forwarding configuration. However, what you want is a root accessible over v6 transport (and of course all the TLDs, etc, etc) so that you can move away from your forwarding configuration. However, to avoid walking around in a barren wasteland of almost no DNS hierarchy initially I strongly suspect that you would like some sort of fallback mechanism so that you can still get to the data that is presently only available over v4 transport. But to do that you *will* need a server replacement, since no server deployed does that today. There are various icky schemes for doing such transport bridging (Alain Durand and I have spent some time in that mess and there is a draft outlining some of the problems). All of these schemes are ugly, but without something like that I see little point to the v6 roots that you want. So, I still claim that the time of deployment of v6 glue for the first root is a "magic date" since that will initiate a configuration change and in all likelihood a server replacement for all the v6 caching resolvers that want to utilize this v6 root for anything useful. Look at it as a synchronization barrier for IPv6 DNS functionality. Johan Ihren