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