[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