Subject: Re: (ngtrans) Joint DNSEXT & NGTRANS summary

From: Alain Durand <[email-masked]>
Date: Tue, 14 Aug 2001 22:55:37 -0700

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.

to unsubscribe send a message to [email-masked] with
the word 'unsubscribe' in a single line as the message text body.

---

From: Robert Elz <[email-masked]>
Date: Wed, 15 Aug 2001 17:00:43 +0700

Date:        Tue, 14 Aug 2001 22:55:37 -0700
    From:        Alain Durand <[email-masked]>
    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

---

From: David Terrell <[email-masked]>
Date: Wed, 15 Aug 2001 03:21:35 -0700

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

There's no reason why it can't be a gradual upgrade.  Authoritative
servers for zones with A6 can do AAAA synthesis at query time just
as easily as the local non-stub resolver can.  It becomes a server-side
indirection mechanism, which is available to A6-grokking caches.

Considering that like it or not A) BIND is still a majority of
nameservers, B) bind9 is the first version to support v6 transport
and C) I don't imagine Nominum/ISC/"The BIND Company" removing A6
support just because it's not "the thing", this feature is basically
already present today.  ISPs can provide A6 prefix records for their
customers, those customers can use A6 chains to point to their ISPs
and do authoritative server-side AAAA synthesis (well, ok, bind
needs to add this I guess), and most people can go on using AAAA
and be happy.

I'm squarely in the "Let's take AAAA because it works and let's get
IPv6 off the ground" camp.

-- 
David Terrell   | p = "you are nasty"          q = "my first name is Janet"
Nebcorp PM      | r = "my first name is baby"  s = "My name is Miss Jackson"
[email-masked]    | (!r -> q) & (p -> s)        - Braverman's Third Lemma
wwn.nebcorp.com | !r & (!p -> q) & (p -> s)   - Libor's Corollary

---

From: Johan Ihren <[email-masked]>
Date: 15 Aug 2001 12:30:37 +0200

> indirection mechanism, which is available to A6-grokking caches.

This is *wrong*.

An authoritative, non-recursive server with only A6 fragments around
can not synthesise the AAAA since that would require it to query for
missing fragments.

Johan Ihren

---

From: Nathan Jones <[email-masked]>
Date: Thu, 16 Aug 2001 02:04:35 +1000

>can not synthesise the AAAA since that would require it to query for

True, but it could still be an option for DNS administrators happy
to run a recursive nameserver.

Also, I haven't thought this through fully, but is there any reason
a nameserver couldn't have an option to use recursion for AAAA
synthesis, but still deny to recurse when answering client queries?

--
nathanj

---

From: Alain Durand <[email-masked]>
Date: Wed, 15 Aug 2001 10:10:28 -0700

>can not synthesise the AAAA since that would require it to query for

Those fragments could be provided (or queried) when the server is started.

         - Alain.