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 autoreconf
autoreconf --install
Run configure
./configure
Run make
make
Run make install
make install
Run hip daemon on both "crash" and "oops"
hipd
Use the hipconf tool to set up HIP Opportunistic mode on both hosts manually. "hipconf set opp on|off" 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 the section called “For Hackers: How to Test HIP Connectivity from Command Line using 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 (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.
The system-based opportunistic mode enables HIP communication without the use of the opportunistic library. If the peer does not support HIP, communication falls back on normal TCP communication.
The system-based opportunistic mode is implemented at the HIP firewall. It is enabled with the -o option as shown below:
hipfw -dAo
Following is an example of all the steps to be followed at two peers for using the system-based opportunistic mode between them.
At the responder, one can execute these steps:
1. hipd
2. hipfw -Aod
3. nc -l 1111
At the initiator, one can execute these steps:
1. hipd
2. hipfw -dAo
3. nc <responder-ip> 1111
HIPL supports the extensions defined in http://tools.ietf.org/html/draft-nikander-hip-hiccups. Support for the extensions is very experimental and may not interoperate with other extensions in HIPL. The data packet mode does not support sequence numbers, UDP encapsulation nor switching to ESP yet. Next, we'll give an example how to try out the extension:
Start HIP software as follows both at the client and server host:
# hipd -k # hipfw -Aid # hipconf datapacket on
Notice that the last command can be also configured to /etc/hip/hipd_config
Then execute at the client:
ping6 <HIT_OF_THE_SERVER>
Please do not take <HIT_OF_THE_SERVER> literally. You should replace it with the actual HIT of the server.