For Hackers: How to Test HIP Connectivity from Command Line using two Locally Connected Hosts

We will show in this section how to connect two hosts using HIP. This section is oriented towards hackers and developers.

We assume two machines called crash and oops that are in the same network. Crash is the one that starts a communication against oops.

Both machines are used through this whole document as examples even though you probably have your own naming and addressing conventions. It is possible to use IPv4 addresses as well as IPv6 addresses on-wire.

This section show to developers and maintainers how to test your HIPL installation. The section starts with IPv6 test applications, continues with IPv4-IPv6 interoperability and concludes with IPv4 test applications.

Testing a HIP connection with an IPv6 application

You can test HIP with any networking application, but in this section we will demonstrate few command line applications.

You should run nc6 with root privileges at the server side if the port number is less than 1024.

In this section we will use ipv6 addresses, but you can use also ipv4 addresses. Furthermore, the use of hipfw is optional.

oops:

  • ifconfig eth0 inet6 add 3ffe::2/64

  • hipd # (to start as a background daemon process, add -b flag)

  • nc6 -l -p 1111

Crash will act as the connection initiator, so we need to configure the hosts files of crash:

FileLine to add
/etc/hostsHIT_OF_OOPS oops
/etc/hosts3ffe::2 oops

You need to run also the following commands at the crash host:

  • ifconfig eth0 inet6 add 3ffe::1/64

  • hipd

  • nc6 oops 1111

  • <Type some text in crash, press enter and you should see some text appearing in the output of the hosts>

This will setup a HIP connection between the two hosts (it may take a while if you are using virtual machines). You should replace HIT_OF_XXX with the HIT of the host XXX. The hip daemon loads (and creates if necessary) the host identities from /etc/hip automatically. If you want to know the default HIT of the localhost, run "hipconf get hi default". You can list all HITs of the machine with "hipconf get hi all". By default, you'll see only one. If you want to use all four HITs of the host, you have to invoke "hipconf add hi default". The use of multiple local HITs is not currently recommended!

Mappings between HITs and IP addresses are usually set up automatically with the hosts files. Manual configuration is also possible but not necessary:

hipconf add map PEER_HIT PEER_IP

You can also add the mapping to "/etc/hip/hipd_config" and restart hipd. It is also possible to use DNS for the mappings.

Link local IPv6 addresses are not supported well, so do not use them. Use global IPv6 addresses instead for testing. The reason for this is that it is hard to know if the peer belongs to the same local network as we are or not.

IPv4 and IPv6 interoperability

One of the main advantages is that the conjunction of LSIs and HITs allows the communication between IPv4 and IPv6 applications. We will show an example using the configuration described in the IPv4 section of this section.

oops:

  • nc6 -l -u -p 5555

crash:

  • nc OOPS_LSI -u 5555

  • <Type some text, press enter and you should see some text appearing in the output of the host oops>

We can check also the opposite case.

oops:

  • nc -l -u 5555

crash:

  • nc6 OOPS_HIT -u 5555

  • <Type some text, press enter and you should see some text appearing in the output of the host oops>

Tips: Displaying log information and traffic. 

For both, LSIs and HITs we can obtain more information about how they work showing more information messages with the daemons or capturing the network packets.

The log messages displayed by the hip daemon can be changed dynamically:

hipconf debug none # <only HIP_DIE messages are shown>

hipconf debug medium # <shows HIP_DIE, HIP_ERROR and HIP_INFO messages>

hipconf debug all # <shows all messages, including HIP_DEBUG>

These options can be also set in "/etc/hip/hipd_config" to configure hipd and other libraries at startup.

See the log messages for information about the result of HIP base exchange and USAGI IPSec negotiation. Tcpdump or ethereal are good tools for dumping the network traffic during the base exchange. For tcpdump, you can use "tcpdump -n -i any esp or proto 139 or port 10500" to catch HIP-only traffic. It should be taken into account that LSIs are local identifiers, so they are not in the wire.

Testing a HIP connection with an IPv4-only application

Initial configuration. 

We have different mechanism for mapping the HIT-LSI information. We can choose whatever of the next possibilities. The user can introduce manually the LSI or this can be created automatically by the hip daemon. It should be noticed that the address interval between 1.0.0.1 - 1.0.0.4 is already in use by the hipd, so the user must choose a free LSI. These four LSIs are the local LSIs assigned with the four local HITs.

crash:

  • Add the information in /etc/hosts

    • OOPS_HIT oops

    • OOPS_LSI oops Optional! If it's not defined, it would be created by the daemon

  • Add the information with hipconf add map

    • hipconf add map OOPS_HIT OOPS_IP [OOPS_LSI]

If the command hipconf add map is not executed, we must add the peer IP in the file /etc/hosts

  • OOPS_IP oops

Apart from starting the hipd process, the hipfw process must be also started in both machines, oops and crash. Notice that hipfw must be started always before hipd!

  • hipfw -lA (to start the firewall with LSI support enabled and allow HIP/ESP packets)

  • hipd # (to start as a background daemon process, add -b flag)

Beforehand the following rules must be added in the file /etc/hip/firewall.conf

crash:

  • INPUT -src_hit OOPS_HIT ACCEPT

  • OUTPUT -dst_hit OOPS_HIT ACCEPT

oops:

  • INPUT -dst_hit OOPS_HIT ACCEPT

  • OUTPUT -src_hit OOPS_HIT ACCEPT

Running the application. 

Once we have finished the step before and started running hipd and hipfw, we can run the application. If the LSI has been generated automatically, we can check its value with hipconf get ha OOPS_HIT or hipconf get ha all. Afterwards, we start running the application, e.g.:

  • ping OOPS_LSI

  • ssh OOPS_LSI

  • nc OOPS_LSI -u 5555 # oops must be running nc -l -u 5555