Hi Scott, In "Re: [RRG] Evolutionary Possibilities - host MH/portability, IPv4 address depletion, you wrote:
> 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? I meant IPv6. >> 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. (See new thread "Authentication of authority to control mapping" concerning the questions you raise about problems with securely controlling mapping.) Is it true that with LISP in general, or at least with LISP-ALT, that you not anticipating the system to be used to control the mapping of individual IPv4 addresses or IPv6 /64s, but to be used for some larger number of these? If so, please give some examples of the lower limit of number of IPv4 addresses per EID prefix - the longer prefix limit - you think the system should be used for. For instance, do you think LISP should be used to provide EID IPv4 prefixes longer than /24? Or some other limit shorter than /32? If not, I would like to understand your reasoning. > 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. I think that unless you have host changes, session continuity depends entirely on persistence of the IP - address used by applications and seen by the correspondent hosts - as the device moves. Traditional approaches to Mobile IP involve fancy software at one or both ends, and usually a "home agent" router, with the likelihood of long path lengths unless the correspondent host has upgraded software too. Ivip's approach to mobility is different. The mobile device retains its IPv4 (or IPv6) address or prefix (with Ivip, actually any contiguous number of them, from any starting point) and the applications run via this address. The device gains one or more care-of addresses in the various networks it connects to, and sets up a two-way encrypted tunnel to a Translating Tunnel Router (TTR) which behaves like an ETR to the rest of the Ivip system, but can also get packets out to the Net. This is described further in: http://www.firstpr.com.au/ip/ivip/draft-whittle-ivip-db-fast-push-00.html#rfc.section.4.5 Since there is a lot you can do with a single IP address, I think the map-encap architecture should support and work efficiently with single IPv4 address EIDs/micronets. >> 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? I intend to do this, but the melting point depends on the technology of the day. By the time a billion micronets are needed, we will have cheaper CPUs, RAM, bandwidth etc. Can you write about how LISP-ALT or LISP-NERD could support mobility or not? Also, given the answer to that question, how many EIDs do you think - as an outside but not unrealistic estimate - a LISP scheme would ever have to support, say in 2015, 2020, 2030, 2040 and 2050? - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] 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
