Re: Notes about identifier - locator separator

[Erik Nordmark <Erik.Nordmark@sun.com>]

Useful writeup. Some comments.

> 2. Translations
> 
>     Once the end-point identifiers have been separated from
>     locators, we need to translate the identifiers to locators
>     at some point, and it also becomes possible to translate
>     between locators.  That is, the apps will only know the
>     identifiers, not locators.  Thus, at some point, the
>     identifiers must be translated into locators so that the
>     packets can be routed to their destination.
> 
>     Here I see two basic solutions, again:
> 
>       a) perform the identifier -> locator translation at
>          the end-host so that all packets leaving the end-host
>          have a proper locator,

Is the singular "a proper locator" intentional or a mistake?
I think each packet need both a source locator and a destination locator
in order to enable ICMP errors and e.g. TCP SYN+ACK messages to be returned
without anybody having to perform a mapping - since doing such a mapping
in response to a single packet would be a field day for DoS attacks.

>       b) allow the identifiers to leave the end-host without
>          locators, and perform the translation within the
>          the network, e.g., at a site border router.

But on a larger issue, 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.
It would be useful to understand the different impact on the applications
for such a case. For instance, if porting applications to IPv6 means that
they use getaddrinfo hence can handle variable length "address" structures
without any additional changes...

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.

> 3. Resolution
> 
>     Apparently there must also be some way of finding the
>     locators based on the identifier or a name.  Apparently
>     there is a huge number of possible solutions to this.
>     One of the most obvious ones is to store both identifiers
>     and locators into the DNS, and make the name resolution
>     library to fetch both.

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.

>     a) application level backwards compatibility

In addition to the constraint you list, presumaby we do not want to require 
that multi-party applications change significantly. Thus an application should
be able to take the address it got from getaddrinfo(), the local pr 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.

> Those are the dimensions as I see them.  There are
> probably others. 

One additional issue on my list is to what extent one can ease deployment of
a new scheme by being able to derive some benefits when e.g. the local host
and the local border routers implement the new stuff, but the peer host
and peer border routers do not.

   Erik