Re: Joint DNSEXT & NGTRANS agenda
Robert Elz <kre@munnari.OZ.AU> Tue, 31 July 2001 15:04 UTC
Received: from psg.com (exim@psg.com [147.28.0.62]) by ietf.org (8.9.1a/8.9.1a) with SMTP id LAA19960 for <dnsext-archive@lists.ietf.org>; Tue, 31 Jul 2001 11:04:43 -0400 (EDT)
Received: from lserv by psg.com with local (Exim 3.31 #1) id 15RajE-0007zv-00 for namedroppers-data@psg.com; Tue, 31 Jul 2001 07:42:36 -0700
Received: from rip.psg.com ([147.28.0.39] ident=exim) by psg.com with esmtp (Exim 3.31 #1) id 15RajD-0007zp-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:42:35 -0700
Received: from randy by rip.psg.com with local (Exim 3.31 #1) id 15RajD-000Keb-00 for namedroppers@ops.ietf.org; Tue, 31 Jul 2001 07:42:35 -0700
MIME-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7bit
From: Robert Elz <kre@munnari.OZ.AU>
To: Olafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com>, namedroppers@ops.ietf.org, ngtrans@sunroof.eng.sun.com, Alain Durand <Alain.Durand@sun.com>, ipng@sunroof.eng.sun.com
Subject: Re: Joint DNSEXT & NGTRANS agenda
In-Reply-To: <E15RICP-0008dx-00@psg.com>
References: <E15RICP-0008dx-00@psg.com>
Sender: owner-namedroppers@ops.ietf.org
Precedence: bulk
Message-Id: <E15RajE-0007zv-00@psg.com>
Date: Tue, 31 Jul 2001 07:42:36 -0700
Content-Transfer-Encoding: 7bit
Date: Mon, 30 Jul 2001 11:55:29 -0700 From: Olafur Gudmundsson/DNSEXT co-chair <ogud@ogud.com> Message-ID: <E15RICP-0008dx-00@psg.com> | 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 <itojun@iijlab.net>: | <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 to unsubscribe send a message to namedroppers-request@ops.ietf.org with the word 'unsubscribe' in a single line as the message text body.
- Joint DNSEXT & NGTRANS agenda Olafur Gudmundsson/DNSEXT co-chair
- Re: Joint DNSEXT & NGTRANS agenda Robert Elz