(ngtrans) Re: Joint DNSEXT & NGTRANS agenda

[Robert Elz <[e-mail]>]

    Date:        Mon, 30 Jul 2001 11:55:29 -0700
    From:        Olafur Gudmundsson/DNSEXT co-chair <[e-mail]>
    Message-ID:  <[e-mail]>

  | 	51 IETF DNSEXT NGTRANS Joint Meeting on
  | 	IPv6 Addresses in DNS
  | 
  | 	Monday 2001/Aug/6   15:30-17:30
  | 	Room: King's Suite/Balmoral 2

I'm not going to be there, and thus didn't write a draft to speak about
at the meeting (which the earlier request seemed to be about).

I will make some comments about the 5 drafts (well, 4 drafts and a web
page) that are to be considered though.

Before I begin, I'd like to point out again that this issue really has
nothing whatever to do with ngtrans - it should be being considered in
the ipngwg rather than ngtrans.  This issue has nothing specifically to
do with transition arrangements (other than that a solution is needed
so the transition can happen - but that is or was true of everything else
related to IPv6 - the basic protocol doc might just as well have been
done in ngtrans if that was the criteria).

ngtrans should be concerning itself with those short term issues needed
to allow the v4 internet to turn itself into the v6 internet.   The result
when that has finished should be what has been defined by the ipngwg,
all the ngtrans issues should eventually simply vanish (eventually may
be a long time away, that's OK).

Nor is this really a dnsext issue - when the RR types were being defined
that made sense, but it doesn't really any more.   The question is just
which RR type (which exists in the DNS definitions already) IPv6 should
actually be using (not for the transition period, but forever).

Once that decision is made, if ngtrans wants to map a path to get from
where we are now, to the eventual end point, that's fine.   But it really
is a bit hard for ngtrans to plan a transition when the end point isn't
yet fixed.

  | 1 Rob Austein:
  |   <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-ipv6-dns-tradeoffs-00.txt>

This is an excellent analysis of the issues.   (It also makes the point
that this is really an ipv6 issue - ipngwg that is).

About the only issue I have with it is the assumption that whether to
use AAAA or A6 should be decided merely by the relative frequency of
renumberings expected for IPv6 systems.

One reason for not simply going that way, is that it is an issue upon
which no-one really agrees.   There are hopes, expectations, and
dooms day scenarios, which all produce different expectations.

Personally I have no idea how frequently IPv6 nets will renumber.  What
I am sure of however, is that I want to do everything possible to allow
for renumberings to happen with the greatest possible ease, with the
smallest possible notice, and the greatest possible frequency.   Planning
that way maximises the chances that we will actually end up with something
which will work in the environment that develops - whether that means
permanent addresses, and no renumbering at all for anything (ie: we manage
to make the routing system deal with routing to arbitrary /128's), or
if we end up in a state where major sites are expected to renumber
four times a day as traffic patterns shift going to and from the work
user and home user peak periods.

  | 2 Christian Huitema:
  |   <http://www.ietf.org/internet-drafts/draft-huitema-ipv6-renumber-00.txt>

This is just a summary of what's involved in renumbering in some
interesting cases.  The draft is fine, but I'm not sure it adds a
whole lot to the A6 vs AAAA debate.

  | 3 Matt Crawford:
  |   <http://home.fnal.gov/~crawdad/draft-ietf-dnsext-ipv6-dns-response-00.txt>

I have nothing much to say about this one, other than that I essentially
agree with all of it.

  | 4 Jun-ichiro itojun Hagino <[e-mail]>:
  |   <http://www.ietf.org/internet-drafts/draft-ietf-dnsext-aaaa-a6-01.txt>

This one contains a bunch of info on the current state of the world,
followed by a large amount of FUD.   There's essentially nothing in it
of value to the discussion.  I could analyse this doc paragraph by
paragraph, and was once planning to do so - but I think that would be
a waste of everyone's time.

  | 5 Dan Bernstein:
  |   <http://cr.yp.to/djbdns/killa6.html>

And this one points out that with A6 it will be possible for sites to
create ludicrous setups that won't work.   Without A6 sites can create
ludicrous setups that won't work, so there is nothing really new here.
Just one extra way to shoot yourself in the foot.  Big deal.


What is missing in all of this is any real data upon which anyone could
really base a decision.   There's no comparisons of how many queries
it will take to resolve names in various common cases, what the cache
effectiveness can be expected to be, how much cache churn renumbering
will cause, how big the DNS packets for various scenarios will actually
be - nothing like this at all.

The effect of that is that any decision on which way to go cannot be
based upon any more than either guesswork or fear.

I had hoped to have collected some data on all of this by now, but for
various reasons it hasn't happened yet (even if it had, there wouldn't
have been very much yet, so it probably still would have been premature
to use it for much).

I am still planning to (ie: actually doing the setup for now) collect
some data, initially on A6 vs AAAA - that is, so see whether any extra
round trips that are needed actually make a difference to name resolution
for rationally configured setups (I'll also look at some irrational
configurations of course).

kre