hipl-core team mailing list archive
Mailing list archive
[Bug 619332] Re: Broadcast as fall-back mechanism when no HIT->IP
Regarding to broadcast, I just recalled a problem related to NATs that
it solved for me. I have a server at home behind a NAT box which has a
public IP address. I have pinholed the NAT to pass HTTP and SSH to the
server. The DNS contains a public address for the machine.
The problem occurs when I am at home with a laptop and contact my server
using its public IP address (via DNS). The connection fails because the
NAT box does not support so called hairpinning (I believe this is quite
common). So I have to use the private address of the server at home and
outside home I can use DNS normally (public IP address). This sucks big
While split DNS horizon or bying a more expensive NAT box would solve
the case, they both have their tradeoffs (configuration complexity or
monetary cost). HIP with an option for broadcast would offer a cheap and
straightforward solution for the problem. Right?
Broadcast as fall-back mechanism when no HIT->IP
You received this bug notification because you are a member of HIPL core
team, which is subscribed to HIPL.
Status in Host Identity Protocol for Linux: New
If the hip daemon can't resolve an address with hip_map_id_to_addr, it tries to broadcast an I1 message using standard interfaces.
This fallback mechanism is in my and Renes opinion useless and should be stripped out.
The cause of failing in my particular case was that I mounted /etc/hip/hosts with fuse and the fopen function failed to open it, even though hipd had root rights.