Re: Notes about identifier - locator separator

["J. Noel Chiappa" <jnc@ginger.lcs.mit.edu>]

    > From: Erik Nordmark <Erik.Nordmark@sun.com>

    > it isn't clear to me that a translation is necessary (except for
    > debugging) if one would always carry around blobs that consist of the
    > indentifier plus a set of (possibly stale or not working) locators.

Yes, that's always been my take too.

The way things work now, you basically always either i) get addresses (and
here I mean the kind names we currently have, which provide both entity
identification as well as location) from a translation process (DNS), or ii)
in the case of mobile things (at least in IPv6), you start off with an
address for them which you obtain as above, and then either the thing itself,
or an agent, tells you what the current address is.

So if we say that you don't need to be able to translate from endpoint
identifiers to locators, we're basically in the same situation we are now -
but we are better off to the extent that we have separated out location and
identity, and we can now start to play games, e.g. with having N locators for
something (which you got e.g. in the initial lookup) and using them
interchangably, while keeping e.g. the TCP layer oblivious that we are doing
so.

    > If the translation needs to be present in the performance and DoS
    > critical path I think it would be quite critical to understand how such
    > a translation function can be constructed.

Yes, but if we do decide we need it, let's not get too crazed over extra
packet exchanges; loading a single web page these days (on a site with
advertising) seems to take a zillion packets anyway...


    > That doesn't work e.g. for the passive side of a TCP conenction where
    > the transport protocol, and often not even the application, do a DNS
    > lookup. Unless you carry a source identifier plus a list of source
    > locators in e.g. the TCP SYN packet.

Yes, exactly. If you implement it as an IP option (I first thought of a TCP
option, but then every transport would have to define the same functionality,
and some e.g. UDP can't), then it has the added benefit that hosts which
don't understand it can ignore it, at some loss in functionality/robustness.


    > Thus an application should be able to take the address it got from
    > getaddrinfo(), the local [or] remote address of some existing connection
    > (getsockname() and getpeername() type stuff) and pass that address to
    > another peer in the multi-party application. Thus if you only expose
    > the identifier to the application in these calls, then you must be able to
    > perform the identifier->locator mapping in other hosts that have not
    > done a DNS lookup of the hostname. 

Excellent point, and I don't see any easy way around it, other than really
gross kludges - e.g. have the OS notice whenever any application either sends
a packet to, or gets a packet from, a host it hasn't previously communicated
with, and when that happens, send the identifier/locator list for such hosts
to all other hosts that application is communicating with.

I think we'd just have to suffer for a while with applications, protocols,
etc which have the old view of the world. There's no way to make everthing
work perfectly on day one...

But it would be good for someone to start compiling a list of gotcha's (like
this one), along with potential fixes.

	Noel