Re: Notes about identifier - locator separator

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

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

>     Due to the chartering of this working group, I think it is
>     natural that people here tend to look at solutions from the
>     b) category.  However, I personally think that a completely
>     separate name space might be better.  Furthermore, if we
>     create a completely new name space, that would leave
>     the IP address space more or less intact, allowing routing
>     technogy to be developed independently of end-host mobility
>     and end-host multi-homing issues.

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.

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

Since the identifiers aren't carried in IP and we need extra locators,
there must be some serious session establishment. 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). However, many applications don't use UDP as-is but
use a UDP-based real-time transport protocol. As long as we're building
a new transport protocol, we may as well address this need too and
implement an unreliable and possibly as semi-reliable (for multicast?)
mode in addition to the regular TCP-like reliable mode.

A nice addition would be having a better checksum for the new protocol.
If we replace the TCP checksum by an MD5 hash or part thereof that is
calculated over the packet contents, assorted transport layer fields
such as the sequence number, the identifier and some kind of magic
cookie, it becomes pretty hard for someone to steal a session without
having seen the intial identifier/cookie exchange. Obviously more
extensive mechanisms can be negotiated as well if desired.

Since we now have all the functionality we'll ever need in our new
transportzilla protocol, there is no need to change IP or routing.

Also, the network layer is now completely hidden from the application.
So moving from IPv4 to IPv6 to IPv6 multihomed to IPv7 and IPv9
(skipping IPv8) will be a breeze.

Most application builders will love this since they can finally stop
worrying about resolving domain names in their applications. (Although
the fact that they have to change their apps in itself may not be
greeted with much enthusiasm for those who already did the v6 work, but
most are still v4-only anyway.)

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

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.

Iljitsch