+To let the kernel on the receiving end accept the packet, the destination MAC
+address must match that of the virtual network interface.
+If tinc is in it's default routing mode, ARP does not work, so the correct destination MAC cannot be set
+by the sending daemons.
+tinc solves this by always overwriting the
+destination MAC address with fe:fd:0:0:0:0. That is also the reason why you must
+set the MAC address of your tap interface to that address.
+
+
+@c ==================================================================
+@node The meta-connection, , The UDP tunnel, The connection
+@subsection The meta-connection
+
+Having only an UDP connection available is not enough. Though suitable
+for transmitting data, we want to be able to reliably send other
+information, such as routing and session key information to somebody.
+
+@cindex TCP
+TCP is a better alternative, because it already contains protection
+against information being lost, unlike UDP.
+
+So we establish two connections. One for the encrypted VPN data, and one
+for other information, the meta-data. Hence, we call the second
+connection the meta-connection. We can now be sure that the
+meta-information doesn't get lost on the way to another computer.
+
+@cindex data-protocol
+@cindex meta-protocol
+Like with any communication, we must have a protocol, so that everybody
+knows what everything stands for, and how she should react. Because we
+have two connections, we also have two protocols. The protocol used for
+the UDP data is the ``data-protocol,'' the other one is the
+``meta-protocol.''
+
+The reason we don't use TCP for both protocols is that UDP is much
+better for encapsulation, even while it is less reliable. The real
+problem is that when TCP would be used to encapsulate a TCP stream
+that's on the private network, for every packet sent there would be
+three ACKs sent instead of just one. Furthermore, if there would be
+a timeout, both TCP streams would sense the timeout, and both would
+start re-sending packets.
+
+
+@c ==================================================================
+@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
+successful 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_EDGE
+@cindex ADD_SUBNET
+@example
+daemon message
+--------------------------------------------------------------------------
+origin ADD_EDGE node1 12.23.34.45 655 node2 21.32.43.54 655 222 0
+ | | | \___________________/ | +-> options
+ | | | | +----> weight
+ | | | +----------------> see below
+ | | +--> UDP port
+ | +----------> real address
+ +------------------> name of node on one side of the edge
+
+origin ADD_SUBNET node 192.168.1.0/24
+ | | +--> prefixlength
+ | +--------> IPv4 network address
+ +------------------> owner of this subnet
+--------------------------------------------------------------------------