Re: [RRG] loc/id split and HIP (was LISP)

[Pekka Nikander <pekka.nikander@nomadiclab.com>]

> > Hence, the [limitations w.r.t mobility] in the draft refers only  
> > to the case where you basically want to preserve existing Internet  
> > semantics, i.e., an IP address points to the host *currently*  
> > reachable at the location.  Then, if the host moves, those UDP  
> > applications that cache the address break today.  In this  
> > scenario, HIP doesn't change anything since we don't want to  
> > change the semantics.
> > If you willing to work with different semantics where the meaning  
> > of an IP address is changed somewhat, you can "fix" the situation  
> > and make also UDP applications to work, even when they do cache IP  
> > addresses.  That won't be simple and it will configuration would  
> > be ugly -- therefore we don't recommend it.  It would be better to  
> > use LSIs (which would have different semantics anyway) or,  
> > preferably, HITs.
> Pekka, I think you mis-understood what I meant originally. When I  
> said "ALL applications to be modified in order to support HIT", I  
> referred to those applications that use IP as identifier within  
> their implementations.
I don't think I misunderstood you.  When I wrote about legacy  
applications, I really meant legacy applications that use IPv4  
addresses directly in their data structures and configuration files.
I really mean that you *can* make HIP to work with such legacy  
applications, but you pay for it.  In practise you have to have some  
"local" configuration (not necessarily host-local, though) that  
statically binds such statically used legacy IPv4 addresses into  
HITs.  That changes the semantics that people generally expect about  
IPv4 addresses today; OTOH, such changed semantics would be closer to  
what people expected from IPv4 addresses before NATs, DHCP, and  
mobility.
--Pekka Nikander

PS.  All that I'm trying to do here is to correct some common  
misconceptions about HIP.  You are not alone thinking that HIP  
doesn't work with legacy IPv4 applications, while it does.
As I have written a few times, I don't think that HIP, as it is  
today, would be able to solve the routing table scalability problem.   
See my previous messages for what would be needed in order to HIP  
help there.

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