Use edge local addresses for local discovery.
authorEtienne Dechamps <etienne@edechamps.fr>
Sun, 22 Jun 2014 16:27:55 +0000 (17:27 +0100)
committerEtienne Dechamps <etienne@edechamps.fr>
Sun, 29 Jun 2014 10:23:32 +0000 (11:23 +0100)
commite16ade874d08f82481dca7302b98305bcfbe27cf
tree67aff02a1c629a4312fff7bcfb9469963ae7fc87
parentbfce56d473e1e01a8af0260262ca84f09154e71f
Use edge local addresses for local discovery.

This introduces a new way of doing local discovery: when tinc has
local address information for the recipient node, it will send local
discovery packets directly to the local address of that node, instead
of using broadcast packets.

This new way of doing local discovery provides numerous advantages compared to
using broadcasts:

 - No broadcast packets "polluting" the local network;

 - Reliable even if the sending host has multiple network interfaces (in
   contrast, broadcasts will only be sent through one unpredictable
   interface)

 - Works even if the two hosts are not on the same broadcast domain. One
   example is a large LAN where the two hosts might be on different local
   subnets. In fact, thanks to UDP hole punching this might even work if
   there is a NAT sitting in the middle of the LAN between the two nodes!

 - Sometimes a node is reachable through its "normal" address, and via a
   local subnet as well. One might think the local subnet is the best route
   to the node in this case, but more often than not it's actually worse -
   one example is where the local segment is a third party VPN running in
   parallel, or ironically it can be the local segment formed by the tinc
   VPN itself! Because this new algorithm only checks the addresses for
   which an edge is already established, it is less likely to fall into
   these traps.
doc/tinc.conf.5.in
src/net_packet.c
src/node.h