[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4 address depletion
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
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 firstname.lastname@example.org 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