[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Notes about identifier - locator separator

On Sat, 2 Nov 2002, Pekka Nikander wrote:

1. Architectural "structure" of the identifiers

   From my point of view, there are two different basic
   approaches:

     a) make the end-point identifiers a completely
        separate name space

     b) divide the IPv6 address space into locator
        and identifier space

Iljitsch van Beijnum 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.
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.

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.

Or that's at least I see HIP.  :-)   If you want to, you can
give the "upper" IP some other name, like "Host Layer" or
"Common Lower Transport Layer" or whatever.  The point is that
it is completely underneath current transport protocols.
(And optional, as I discuss below.)


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.  And we
already have SCTP.  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.)

However, based on my limited understanding, I think that splitting
IP into two sub-layers would *probably* be better.  The reasons
are related to security, signalling overhead, and architectural
"beaty".  I definitely don't mean that a solution based on SCTP
would not work or be viable.  I just want to say that I do find
the idea of separate end-point identifiers and a separate layer
for them better.


Since the identifiers aren't carried in IP and we need extra locators,
there must be some serious session establishment.

Agreed.  There are also security issues involved, requiring
session establishment.  However, some of these security issues
would be present even if the locators and identifiers are
separated "within" the IP address space á la 8+8.


Doing this in UDP
defeats the purpose. So apps that use straight UDP must either live with
the fact that they are not multihomed (which may be ok for something
like syslog) or implement their own multihoming mechanisms (such as the
DNS already does).

If we split the IP layer into two sub-layers, I think that it should
still be possible to use TCP/UDP either with the additional
services provided by the "end-host identifier" layer or without it.
When used without, the "new" services like multi-homing would not
be available.  However, this would be perfectly fine for short term
request-response services.

Architectural flexibility seems like a key issue here.

[Some comments clipped since I didnt' find them relevant,
 even though they certainly were amusing :-) ]


  - identifiers are translated into locators
    at the end-hosts, and the network performs
    locator-locator translations if needed
    e.g. for traffic engineering,

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.


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

BTW, my co-auther presented it and according to her most of the
audience didn't get it while a couple had difficulties in keeping
on their chairs and not rolling on the ground.  :-) :-)

--Pekka