To:
Keith Moore <moore@cs.utk.edu>
cc:
ngtrans@sunroof.eng.sun.com, namedroppers@ops.ietf.org, ipng@sunroof.eng.sun.com, dnsop@cafax.se
From:
Robert Elz <kre@munnari.OZ.AU>
Date:
Thu, 09 Aug 2001 00:56:50 +0700
In-Reply-To:
<200108081709.NAA14777@astro.cs.utk.edu>
Sender:
owner-dnsop@cafax.se
Subject:
Re: (ngtrans) Joint DNSEXT & NGTRANS summary
Date: Wed, 08 Aug 2001 13:09:38 -0400 From: Keith Moore <moore@cs.utk.edu> Message-ID: <200108081709.NAA14777@astro.cs.utk.edu> | DNS cannot tell you that old addresses are no longer valid, it can only | tell you that some addresses should be valid. The absence of some address | in a list of A (or AAAA or A6) records is not an indication that the | address is not valid. I'm not sure I agree with that. The RRset should be the complete list of addresses that belong to a name (which isn't necessarily the complete set that belong to the node that owns the name of course). If an address isn't in the RRset, then it doesn't belong to the name, by definition, and hence, is invalid as a translation of the name. Whether that address still happens to reach the entity that it reached yesterday, when it was a valid translation of the name is a different question. | any system for renumbering (including the one you are proposing) | will require changes to existing protocols. the question is, | where is the best place to make these changes? my guess is, | some combination of ND/RD and ICMP. I'm not sure it is possible. Sure, a node could respond with some kind of message to a peer that sends a packet to an address that the node is in the process of deprecating - but that doesn't help at all for all the other peers that don't happen to send any traffic during the deprecation period. | which apps are affected depends on the frequency of renumbering and the | overlap during which multiple addresses are valid. The overlap period, yes, the frequency, no, not really. I can renumber 7 times in a day, and as long as the first (and rest) of those addresses remain valid long enough, then all is OK. | we really need for these to be explicitly chosen design parameters. That means then the overlap period. Unfortunately, I suspect that's not possible. | my feeling is that the mean time between renumbering should be no worse | than the mean time between shutdown of reasonable hosts for other reasons, | which is to say, several months. that way, renumbering doesn't | significantly affect application reliability. And unfortunately you're trying to equate two measures that are likely moving in opposite directions. Hosts (and OS's) are becoming more stable, and remaining running between shutdowns far longer than used to be possible (I recall the days when computers were turned off each night when people went home...) And renumbering is likely to become more necessary, hence more frequent, as the net gets bigger, and the routing problems get worse (assuming no revolutionary solution of course). But in any case, it isn't host uptime that counts, but application connection time - what you would like is for addresses to remain valid (after ceasing to be preferred) for at least as long as the average app connection is likely to remain. It would be nice to aim for that where possible, but circumstances being what they are, mandating it would just make us look foolish. kre