Subject: Re: Notes about identifier - locator separator

From: "J. Noel Chiappa" <[email-masked]>
Date: Fri, 8 Nov 2002 11:59:40 -0500

> From: Erik Nordmark <[email-masked]>

    > 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

---

From: Frank Kastenholz <[email-masked]>
Date: Fri, 08 Nov 2002 13:31:09 -0500

>don't understand it can ignore it, at some loss in functionality/robustness.

The presence of IPv4 options in a packet header cause the IPv4
packet to be kicked out of the silicon-path of many of today's
high speed routers. Given that history, I could easily forsee
a silicon-forwarder for IPv6 that kicks packets to the slow
path if the next-header field is _not_ one of several known
values (on the theory that if the next header is not X, Y, or Z
then there _might_ be something in there that the router needs
to look at...). This has undesired effects on throughput.

Frank Kastenholz

---

From: Erik Nordmark <[email-masked]>
Date: Sun, 17 Nov 2002 22:44:59 +0100 (CET)

> 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