[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



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