Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Robert Elz <kre@munnari.OZ.AU>]

    Date:        Tue, 14 Aug 2001 22:55:37 -0700
    From:        Alain Durand <Alain.Durand@sun.com>
    Message-ID:  <5.1.0.14.0.20010814140706.01aa6d98@jurassic>

  | 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.

yes, sure.

  | 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)

It would work if we did it now.   There's no way we can ever upgrade all
the resolvers (the real resolvers, the back ends) once IPv6 becomes mainstream.
Just imagine now that you wanted to upgrade all the IPv4 resolvers (back end
resolvers) - there's simply no way.  When IPv6 starts being deployed the
net will be able to grow faster than it has, it is going to be lots
bigger 5 years from now than it is now.   Upgrading anything that requires
everyone to upgrade anything at all will simply be impossible.

  | Still, it may not be possible to upgrade them all before we introduce A6
  | in some servers.

Actually, it would probably be easier the other way.   Adding anything in
zone files requires deliberate administrator effort.  People will only do
that if there's a benefit.   On the other hand, AAAA synthesis can be
slipped in along with other changes in back end resolvers, so that people
(some people) would have it without really even realising it.   Some people
have it now without realising it...

But there's no way to get everyone to have it - which means that administrators
will always have to add AAAA records so those people can find their web
server, mail server, ....   And if AAAA records have to exist, and resolvers
will be looking for them (because no way are all servers going to start
supplying A6 all at once, even with a fairly broad concept of the time quantum)
then there's no point adding A6 records at all - they'd be just one more
thing that has to be maintained (excess duplicate data).   Further, they
wouldn't help do anything, as the AAAA records are still all going to be
there.   If there's a problem that A6 would be useful to solve, then what
will happen is that people will find some hack that allows it to be solved
using AAAA instead, as AAAA will be what exists.

If you want examples of this, look at Mobile IP - which has a whole
mechanism all created, with packet forwarding via home agents, and stuff,
all because there's simply no way to upgrade TCP stacks to allow the
identifier of a connection to be changed (not even with enough security
added to make the change secure).   Not even given that only major servers
really would need that upgrade (and mobile nodes of course, which need
upgraded code anyway).   Rather than upgrading TCP, we invent a hack to
work around the fact that TCP simply cannot be upgraded.

Or, look at IDN, which is doing obscene things to the DNS, to work around
the fact that it is impossible to upgrade all the old mailers (etc) to handle
arbitrary (non-ascii) domain names.   Rather than fix the problem where
it ought to be fixed, hacks are done in other places - because there is
simply no practical way to get the upgrade done that people are willing
to live with (me: I'd just break all the old mailers, etc, and tell people
to upgrade if they'll ever receive/send mail to a domain with a non-ascii
name, but most people aren't willing to do that).

  | 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.

No.  What I was highlighting is that if AAAA is nominated now as the
way that we go, then AAAA is it for eternity.  Pretending that we might
sometime later upgrade to A6 if it seemed to be a better idea is no
more than an attempt to handle people who think "A6 probably is better,
but it isn't deployed yet - let's go with what we have now so we can
make it happen, then we'll upgrade later".   Pretend that the upgrade
can happen, and selecting AAAA now doesn't seem so bad.

It cannot happen - net wide infrastructure upgrades are close to impossible
(for them to be even worth considering, the rationale has to be more
than compelling, there must be no other choice - for A6, or mobile IP,
or IDN, or anything else like that, there's always going to be some other
way than the right way).

  | 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:

If we were to make the change now, then yes, that's exactly what we should
be doing.   Now there isn't enough deployment to make it all that hard.
For the next 6 months or so (maybe even longer if IPv6 takeup remains
slow) we'll still have that option.   But not much further away.

  |    - the server could automatically generate all the corresponding AAAA records
  |      when loading its A6 database.

Yes.   I'd actually thought of making a hack to bind9 that would convert
all AAAA records into A6 0, and supplying only A6 whatever the admin
configured into the zone file...

  | 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.

We have a way to do it now, or soon.   There's no way that it can ever
be made to happen once we get wide deployment.  Expecting it is just fantasy.

eg: now the DNS has SRV records, they do so everything that MX can do,
and more.   In a way they're the analog of A6 and AAAA (MX is a subset of
SRV).   There would be benefits to converting SMTP to use SRV instead of
MX.   Can you imagine anyone seriously suggesting that that happen however?
Can you really imagine that there'd ever be a day when we could deprecate
the MX record?

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

Yes, sure.   Though it is also possible that AAAA synthesis would never
be a transition technique, but rather a permanent part of the way things
work (even if we decided that we wanted to move away from it, and there
probably wouldn't be much reason, there'd be no way to ever upgrade all
the clients, so back end resolvers would always need to provide it, so
new clients may as well just use the service that they know will be there...)

kre