Table of Contents
Opportunistic mode has two benefits. First, you don't have to know the HIT of the peer. This is makes HIP more suitable to "ad-hoc" environments where preconfiguration of HITs is difficult. Second, the opp. mode implementation allows the use of IPv4 addresses at the application. This way, even IPv4-only legacy applications can benefit from the security and mobility features of HIP.
Opportunistic mode is compiled on by default. In order to use Opportunistic mode enabled HIP, the following steps are needed:
Move to top level of HIPL
e.g. cd hipl
Run autogen.sh
./autogen.sh
Run make
make
Run hip daemon on both "crash" and "oops"
hipd/hipd
. Using hipconf tool to set HIP Opportunistic mode on both hosts manually. "tools/hipconf set opp on|off" command is used to enable/disable opportunistic mode. By default it is on.
Now the opportunistic mode is enabled. To test Opportunistic mode, you need to remove crash's HITs and name from /etc/hip/hosts, and then following the steps in Chapter 9, Testing a HIP connection between two locally connected hosts.
HIPL supports also opportunistic mode that is uses TCP options to detect whether peer supports HIP or not. This is particularly useful in networking environments without HIP look up infrastructure (OpenDHT/DNS/etc) and where the number of HIP hosts is small. This "advanced" version of the opportunistic mode enables fast and backwards compatible fallback to non-HIP communications for TCP connections when the peer does not support HIP. To use the opportunistic mode, start both the hipd and hipfw (e.g. with option -A). Then instruct "hipconf set opp advanced" and use the opportunistic mode as instructed earlier in this section.
The normal HIP opportunistic mode experiences a delay when a HIP peer tries to communicate with a non-HIP peer. This happens because the initiator waits for a HIP response before falling back on normal TCP communication. The efficient detection of peer HIP capability enables us to detect peer HIP capability or the lack thereof. If we detect that the peer supports HIP, we continue the HIP opportunistic communication. Otherwise, communication falls back on plain TCP. Efficient detection of peer HIP capability is enabled with the second of the following commands.
As an example, we run the HIP daemon first.
1. hipd
Afterwards, we run the firewall as shown in the following command. The firewall is needed in case the peer does not support HIP, because it captures the incoming TCP SYN_ACK packet and notifies the HIPD of the lack of HIP support at the peer:
2. hipfw -dA
Then, we enable efficient, undelayed detection of peer HIP capability with the following command:
3. hipconf set opp advanced
To try the feature, we initiate a TCP connection using the HIP opportunistic library:
4. hipconf run opp wget IP-number
One thing to stress here is that the receiver should also run the firewall and enable the efficient HIP opportunistic mode in order to be ensure being detected correctly. If this feature is not enabled at the receiver, correct detection depends on the relative latency of a TCP and a HIP packet.
The enabling at the receiver is done by executing step 2 after the HIP daemon has started.