On 2/16/08 9:14 PM, Robin Whittle allegedly wrote: > (or I guess /64s for IPv4) This makes no sense. How many bits are there in an IPv4 address? > so I
think they are aiming their system to do "network" (many IP addresses and hosts per EID prefix) multihoming, not "host" multihoming.
There is an authentication problem with map-n-encap and wandering EIDs. Suppose a device visits a site and wishes to use an EID that is not in a prefix that that site normally announces, and the site agrees to announce it. Why should the mapping infrastructure, whatever it is, listen to the announcement of that new EID? You could have it trust whatever it's told, but more likely there will be filters in place to defend against bogus announcements, intentional or otherwise. Compare BGP route filters.
However, there is not really a need for this anyway. An EID names an interface -- a network attachment point. It is not a persistent name for a device. Session continuity (the real gist of the IP mobility problem you're trying to solve) does not and should not need continuity of IP "address" as you move.
So far, Ivip is the only map-encap proposal which explicitly aims to provide mobility - for networks or single IP addresses. To do this, a fast push system is needed - either to all ITRs in the world (pure push), or to some and to query servers which answer mapping queries for nearby caching ITRs (hybrid push-pull). I think there also needs to be a notification system by which the query server can send a message to an ITR about updated mapping for a micronet (EID prefix) which it queried recently and which has just had its mapping changed.
I just don't see this scaling. Can you put together a model of how you think it would work that we can put numbers into, to see when it melts?
-- to unsubscribe send a message to rrg-request@psg.com with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg