-When tinc daemons connect to each other, they will have to
-authenticate each other first. This is done by exchanging BASIC_INFO,
-PASSPHRASE, PUBLIC_KEY and ACK requests. BASIC_INFO requests contain
-the virtual address and netmask of the tinc daemon, protocol version,
-port number and flags. This identifies that tinc daemon, though it
-still has to be verified. To that end, passphrases and public keys are
-exchanged. The passphrases are known at both ends, but they are
-encrypted with the public key before transmission. This way, nobody
-that sniffs the network can see what the passphrase actually was, and
-at the same time this ensures that the other host really knows the
-secret key that belongs to the public key it sends. If both hosts are
-satisfied, the connection is activated, the contents of each other's
-connection lists are exchanged and other requests may be sent. The
-following diagram shows how authentication is done:
-
-Client Server
-----------------------------------------------------------------
-
-
-----------------------------------------------------------------
-
-The client must never make a connection to a server that is already in
-it's connection list. Not only would it corrupt the connection list,
-but it would also violate the tree property. The meta connections must
-always be so that there are no loops. This is very important, because
-certain requests are broadcast over the entire network of tinc
-daemons. If there were loops in the network topology, some packets
-would be forwarded in a ring until the end of times (or until the ring
-breaks, which probably happens before time ends).
+The authentication scheme is described in the SECURITY file. After a
+succesful authentication, the server and the client will exchange all the
+information about other tinc daemons and subnets they know of, so that both
+sides (and all the other tinc daemons behind them) have their information
+synchronised.
+
+daemon message
+--------------------------------------------------------------------------
+origin ADD_HOST daemon a329e18c:655 0
+ | | +--> options
+ | +---------> real address:port
+ +-------------------> name of new tinc daemon
+origin ADD_SUBNET daemon 1,0a010100/ffffff00
+ | | | +--> netmask
+ | | +----------> vpn IPv4 network address
+ | +----------------> subnet type (1=IPv4)
+ +--------------------> owner of this subnet
+--------------------------------------------------------------------------
+
+In case daemons leave the VPN, DEL_HOST and DEL_SUBNET messages with exactly
+the same syntax are sent to inform the other daemons of the departure.
+
+The keys used to encrypt VPN packets are not sent out directly. This is
+because it would generate a lot of traffic on VPNs with many daemons, and
+chances are that not every tinc daemon will ever send a packet to every
+other daemon. Instead, if a daemon needs a key it sends a request for it
+via the meta connection of the nearest hop in the direction of the
+destination. If any hop on the way has already learned the key, it will
+act as a proxy and forward it's copy back to the requestor.
+
+daemon message
+--------------------------------------------------------------------------
+daemon REQ_KEY origin destination
+ | +--> name of the tinc daemon it wants the key from
+ +----------> name of the daemon that wants the key
+daemon ANS_KEY origin destination e4ae0b0a82d6e0078179b5290c62c7d0
+ | | \______________________________/
+ | | +--> 128 bits key
+ | +--> name of the daemon that wants the key
+ +----------> name of the daemon that uses this key
+daemon KEY_CHANGED origin
+ +--> daemon that has changed it's packet key
+--------------------------------------------------------------------------
+
+There is also a mechanism to check if hosts are still alive. Since network
+failures or a crash can cause a daemon to be killed without properly
+shutting down the TCP connection, this is necessary to keep an up to date
+connection list. Pings are sent at regular intervals, except when there
+is also some other traffic.
+
+daemon message
+--------------------------------------------------------------------------
+origin PING
+dest. PONG
+--------------------------------------------------------------------------
+
+This basically covers everything that is sent over the meta connection by
+tinc.