Abstract
In this section, we show how to use the rendezvous server to establish a HIP connection between two HIP hosts using the "conntest-server" connection test server and the "conntest-client-hip" connection test client.
Before you test the rendezvous mechanisms, you should have run the base exchange once without the rendezvous server to get familiar how the "/etc/hosts" and "/etc/hip/hosts" files are configured. Please see Chapter 9, Testing a HIP connection between two locally connected hosts for information on how to run a base exchange without the rendezvous server. Also, before you can test the rendezvous mechanism, the configuration file must be edited appropriately, see the section called “The RVS and HIP Relay Configuration File” for more information.
The rendezvous server is similar to the home agent in Mobile IP. The rendezvous server provides a stable IP address for the responder and forwards the initial I1 packet to the current location of the responder. 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).
Base exchange via the rendezvous server. I = Initiator, RVS = RendezVous Server, R = Responder
First, the "/etc/hosts" and "/etc/hip/hosts" files are configured. Please notice that you can leave all non-HIP-related values in "/etc/hosts" intact.
INITIATOR
In the "/etc/hosts" file you should have: <RVS IP> <RESPONDER NAME>. In other words the responder's host name is mapped to the IP address of the rendezvous server. It is important that the responder's host name is NOT mapped to responder's IP address. Otherwise the rendezvous server is not used at all!
In the "/etc/hip/hosts" file you should have: <RESPONDER HIT> <RESPONDER NAME>. This is the line that you would have in a normal base exchange execution not involving an RVS. Please make sure that you use the same HIT here as <RESPONDER HIT> as what the "tools/hipconf get hi default" outputs at the responder.
RVS
Both files, "/etc/hosts" and "/etc/hip/hosts", are left blank. The files are left blank because the rendezvous server is assumed to have no information of its clients beforehand. The RVS can have some white listed HITs as beforehand information, however, but it is not required to have none whatsoever. Using the white list to filter HITs is local policy and as such is not part of the registration procedure.
RESPONDER
At the responder, both files,"/etc/hosts" and "/etc/hip/hosts", are left blank also. The responder is assumed to know the IP address and the HIT of the rendezvous server, but this information is given as command line parameters of the "hipconf" tool.
You are now ready to test the actual connection establishment. You will need two shells open on each host, one for the HIP daemon and other for the hipconf tool:
Start HIP daemon at each host:
hipd/hipd
At the rendezvous server, we have to indicate that we are willing to offer rendezvous service:
tools/hipconf add service rvs
At the responder, we have to register to the rendezvous server:
tools/hipconf add server rvs [RVS-HIT] <RVS-IP or hostname> <LIFETIME-IN-SECONDS>
This will launch a base exchange i.e. establish a HIP SA between the rendezvous server and the responder. Please use the default HIT of the rendezvous server ("tools/hipconf get hi default" at the RVS). The <LIFETIME-IN-SECONDS> value represents the number of seconds we would like our service registration to last, but it is not necessarily the number of seconds we are granted the service. Notice that opportunistic mode will be used if you don't specify rendezvous HIT.
At the responder, start a server listening for incoming connections (5000 is an example port number):
test/conntest-server tcp 5000
At the initiator, start a connection test client:
test/conntest-client-hip <RESPONDER-HOSTNAME> tcp 5000
At the initiator, type some text and press CTRL + d. If everything works as it should, the typed text should now be echoed at the responder.
Server side commands i.e. commands run on the rendezvous server.
To cancel the rendezvous service (without killing the HIP daemon) type:
tools/hipconf del service rvs
This will delete all existing rendezvous server registrations and remove the rendezvous service from the offered services.
To reinitialize the rendezvous service after modifications to the configuration file (without killing the HIP daemon) type:
tools/hipconf reinit service rvs
The changes that you have made to the configuration file affect the clients registering after the reinitialization.
Client side commands i.e. commands run on the responder (rendezvous server client).
To cancel the registration to the rendezvous service type:
tools/hipconf del server rvs <RVS-HIT> <RVS-IP>
This will send a HIP message asking for rendezvous service cancellation to the rendezvous server.
The rendezvous service implementation is based on RFC 5204: Host Identity Protocol (HIP) Rendezvous Extension and RFC 5203: Host Identity Protocol (HIP) Registration Extension.
At the time of writing this section, the UPDATE packet implementation of HIPL was under heavy renovation. Therefore the RVS extension does not have UPDATE packet support. Effectively this means that the current rendezvous service implementation uses base exchange packets to signal any changes in the service status.
For example, when you register to the RVS service and then cancel the service, the HIP daemon will launch a base exchange for both the service registration and the service cancellation. According to RFC 5203 the service cancellation should use UPDATE packets since there already is a HIP connection between the client and the server.
The rendezvous server relays only the I1 packet. Once the I1 packet has been successfully relayed to the responder, the responder sends an R1 packet directly to the initiator and the initiator learns the responder's location from the IP header of the R1 packet. Therefore, all successive traffic flows directly between the initiator and the responder.
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.
The responder does not yet store the granted service lifetime anywhere.
17th of July 2008