Re: Notes about identifier - locator separator

[Iljitsch van Beijnum <iljitsch@muada.com>]

On Sat, 2 Nov 2002, Pekka Nikander wrote:

> > As it seems to be open season on all aspects of the TCP/IP architecture,
> > let's follow this reasoning to its logical conclusion and make the
> > identifier the full host name.

> I like this approach, but I don't agree with your conclusions.
> Let's see why.

Ok...

> > Let's go with this for a moment. Now obviously IP will be unable to
> > route based on hostnames, so the whole thing must be done at the
> > transport layer.

> Already here you make a statement that I don't sign.  As of today,
> IP has also other functions but routing.  Routing is the main
> function of IP from the router point of view, true.  But from a
> host or application point of view, IP *also* provides a name space
> for end-points.

I don't understand.

> If you separate locators completely from end-point identifiers,
> the logical conclusion is NOT to move the function to the
> transport layer but to split the IP layer into two halves:

> -  A "lower" IP that routers packets much as today, and uses
>     IP addresses as locators.

> -  An "upper" IP that provides end-point identifiers to the
>     transport protocols and eventually to the hosted applications,
>     and maps these identifiers to locators before passing them
>     to the "lower" IP.

Ok, that makes some sense. I believe the IEEE slices a single OSI layer
at least three ways so two is modest.

However, what will the interaction with the upper layer be like? Either
this has to be done using the new identifiers, which isn't good. I'm not
completely sure how much of the inefficiencies of string handling (as
compared to working with a fixed length machine word size aligned value)
modern processors can optimize away, but I doubt it's the entire thing.
This would get pretty bad in machines with very many sessions.
Alternatively, there must be some kind of state. That's contrary to the
IP (as in IP layer, not TCP/IP as a whole) philosophy.

> > Retrofitting TCP is probably not worth it, so we make a
> > new transport protocol. As I've said before, doing multihoming at the
> > transport layer has many drawbacks compatibility-wise, but if we're
> > going to do some major architectural work, we may as well go the full
> > nine yards and solve everything once and for all.

> If we take the position that multi-homing needs to be implemented
> at the transport layer, I by and large agree with you.

A reason to not want this is that it requires big changes to existing
code. But many of the things we've been discussing lately do this
anyway. Apart from that my main gripe with doing it at the transport
layer is that we can't offload the processing to a box external to the
end host. On the other hand the big plus is that the tranport layer
knows when to switch locators.

> And we already have SCTP.

I'm not fully familiar with SCTP, but it's never intended to fully solve
the multihoming problem, and I'm not convinced it is as advanced as TCP
with regard to congestion issues. (Although I believe we can improve on
TCP in that regard, but at least its track record is proven and
well-known.)

> One possible way that I see is to implement
> compatibility "shims" so that you can run legacy TCP and UDP
> applications over SCTP.  (I think Brian mentioned this a while
> back.)

You mean intercept the old APIs and translate them to new stuff. I guess
this could work. Still, IPv6 deployment isn't that huge so if we can
make something that is really very good, people will want it and we
shouldn't have to deal with much legacy stuff.

About UDP: this is intended to be a light weight protocol. Running it on
top of a heavy weight protocol defeats the purpose. Also, you'll get
into trouble if you end up doing name server request over the multihomed
transport as this new transport needs to go to the DNS itself.

> However, based on my limited understanding, I think that splitting
> IP into two sub-layers would *probably* be better.

Tell us more about how this works and what it solves.

> > A good way to do traffic engineering if the hosts are in charge of the
> > identifier->locator substitution would be a way to add preference
> > information to each locator. To be crude: the DNS looks in the BGP
> > table to see which locators are better connected and includes this
> > information in the replies.

> Would you please clarify?  I didn't quite understand.

You open a connection to blah.com. The new transport protocol looks up
the locators associated with blah.com. Suppose they are abc::1 and
def::1. Today, the DNS/resolver library either presents the addresses to
the application in the order they were received or orders them
semi-randomly (round robin) to achieve some load balancing. The DNS
and/or resolver could look in the routing tables and sort the addresses
according to their routing metric (suppose abc::/32 is 3 AS hops away
and def::/32 1 AS hop, def::1 would be first and abc::1 second) but it
would be better to list an explicit preference value (for instance,
abc::1 pref = 33, def::1 pref = 100).

> > BTW, in order to do this right (traffic engineering incoming traffic) we
> > also need to make the host ask for advice on which source address it
> > should use.

> Well, if you separate identifiers from locators, the semantics of
> the source address also change, at least potentially.  We wrote
> a tongue-in-the-cheek paper about that to a local security conference
> (Nordsec) last year.  It was titled "IPv6 source addresses considered
> harmful."  For a couple of chuckles, see

> http://www.tml.hut.fi/~pnr/publications/nordsec2001.pdf

I didn't read the whole thing but it seemed at least somewhat serious...
Leaving out source addresses means you can't protect yourself against
DoS attacks.

Iljitsch