+@node The meta-protocol, Security, The connection, Technical information
+@section The meta-protocol
+
+The meta protocol is used to tie all tinc daemons together, and
+exchange information about which tinc daemon serves which virtual
+subnet.
+
+The meta protocol consists of requests that can be sent to the other
+side. Each request has a unique number and several parameters. All
+requests are represented in the standard ASCII character set. It is
+possible to use tools such as telnet or netcat to connect to a tinc
+daemon and to read and write requests by hand, provided that one
+understands the numeric codes sent.
+
+The authentication scheme is described in @ref{Authentication protocol}. 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.
+
+@cindex ADD_HOST
+@cindex ADD_SUBNET
+@example
+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
+--------------------------------------------------------------------------
+@end example
+
+@cindex DEL_HOST
+@cindex DEL_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.
+
+@cindex REQ_KEY
+@cindex ANS_KEY
+@cindex KEY_CHANGED
+@example
+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
+--------------------------------------------------------------------------
+@end example
+
+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. A little bit of salt (random data) is added
+with each PING and PONG message, to make sure that long sequences of PING/PONG
+messages without any other traffic won't result in known plaintext.
+
+@cindex PING
+@cindex PONG
+@example
+daemon message
+--------------------------------------------------------------------------
+origin PING 9e76
+ \__/
+ +--> 2 bytes of salt (random data)
+dest. PONG 3b8d
+ \__/
+ +--> 2 bytes of salt (random data)
+--------------------------------------------------------------------------
+@end example
+
+This basically covers what is sent over the meta connection by
+tinc.
+
+
+@c ==================================================================
+@node Security, , The meta-protocol, Technical information