+.SS "Setting up a VPN with tripe"
+The
+.B tripe
+server identifies peers by name. While it's
+.I possible
+for each host to maintain its own naming system for its peers, this is
+likely to lead to confusion, and it's more sensible to organize a naming
+system that works everywhere. How you manage this naming is up to you.
+The only restriction on the format of names is that they must be valid
+Catacomb key tags, since this is how
+.B tripe
+identifies which public key to use for a particular peer: they may not
+contain whitespace characters, or a colon
+.RB ` : '
+or dot
+.RB ` . ',
+.PP
+Allocating IP addresses for VPNs can get quite complicated. I'll
+attempt to illustrate with a relatively simple example. Our objective
+will be to set up a virtual private network between two sites of
+.BR example.com .
+The two sites are using distinct IP address ranges from the private
+address space described in RFC1918: site A is using addresses from
+10.0.1.0/24 and site B is using 10.0.2.0/24. Each site has a gateway
+host set up with both an address on the site's private network, and an
+externally-routable address from the public IP address space. Site A's
+gateway machine,
+.BR alice ,
+has the addresses 10.0.1.1 and 200.0.1.1; site B's gateway is
+.B bob
+and has addresses 10.0.2.1 and 200.0.2.1.
+.PP
+This isn't quite complicated enough. Each of
+.B alice
+and
+.B bob
+needs an extra IP address which we'll use when setting up the
+point-to-point link. These addresses need to be routable, at least
+within the virtual private network: unfortunately, you can't just use
+the same pair everywhere. We'll assign
+.B alice
+the point-to-point address 192.168.0.1, and
+.B bob
+the address 192.168.0.2.
+.hP 1.
+Install
+.B tripe
+on both of the gateway hosts. Create the directory
+.BR /var/lib/tripe .
+.hP 2.
+On
+.BR alice ,
+make
+.B /var/lib/tripe
+the current directory and generate a Diffie-Hellman group:
+.RS