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

[Pekka Nikander <pekka.nikander@nomadiclab.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.

> 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