Network2/Design

IPv6 Configuration

Peers:

Your job is to be an IPv6 node. Consequently, when you bring up your interfaces,

1. You might discover an IPv6 router advertising on one of your links.
   • (See sysctl net.ipv6.conf.all.accept_ra and related variables.)
2. You might try out dhcp6c.
3. You might have some kind of IPv4 connectivity. If so, connect to the Internet or to other internetworks of your choice.
   • (miredo and openvpn seem particularly easy to configure and hence to experiment with...)
4. Use dnshash to add guessable link-local addresses to all your interfaces.

Servers:

Your job is to be an IPv6 router and a DNS server. One of several situations might obtain:

1. You might discover an IPv6 router advertising one or more IPv6 prefixes on your outbound link(s).
2. You might have some kind of IPv4 connectivity. If so, connect to the Internet or to other internetworks of your choice.
3. You might be under a tree. If so, generate a Unique Local Address prefix.
4. (Use dnshash to add guessable link-local addresses to all your links?)

When done, use radvd or dhcp6d to share addresses.

DNS Configuration

One of the server's most important jobs is to get itself on appropriate internetworks so that it can dynamically map stable (DNS) names to unstable names (IPv6 addresses) for itself and its peers.

Discovery:

Peers need help locating one or more DNS servers. See RFC 4339 for available mechanisms; pay particular attention to RDNSS discovery.

Update

Here are two approaches for solving the update problem, based on how peers might want to communicate with DNS servers:

1. Use a DNS UPDATE client like ipcheck or ddclient with shared keys with a DNS server like BIND.
2. Run a bespoke control protocol over an existing secure tunnel, e.g. something based on with XML-RPC over HTTPS + client certs or on access to a restricted shell over SSH.

(NB: In order to perform this update, it will usually have been necessary for the peer to have been cryptographically introduced to the server.)