Re: Thinking differently about the site local problem (was: RE: site local addresses (was Re: Fw: Welcome to the InterNAT...))

[Keith Moore <[e-mail]>]

>     > actually it's bad to force all apps to use DNS names - which are
>     > often less reliable, slower, less correct, and more ambiguous
>     > than IP addresses.
> 
> This is like saying it's bad to force people to use
> cars/busses/whatever because they occasionally break, and everyone
> should walk everytime they need to go anywhere, because that's more
> reliable.

Nope.  Forcing apps to use DNS names is like telling people that they
must always give taxi drivers the names of the places where they want
to go, rather than the addresses of those places, and that those people
shouldn't mind when the taxi drivers take them to the wrong places, or
run up fares and delays looking for those places.

> We have multiple namespaces, each with different characteristics for
> the names, for very good reasons. If we really need a name with
> characteristic A, and we instead wind up using one with characteristic
> ~A "because it's more reliable", then that's not good.

Indeed, but let's look at this more closely.  We essentially have two
name spaces of concern here: DNS and IP.  DNS is slow, imprecise, not
terribly reliable, not always available, not always in sync with
reality. IP is fast, precise, reliable, but tied to location, which is
often the wrong thing in theory and occasionally the wrong thing in
practice. I suspect we agree that neither one is well-adapted for naming
connection endpoints, and that in an ideal world there would be a
separate namespace for this that provided fast, precise, reliable,
secure indirection that was not tied to location(assuming, of course,
that the cost of maintaining a separate name space and the extra mapping
layers would be justified by the additional utility - something that has
not been demonstrated).  But Tony's argument is that we should *always*
use DNS instead of IP even when IP works better for our purposes -
merely in order to preserve a dubious feature of IPv6.

> If we have a need for a name, and the optimal characteristics for that
> name are those of an address (i.e. the topological location of an
> interface to the network), then fine, use an address. If not, don't.
>
> If the system for mapping from one namespace to another has problems,
> we ought to fix it, not say "oh, we'll just stop using it".
>
> Don't try and make everything into a nail because the hammer is the
> most reliable tool you have.

That applies equally to DNS and IP.  Just because IP is not ideal for
some purpose does not mean that DNS is the right tool for the job, or
that it's appropriate or even feasible to "fix" it for that job. 
And based on consideration of various factors, I'm firmly convinced that
endpoint identifers should look like IP addresses instead of DNS names.