HIPL supports also initiating connections from behind a NAT. The basic idea is that the initiator encapsulates HIP control packets and ESP data packets within UDP. This way, the packets can traverse the NAT box. However, both the initiator and responder have to support NAT extensions in order to make this work. Currently, the responder cannot be located behind a NAT.
The NAT traversal can be experimented in a similar way as depicted in earlier sections. The only difference is that you have to tell the initiator manually that it is behind a NAT using "hipconf hip nat on". After this, you can initiate the base exchange according to the previous instructions. The manual configuration is currently required because support for automatic NAT detection (STUN) has not been implemented yet.
If you have problems in even getting I1 triggered using NAT code e.g. with conntest-client-gai (occurred on 2.6.16.5), you may have to specify the source HIT explicitly. The procedure to initiate a connection behind NAT is as follows:
tools/hipconf hip nat on
tools/hipconf add map peer_hit peer_ipv4_addr
ping6 -I source_hit dst_hit
Make sure that the source is the same as in "ip xfrm policy" output. We are aware of the problem (see bug id 161) and it is being solved. Also, it seemed like the responder could not route packets automatically to the NAT, so a "ip route add nat_ipv4_addr dev xx" was necessary at the responder (occurred on 2.6.16.5).
Three cases of mobility of the initiator have been implemented for the NAT code.
Mobility from behind NAT to behind the same NAT: For this case, the use the standard procedure for update after the base exchange is completed. The update would be UDP encapsulated.
Mobility from public addressable network to behind NAT: Once a hip association is set up between two hosts, both on the public network and one of them wishes to move behind a NAT, then that node should first delete the public ip address, then turn the NAT on using hipconf and then add the ip address behind NAT along with the route to the interface. The update would be done using UDP now and future communications would be UDP encapsulated (both HIP control traffic and ESP packets).
Mobility from behind NAT to publically addressable network: If a node has setup hip association from behind NAT and now wishes to move to public IP domain, then it should first delete the ip behind NAT, turn off the NAT using hipconf and then add the public IP along with the route to the interface. HIP association then would not use UDP encapsulation and the update would be done using normal HIP packets (without UDP encapsulation).