Penguin

Discussion document for replacement for wand/wansd

Please note: This is related to the wand/wansd programs which are only responsible for distributing and learning other peoples IP/port -> MAC translation. It in particular does not relate to the actual tunnel which is run by Etud, which uses the IP/port -> MAC translations provided to talk to it's peers.

Please add any issues you can foresee, or pros and cons of any of the current issues.

MattBrown's proposed replacement design for WAND/WANSD is at http://www.mattb.net.nz/metanet/protocol.txt

TCP vs UDP

TCP makes it harder to spoof source address, and allows things like SSL.

TCP requires a connection to be made, either for each query/update (high overhead for both ends) or a persistant connection (more complex, deal with your remote end comming and going, firewalls timing out connections, etc etc).

UDP is very simple and non-stateless, but has issues with updates not fitting into a single packet (means that we need to cope with / expect multiple packets for an update) and will have problems doing auth properly.

Client/Server vs "p2p"

robustness - no reliance on single (or group) of machines

Although if a server (eg deuterium) does go down, the other routers can still talk to each other. Making the current wand talk to more than one wansd is a simple way to fix this, requires a timestamp to be provided by each wansd server (so the clients can pick the "upto date" entry if different entries are ever returned) and the wansd's to have a method to sync themselves to each other.

Complexity

need n^2 paths if every peer talks to every other peer.

ipt's routing protocol was n^2/2, not brilliant, but not too bad. I have better ideas of how to reduce this even further with what I've learnt from other routing protocols since then. Perhaps O(n)?

AddToMe