Config-file lines consist of a keyword and data.  The keyword, which is
case-insensitive, consists of everything from the first non-whitespace
character to the next whitespace character, or the end of line if there
is no following whitespace character.  If there are no non-whitespace
characters at all, or if the first such is a #, the line is a comment
and is ignored.

The data begins with the first non-whitespace character after the
keyword.  (This implies it cannot begin with whitespace.)

If a file ends with a partial line (ie, it has a last character but it
isn't a newline), a newline is supplied.  Note that this means that a
partial line ending a file read with @ does not merge with the line
after the @ - to put it another way, @ operates at a level where files
are streams of lines, not streams of bytes.

@ FILE
	FILE is read and its contents effectively inserted in place of
	this line.

key KEY
	The cloud key is literally KEY.

keyfile KEYFILE
	KEYFILE is read and the contents are the cloud key.  If the
	file is larger than 64K, only the first 64K is used.

	Note that no transformations are applied to the file's
	contents; for example, using "key foo" is not the same as doing
	"echo foo > foofile" and then using "keyfile foofile", because
	the file will contain a fourth character, a newline, and a
	three-character key "foo" is as different from a four-character
	key "foo\n" as any other two distinct keys are.

id N
	This member's cloud ID is N; N must be in 0..255.

ip ADDR
	ADDR is one of this member's cloud IPs.  This may be given
	multiple times; the resulting addresses accumulate.

type T
	This member's type is T.  In the typology of protocol.doc, T
	can be (case-insensitive)

		public	This cloud member is type 1 or 2; it pays
			attention to PUBLIC packets and tries to
			maintain connections to the endpoints in them.

		save FILE
			Like public, except that the list of PUBLIC
			peer addresses is periodically saved to FILE.
			If FILE exists on startup, it is read and the
			address(es) found therein is/are treated just
			like peers learned from PUBLIC messages.

		private	This cloud member is type 3 or 4; it ignores
			PUBLIC packets, using only the address(es) it
			has been configured with by `peer' lines.

listen ADDR/PORT [OPTIONS ...]
	This host is type 1 (or 4) and should listen on ADDR/PORT for
	cloud connections.  This may be given multiple times to listen
	on multiple endpoints.  The special strings *, *4, and *6 may
	be given for ADDR to listen on all local addresses, all local
	IPv4 addresses, and all local IPv6 addresses, respectively.

	OPTIONS may include "retry", "public", and "private".  Public
	listening points are advertised in PUBLIC packets; private ones
	aren't.  If TYPE is not given, listening points at RFC-1918
	private addresses (for IPv4) or link-local or site-local
	addresses (for IPV6) are private and others are public - but *,
	*4, and *6 listening points cannot be advertised under any
	circumstances.  "retry" indicates that bind() failure on
	startup is not fatal and should, instead, be retried
	periodically until succeeding.

peer ADDR/PORT
	This can be given multiple times, and the contact points
	accumulate.  For a type 1 or 2 host, these give initial entry
	points into the public cloud; for types 3 and 4, these list the
	host's peer(s).  Peers configured this way never expire, in
	contrast to peers learned from PUBLIC messages.

tun N [TYPE]
tun DEVPATH [TYPE]
	These specify the tun device.  If the argument is a number
	(anything accepted by strtol(3) with third argument 0), the
	device pathname is constructed from it a la /dev/tun%d;
	otherwise, the argument is used directly.  (To use an
	all-numeric name as the device node, prefix it with a path,
	using ./ if necessary.)

	The optional TYPE may be POINTOPOINT or BROADCAST
	(case-insensitive).  If specified, the tun interface mode is
	changed (with TUNSIFMODE) to that value.  If neither is
	specified, no attempt to change the interface type is made.

	There is no escaping mechanism; it is not possible to use a
	DEVPATH string containing whitespace.

control ADDR/PORT
control PATH [MODE]
	Specifies a control point.  This can be a network socket
	(ADDR/PORT) or an AF_LOCAL socket at PATH; in the latter case,
	PATH must begin with a slash, to allow the parser to tell the
	difference.  The control point is designed for interactive use,
	allowing a human to control many aspects of the daemon's
	operation.  When using IP addresses, this supports the same *,
	*4, and *6 strings that listen lines do.

	If MODE is given on a PATH line, it is separated from PATH by
	whitespace.  There is no support for PATHs containing
	whitespace.

	Multiple control lines may be given to listen for control
	connections at multiple places.

route ARG [ARG...]
	The cloud includes support for a member to advertise routes to
	networks behind it.

	Each ARG can be either ADDR/MASK, a numeric netblock with a
	slash and a mask width, or a keyword controlling various
	optional capabilities.

	When given an address and mask, this specifies that this member
	has network ADDR/MASK present behind it.  If /MASK is omitted,
	it defaults to /32 for IPv4 and /128 for IPv6.

	Keywords can be

	ignore
	listen
		These specify that this cloud member is to ignore or
		listen to ROUTE packets.

	install
	noinstall
		These specify that this cloud member is or is not to
		install routes into the kernel corresponding to routes
		advertised by other cloud members.

	block
		All further ADDR/MASK args on this line do not specify
		routes for this cloud member to advertise; instead,
		they specify routes that it should never install into
		its kernel even if it receives them.  It is unnecessary
		to specify block addresses for a config that also
		specifies noinstall, since when noinstall is in effect
		nothing is installed anyway; it is not, however, an
		error to do so.

		block specifications block only exact matches.  For
		example, "block 10.0.8.0/23" will not block another
		cloud member's 10.0.8.0/24, nor 10.0.8.0/22.  The
		intent is not general-purpose route filtering but
		rather to suppress routes for networks shared by
		multiple hosts, eg between a type 1 or 2 host which
		advertises a private network and a type 3 host which
		speaks to it over that same network.

		It is not an error (but is useless) to specify block on
		a route line without any ADDR/MASK specs after it.

	The default is "listen install" with no netblocks advertised or
	blocked.  Note that if ignore is set, install/noinstall doesn't
	matter, since there are then no routes available to be
	installed.

	If multiple conflicting options are given, the last one
	specified wins.  This applies both to each route line and to
	multiple route lines.

	Routes are never installed for netblocks this cloud member
	advertises; it is nonsensical to advertise a netblock without
	having some non-cloud way to reach it.

	If a route is installed via an ID which has multiple IPs (as
	in, multiple "ip" lines in its configuration), which IP the
	route points to is random.  However, because of kernel routing
	table limitations, the address family of the route and the
	target have to be the same; this implies that a cloud member
	with no IP in a given address family cannot usefully advertise
	routes to netblocks of that address family.  For example, a
	host with no v6 addresses advertising a v6 block cannot work.