| However, to come up with an architecture which has separate concepts of
| identity and location, there can't be any direct relationship between them
| at all (other than mapping through some kind of database).
Well, it's sufficient to have the identity not be dependent upon the
location. The location may be dependent on the identity without
much pain. For example, all 128 bits of an IPv6 address field could
be considered the locator, but only about half of those form the
identity. So the host only considers those identity bits when
(for example) encoding its address on the wire or demultiplexing
packets for itself (performing checksums etc.).
The one-way dependency makes a few things easier. For example, if
a host or an agent in the middle has a scheme for generating/looking-up
some or all of a locator based on the host's identity bits.
It is, however, probably a bit cleaner and more flexible if we have
full independence, such that "inside" & "outside" location labels
can vary only on the basis of where the traffic is sourced/sunk
in the network, rather than what host is doing the talking or listening.
Either way you are stuck with a flavour of registering your
identity at a particular location.
| Mobile IP neither is, nor pretends to be, any kind of demonstration of
| a model with separate ID and location spaces.
If something sending to the mobile node thinks it's talking to
"mobile node registered at home node", but will also talk with
"mobile node registered at secondary home node" without much
fuss, you have a separation of identity ("mobile node") from
location ("home node" or "secondary home node").
If the receiving "mobile node" chooses to accept packets
for "mobile node" independent of whether it is registered
at "home node" or "secondary home node", you have an analogue
to an 8+8 scheme where only the lower 8 identity bytes are
used in checksumming/demultiplexing by the receiver. The top
8 bytes likewise are an analogue to "home node" or "secondary
home node".
Sean.