[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]


To: Robert Elz <kre@munnari.OZ.AU>
Cc: ngtrans@sunroof.eng.sun.com, ipng@sunroof.eng.sun.com, dnsop@cafax.se, namedroppers@ops.ietf.org
From: Alain Durand <Alain.Durand@sun.com>
Date: Tue, 14 Aug 2001 22:55:37 -0700
In-Reply-To: <15663.997800535@brandenburg.cs.mu.OZ.AU>
Sender: owner-dnsop@cafax.se
Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

At 09:48 PM 8/14/2001 +0700, Robert Elz wrote:
>
>No, assuming you're right, long term what will happen is that people
>will lament that the wrong decision was made in 2001, but regret that
>there's no way to transition any more, the combination of resolvers
>doing only AAAA lookups, and servers providing only AAAA records, means
>there's no clean way to get out from under (sure, servers could provide
>A6 records as well, but they'll have to keep providing AAAA records
>forever to keep the old resolvers happy, and resolvers could do A6 lookups
>but they'd have to fall back on doing AAAA so they can find names that
>are only available that way - given that AAAA would have to remain, and
>resolvers would have to do lookups of it, just for practical reasons,
>there's no way to actually transition to A6).

Doing AAAA synthesis at the resolver side helps a stub resolver that
knows only about AAAA to get data from servers that knows only about A6.
This transition scenario will work if we can upgrade the resolvers
at the same time we introduce A6 in the servers. (note that upgrading
the resolvers is a much simpler task than upgrading all the stub resolvers)

Still, it may not be possible to upgrade them all before we introduce A6
in some servers. So what you are highlighting is the need for servers
that are populated with A6 to answer resolvers (not stub-resolver)
that know only about AAAA.

Of course, as you mentioned, servers could be manually populated with AAAA
at well as A6, but there are other possibilities. In other words, we have
to explore AAAA synthesis done at the server side:

   - the server could automatically generate all the corresponding AAAA records
     when loading its A6 database. Of course, the missing pieces will have to
     be provided.
   - the server could generate AAAA on request.

Of course, there are drawbacks and issues with such mechanisms
and more study will have to be made to understand them, but they
are transition mechanism and as such, do not need to be perfect.

The point i'm trying to make is that by combining AAAA synthesis
at the server side with AAAA synthesis at the resolver side, we
may have a way to transition from an all AAAA world to a world
with a mix of AAAA and A6 if/when we need it.

Note also that such techniques would have to be used now if we decided
to move to A6 today.

         - Alain.


Home | Date list | Subject list