The rendezvous extension extends HIP and the HIP registration extension for initiating communication between HIP nodes via HIP rendezvous servers. The rendezvous server (RVS) serves as an initial contact point ("rendezvous point") for its clients. The clients of an RVS are HIP nodes that use the HIP Registration Protocol to register their HIT->IP address mappings with the RVS. After this registration, other HIP nodes can initiate a base exchange using the IP address of the RVS instead of the current IP address of the node they attempt to contact. Essentially, the clients of an RVS become reachable at the RVS' IP addresses.
The rendezvous server is similar to the home agent in Mobile IP. The rendezvous server provides a stable IP for the responder and forwards the initial I1 packet to the current location of the responder.
The participants:
I = Initiator, RVS = RendezVous Server, R = Responder
You should have run the base exchange once without rendezvous server to get familiar how the "/etc/hosts" and "/etc/hip/hosts" are configured.
The idea is that I wants to connect to R's HIT but only knows RVS's IP address (and that RVS is representing R). We'll show how to use RVS the native HIP example applications (although you can do it with nc6 or the other conntest test applications).
"/etc/hosts" and "/etc/hip/hosts" configurations:
INITIATOR: At the initiator, you must modify the "/etc/hosts" file. In the file, responder's hostname must be mapped to the IP address of the rendezvous server. It must not be mapped to the responder's IP address, or otherwise the rendezvous server is not used at all! Thus in /etc/hosts you should have: <RVS IP> <RESPONDER NAME>. The "/etc/hip/hosts" file should contain the hostname and the HIT of the responder as in the normal base exchange execution: <RESPONDER HIT> <RESPONDER NAME>. Notice that there are currently four different HITs at each machine's "dummy0" interface. When the responder registers to the rendezvous server, it can choose any one four HITs. Please make sure that you use the same HIT here as <RESPONDER HIT> as what the responder chooses to register. You can check which HIT is used with the hipconf tool. To do this, start HIP daemon at the Responder: "hipd/hipd". Next type "tools/hipconf get hi default" at the Responder and the default HIT is printed on screen. This is also the HIT that is registered to the RVS.
RVS: At the rendezvous server both files,"/etc/hosts" and "/etc/hip/hosts" are left blank ("/etc/hosts" can of course contain the non-hiprelated mappings). These files are left blank because the rendezvous server is assumed to have no information of its clients beforehand, it just offers the rendezvous service, and the responder then registers its HIT->IP mapping to the rendezvous server.
RESPONDER: Also at the responder both files,"/etc/hosts" and "/etc/hip/hosts" are left blank ("/etc/hosts" can of course contain the non-hiprelated mappings). The responder is assumed to know the IP address and the HIT of the rendezvous server, but this information is given as commandline parameters of "hipconf" tool.
Steps:
Start HIP daemon in each host: "hipd/hipd".
At the rendezvous server we have to indicate that we're willing to offer rendezvous service: "tools/hipconf add service rvs".
At the responder we have to register to the rendezvous server: "tools/hipconf add rvs <RVS-HIT> <RVS-IP>". This will establish a HIP SA between the rendezvous server and the responder. Please use the default HIT of the rendezvous server ("hipconf get hi default").
At the responder start a server listening for incoming connections: "test/conntest-server tcp 5000"
At the initiator start a connection: "test/conntest-client-gai <RESPONDER-HOSTNAME> tcp 5000"
At the initiator type some text and press CTRL + d. If everything works ok, the typed text should be now echoed at the responder.
Notes:
The rendezvous server is only supposed to relay the I1 packet. Once the I1 packet has been successfully relayed to the responder, all other traffic flows directly between the initiator and the responder.
The implemented mechanism is simple forwarding of I1 packet with source and destination IP addresses rewritten.
Drafts complied with: Host Identity Protocol (HIP) Registration Extension draft-ietf-hip-registration-02, Host Identity Protocol (HIP) Rendezvous Extension draft-ietf-hip-rvs-05.
The initiator does not yet store the IP addresses received in the VIA_RVS parameter encapsulated in R1 packet. This means that the double jump scenario does not work.
Parameters used during registration: REG_INFO, REG_REQUEST, REG_RESPONSE, REG_FAILED.
Parameters used with rendezvous service: RVS_HMAC, FROM, VIA_RVS.
The rendezvous mechanism is not yet guaranteed to be interoperable with other implementations than HIPL.