Re: (ngtrans) Joint DNSEXT & NGTRANS summary

[Keith Moore <moore@cs.utk.edu>]

>     Date:        Wed, 08 Aug 2001 14:54:32 -0400
>     From:        Keith Moore <moore@cs.utk.edu>
>     Message-ID:  <200108081854.OAA15722@astro.cs.utk.edu>
> 
>   | why?  nothing in the standards requires that all IP addresses be listed,
> 
> Again, it depends upon exactly what you're measuring here.   The DNS
> defines the name, and if it has A (or AAAA or A6) RR's, then those define
> the addresses that belong to that name.
> 
> That someone might know of some other address that happens to reach
> the same piece of hardware isn't really relevant - even if the other
> address happens to work just as well.

it's relevant to renumbering, because renumbering affects whether those 
addresses continue to work well - independently of what the DNS says.  

>   | 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)
> 
> Perhaps.   When that happens then we'll have two ways to define the
> mapping between names and addresses

not necessarily.  the input to such a service doesn't have to be service 
names (they could for instance be queries for resources matching several 
criteria).  even if the input were service names, those names don't have 
to be from the same space as DNS names.

there are already several applications that work this way, because DNS
doesn't suit their needs.

>   | 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.
> 
> Yes, at the TCP level, things are easy (well, could be, assuming
> adequate protocol support, and "easy" is probably the wrong term
> even then, "possible" would be better).

Right, I'm just generalizing this to "any thing for which the host's 
OS maintains per-connection state".  So (for example) it would also 
be true of UDP sockets for which a remote address were bound to the 
socket. 

> If the client just validates the name it was given whenever its address
> has expired, then it can pick up on address changes, and use the new
> address (the server doesn't care what address requests come to).

as explained earlier, this doesn't work in general.  you're overloading
the DNS name to do something it wasn't designed to do.

> Each protocol really needs to be investigated separately, what might
> work, and what mightn't will vary enormously.   Which is another reason
> why attempting to fix it at the IP layer probably isn't the solution.

no, you can't fix everything at the IP layer. but the notifications that
address prefixes are being changed (or that old ones are invalid) should 
originate with the network, not with DNS.
 
>   | similarly, if those hosts can notify resident applications that the 
>   | addresses prefixes have changed, those applications can at least 
>   | potentially notify their peers.
> 
> Only if the end that is renumbering has any idea who its peers are.
> That isn't always the case.

no, but at least this will provide a mechanisms by which applications
can be aware of their peers.  existing non-connection-based applications 
won't be able to survive renumbering, no matter what fix we come up with.

>   | this doesn't solve the problem entirely, since more than one host 
>   | in a conversation could be concurrently changing addresses.
> 
> yes, that part is the real hard one to handle - but if we can't get it
> right without that case, worrying about that one is a waste of energy.

true enough.  the question is whether a solution that fails to address
that case is adequate.  (or, are we also wasting our energy if we fail 
to address that case?)

>   | 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.
> 
> Yes.   Unfortunately, the very disagreement that you mention means that
> deciding what those bounds should be isn't going to be easy.

Still, I think we'd be better off if we started trying to get consensus on
a figure, than by trying to make progress without a shared understanding
of the problem.

We've made recommendations on other design parameters, like prefix length.
 
> Personally, I'm also not sure I need to know - I want to make it possible
> to renumber easily, which should make it possible to do frequently if needed,
> and then hope I almost never have to actually do it...
> 
> That is, I want to be able to deal with the worst case, but will hope that
> the best case is what occurs.   

Right.  But I want to know what the worst reasonable case is so that I can
design my applications to deal with it.  

>   | 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%,
> 
> Hmm... if it gets to double figures I give up for the day...

I wish the network to my home worked that well.

> But I don't think we've ever had such a definition, what packet loss
> is tolerable also depends heavily upon the applications.

Right.  But at some point you stop expecting anything to work.

>   | address bindings should be good for at least several days.
> 
> Would be a nice target.  Just as long as we don't actually assume that
> we will be able to meet it.

Again, I think we need to be able to make *some* assumptions.
Just as TCP doesn't survive arbitrary amounts of packet lossage, neither
do applications survive arbitrary amounts of renumbering.