Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Keith Moore <moore@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).

why?  nothing in the standards requires that all IP addresses be listed,
and most applications are quite capable of using IP addresses as names
for services.  there's also no reason that you couldn't use a completely
different mechanism than DNS to determine the IP address associated with
a service.  (we will certainly need to do this someday, as DNS cannot 
last forever)

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

perhaps, but it might still be a valid address for the service that
the user wants.

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

if hosts are notified when their address prefixes change, that notification 
can be forwarded to any connections (TCP or otherwise) that the host knows 
about.  similarly, if those hosts can notify resident applications that the 
addresses prefixes have changed, those applications can at least potentially
notify their peers.

this doesn't solve the problem entirely, since more than one host 
in a conversation could be concurrently changing addresses.  but since
only the hosts and applications know who their communications peers are,
that's where you have to start.

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

probably so.  but there is also probably a practical limit to the number 
of address prefixes that should be used at any one time.

>   | we really need for these to be explicitly chosen design parameters.
> 
> That means then the overlap period.
> 
> Unfortunately, I suspect that's not possible.

well, we appear to have some people assuming that renumberings will be
so infrequent that we can disregard them, and others assuming that 
renumberings will be so frequent that protocols have to deal with them
explicitly.  that's no way to do engineering.  for applications to
make use of IPv6 there needs to be some reasonable bounds on tbe 
behavior of the network.

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

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

I don't think that's the right criterion - first of all, that would have 
50% of all connections being broken; second, it's based on assumptions
about the nature of traffic, which will vary widely over time. 

I'd rather say that we have expectations about how the network behaves -
just as (say) end-to-end packet loss should be no worse than 20%, 
address bindings should be good for at least several days.

Keith