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

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



For example, HIP, it requests ALL end devices change their stacks, ALL applications to be modified in order to support HIT, and to deploy a global mapping real-time system in order to translate the identifier (HIT) into locator (IP).

Well, that is not quite true. While that all may be *eventually* required to reap all the potential benefits of HIP, in the short term much less is needed. For example, in order to deploy HIP in a small scale, all that is needed is to *some* end devices to change their stacks. There is no need to modify applications [1]. For stationary hosts, the mapping of HIT to locators can be stationary, requiring no new infrastructure. Additionally, the HIP-enabled hosts can continue to communicate with non-HIP-enabled hosts as if HIP wasn't there at all.

You are partly right here. Yes, for stationary host, no modification is needed. But for me, the most important benefit of HIP is the support for mobility and multihoming. As [1] mentioned, "mobility will break in the connectionless case when an application caches the IP address and repeatedly calls sendto()."

I think you have to think more carefully about the context of that statement; the draft states only what is most obvious. For example, if you use a local policy to *statically* map some IP addresses to host identities, then the system will work even for UDP applications in mobility scenarios. But you cannot do that in the general case, since in the general case you have no pre-existing knowledge if the host *currently* at an IP address is able to speak HIP or not.

Hence, the statement 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.

When I investigated applications porting to IPv6-enabled, most of applications were IP-dependent. Therefore, most of them are needed modified to be HIP-enabled too.

Using LSIs instead of IP addresses in the IPv4 API should work, without modifications to the apps. But then you need to provide the system with the mapping LSI->HI->IP address, which may not be trivial if you are not using the DNS or something similar.

What the draft doesn't state (since that would modify current semantics) is that you can basically use any IPv4 address as an LSI if, and importantly only if, you know for sure that you want that address to refer to a specific, HIP-enabled mobile host. If you don't know that, you are looking for trouble through changing semantics in a way that may have unwanted side effects.

However, HIP deployment may benefit from current IPv6 deployment. If an application has been ported to be IP independent, change the host stack might be enough.

There I agree. With HIP, the semantics of using HITs through the IPv6 API are much cleaner than using LSIs or IP addresses through the IPv4 API.

--Pekka


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