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

[Sheng Jiang <shengjiang@huawei.com>]

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

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. For
those IP-independent applications, changing host stacks and mapping system
could be sufficient. However, before IPv6 motivated applications to be
IP-independent. More than 90 percent applications did use IP as identifier.

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



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