[rrg] Rejecting all but Strategy A

[Pekka Nikander]

I (Pekka) wrote:
>>>> I don't know the details of LISP, but the recent discussion  
>>>> between Dino and me seem to indicate that HIP proxy and LISP xTRs  
>>>> are functionally close enough so that a HIP proxy could be  
>>>> "plugged in" to the LISP architecture...

Dino replied:
>>> And since I don't know the details of HIP-proxy, saying LISP and  
>>> HIP-proxy are functionally equivalent only occurs at a  
>>> conversational level.  The devil is in the details of course.

Eric noted:
>> I strongly resonate with Pekka's posting.

Which make Fred to ask:
> Pekka, is "HIP-proxy" and "HIP mobile router" one and the same thing?

Briefly, a "HIP-proxy" (as I understand the term) could be implemented  
as a version of the "HIP mobile router" (draft-melen-hip-mr-01.txt)  
that has the additional feature of being able to support unmodified  
legacy IPv4 and IPv6 nodes in the mobile network.  For such legacy  
nodes, the MR node would create ephemeral HIP identities and assign an  
IP address in the moving network side for each identity.  Hence,  
typically, the legacy host would get a single stable the IP address  
through DHCP or ND, in which case the MR would act as the DHCP or ND  
server.  OTOH, there is no need for the MR to actually be mobile --  
the mobility aspect could simply refer to its ability to use  
interchangeably multiple PI addresses.

So, I guess my answer is a qualified "no".  They are not the same  
thing, though they could be close.

One old, outdated description of the HIP proxy functionality is  
available as Patrik's MSc thesis at http://www2.cs.hut.fi/~pmrg/index.cgi?id=148 
    But that is basically 4 years old and concerns only the case where  
there is a 3G legacy network, not generic legacy networks at both  
sides.  Quite obviously, the thinking has evolved quite a lot since  
then.

> If so, IMHO it is absolutely realistic that the HIP-proxy and xTR  
> could occur on exactly the same platform.  Note that they are  
> complementary functions, however; not competing ones. I think this  
> also goes with what Eric was saying below?

I don't see any problem at all in installing a HIP proxy and xTR at  
the same box -- they could even use the same mapping infrastructure to  
find out the RLOC of the peer HIP proxy/xTR, and then in parallel send  
an opportunistic HIP I1 and whatever LISP sends when an xTR contacts  
another xTR that it has no prior association with.  But that would be  
a (minor) waste of resources as two packets would be sent in parallel.

Initially, what I think would be interesting to understand is the  
possibility of two additional designs:

1. One where the LISP xTR-xTR protocol is replaced with the HIP  
protocol (providing the additional mobility and security features HIP  
provides).

2. One where the initial xTR->xTR opening message is a hybrid that  
indicates that the sender understands both LISP and HIP, allowing the  
receiver to pick which one to use.

And then I could imagine a few designs beyond either...

--Pekka