Re: Notes about identifier - locator separator

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

On Thu, 7 Nov 2002, Erik Nordmark wrote:

> >       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 that would be one for source, one for destination. (As
opposed to more than one for each.)

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

The idea is that an external box could handle this so a non-multihoming
aware host can enjoy being multihomed. And are you suggesting we should
carry all addresses in all packets? That would be a huge waste of
bandwidth. Not something IPv6 really needs as it is borderline in this
area as it is.

(There are also solutions where both the host and the border
routers/external boxes must be changed, though.)

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

That would be a necessary part of any solution that uses the "forward"
DNS functionality. You could also look up information for the remote
address that is seen in the incoming session, but that is a more
dangerous use of the DNS.

It is also possible to use some new way to map identifiers to locators
and not the DNS.

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

That means the routers have to solve the problem, as is done today. This
works very well but there are scalability issues. Have a look at:

1. http://www.ietf.org/internet-drafts/draft-van-beijnum-multi6-isp-int-aggr-00.txt
2. http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-mhap-01a.txt
3. http://www.ietf.org/internet-drafts/draft-py-multi6-gapi-00.txt

1. proposes a new aggregation mechanism that makes current multihoming
mechanisms a lot more scalable, but probably not enough. 2. is an
aliasing (address replacement) solution that has the necessary
scalability. They both use the address allocation plan 3., so it is
possible to make the transition from 1. to 2. relatively painlessly.
That way, there is more than enough time for current border routers to
implement the new mechanisms.