Re: Notes about identifier - locator separator

[Pekka Nikander <Pekka.Nikander@nomadiclab.com>]

> On Sat, 2 Nov 2002, Pekka Nikander wrote:
> > 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.
Iljitsch van Beijnum wrote:
> I don't understand.
Hmm.  I'm not quite sure what you don't understand.  :-)

Obviously, the text book explanation of IP is that IP
provides the packet forwarding service, and needs routing
in order to be able to forward packets.  But as we all
know, there is more in IP.

From my point of view, end-point naming is one of the most
important "services" IP provides today (in addition to
the packet forwarding "service", of course).  That is,
the TCP and UDP port numbers are qualified by the IP
address of the host currently hosting the application.
In order words, IP provides a name space for end-points,
and the application level entities (sockets) are named
by concatenating the IP address and the port number
(and in some other cases, like TCP MUX and ONC RPC, also
other information).

But this should all be trivial; I am unsure why we are
discussing this.

Well, maybe the reason lies in the fact that the
sublayering idea takes explicit advantage of that
the packet forwarding "service" and end-point naming
"service" need not be so tightly bound as they are today.

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

There are two issues here:  The "real" nature of the new identifiers,
and the representation of the new identifiers in application data
structures.  For application level backwards compatibility, we
obviously want the new identifiers to look (almost) like IP addresses.
If they do, they can be stored in existing data structures, and
we can provide binary compatibility to (almost) all existing
applications.  (The only exception are applications that explicitly
inspect the IP addresses to determine their properties.) No need
for string handling at all.

Thus, as long as application level backwards compatibility is an issue,
we want the interaction between the "upper" IP layer and the transport
layer to look like it looks like today.  The syntax would be (almost)
the same, just the semantics different.  The essence of the semantic
difference would be the hiding of the underlying changing IP addresses.
Today most programs today do not expect the IP addresses to change,
but they do expect the socket to remain connected to the same peer host.
Thus, in a way, the semantic change is not much of a change for most
of the applications.  Most applications are primarily interested on
the peer hosts anyway, not their IP addresses.

The real nature of the end-point identifiers is then a completely
different story.  Either they can be something that fits into
128 bits, or they can be something that does not.  If they do not,
the 128 bits stored in the application data structures would be
a "pointer" to the actual end-point identifier.  In the HIP
case the 128 bit representation is a hash of a public key, while
the actual end-point identifier is the public key.

> 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.
Well, there is certainly state at the IP layer.  The real question
is where and what kind of state.  For example, if you look at the
*BSD TCP/IP implementation, there is certainly state at the IP
layer.  It is represented in the form of routing table entries.
And part of this state is not related to routing at all, but is
essentially end-to-end information, such as PMTU and RTT estimates.

> > 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.
Well, it is hard to tell in detail how it would work, unless
we have some very concrete proposal at hand.  And if we go
into the details of a specific proposal, they will be lenghty.
As examples, both HIP and LIN6 have been documented fairly
well, I think.

Well, what does it solve then?  Apparently it helps to
separate the identifiers from locators, thereby solving
end-host mobility and multi-homing, and perhaps helping
with NEMO style mobile networks and site multi-homing.

> Leaving out source addresses means you can't protect yourself against
> DoS attacks.
Source addresses don't help much with DDoS attacks today.
I sincerely doubt they ever would.  I think that the idea
that ingress filtering would effectively cut down DDoS
is a fallacy.  But some others disagree with me, I know.

--Pekka Nikander