Re: question about draft-irtf-nsrg-report-09.txt

[Keith Moore <[e-mail]>]

> There has been a lot of discussion about the separation of identifiers
> and locators (in various forms) on the multi6, ipv6 and ietf lists.
> A lot of people seem to think this is in some form needed.
> 
> I would like to know the arguments against such a change.

nobody has worked out a complete solution.  if you want to separate
identifiers and locators you immediately need to build a reliable system to
map between the two - where reliable means: fast, up-to-date, highly
available, provides repeatable results across the entire network.  

for compatibility the identifiers need to be the same size as IP addresses,
yet distinct from them.   that way, apps just get identifiers rather than
addresses from DNS lookups.

ideally the mapping happens implicitly rather than explicitly - i.e. it
happens as a side effect of an app treating an identifier as a destination
rather than by having to send a query and wait for a response before
transmitting the packet.  also, you don't want to wait for the query to
complete before sending packets - triangle routing and subsequent redirects
are better.

a lot of people think DNS names can be the identifiers, but besides being the
wrong size, they're already too overloaded for that, plus DNS is too slow and
not reliable enough. part of the reason that DNS is slow and unreliable is
that it's too widely distributed.  that and there are a lot of tricks being
played with DNS that could get in the way.

there are a lot of good ideas in HIP but it doesn't address the
identifier-to-locator mapping problem.

the closest thing we have to a working solution today is mobile IP, but
purists tend to cringe when I say things like that in their presence.  for
stateful transport protocols we might be able to find a way to dispense with
tunneling and let (e.g.) TCP operate in terms of the identifiers rather than
the locators, even though the IP packets still contain the locators.

summary of problems that need to be solved:

1. security
2. fast, robust, highly available identifier-to-locator mapping layer
3. arranging for hosts (or perhaps routers) to find the mapping layer for
   a particular identifier
4. delegation and assignment of identifiers
5. making transport protocols work in terms of identifiers rather than
   locators while minimizing overhead

technically, I think it's doable.   whether we can actually agree
on a solution is a different question.

Keith