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 _______________________________________________ rrg mailing list [email protected] https://www.irtf.org/mailman/listinfo/rrg
