Re: Notes about identifier - locator separator

[Erik Nordmark <Erik.Nordmark@sun.com>]

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

Agreed.
But at the highest level I think there are different approaches to where
pain is allocated in the design; where pain means what function and/or nodes
need to be modifed to support multihomong (applications, transport protocols,
IP stack in hosts, routers in general, border routers, DNS?).

It is far from clear that there is a single pain allocation that is best across
the board. Instead ,I can envision a few design alternatives with different
allocations. But it would seem unwise to assume that any scheme would cause
changes in all of the functions/nodes. Thus looking at for instance a scheme
which changes border routers, such as 8+8/GSE, but not applications might make
sense, and also look at a scheme which doesn't touch routers but requires
changes to applications (in order for them to work optimally  in the face of
multihoming).

   Erik