Pick some typo, language and formatting nits

* It's supported by hardware routers.

## Why IPsec?

## Problems with GRE

* GRE is defined directly on top of IP.

* At least one static IPv4 on at least one endpoint unless you hate yourself.

## Kernel configuration

```conf

options IPSEC #IP security

device crypto

## Userland configuration

Install the racoon daemon. It's included in the [security/ipsec-tools](http://www.freshports.org/security/ipsec-tools/) port.

```conf

path pre_shared_key "/usr/local/etc/racoon/psk";

path certificate "/usr/local/etc/racoon/certs";

# Key generation and distribution

## Using pre-generated keys

## Generating your own keys

If you don't want to use a pre-generated key, refer to [isakmpd(8)](http://man.openbsd.org/isakmpd.8#X.509_AUTHENTICATION).

## Distributing keys

# IPSec Setup

Change the value of the `isakmpd_flags` variable in [`/etc/rc.conf.local`](http://man.openbsd.org/rc.conf.local.8) to `"-K"`, or add the `"-K"` flag if you already have flags in there.

In order to maintain backward compatibility, a number of methods have been used to be able to reach IPv4 space from IPv6. NAT-PT was deprecated, so this mostly leaves us with NAT64.

NAT64 simply consists in embedding IPv4 addresses after an IPv6 prefix, and mapping the whole prefix to the whole of IPv4 space. Thanksfully, that's easily doable because we have 128-bit wide addresses in IPv6. As the name implies, we however have to perform Dynamic-NAT on the IPv4 side to squeeze all the incoming v6 space in v4 addresses (though it should be possible to run 1-1 mappings, but in that case, why not get a v4 address and NAT to it to begin with?)

As such, any address that can only resolve to IPv4 will now also resolve to an address corresponding to it through the NAT64 prefix.

## Routing to Internet and DN42

### With NPT

A first approach is to use NPT: Network Prefix Translation. Yes, this sounds a lot like NAT, but fear not: it does not have most of its problems as it is fully stateless. Initially, the purpose of NPT was to allow multi-homing without an ASN: how can you be reachable through several prefixes allocated by different ISPs ? The IPv6-way of doing it would be to assign multiple addresses from the multiple prefixes to all your nodes, but isn't that just too complicated ?

* *.delegation-servers.dn42 and *.master.delegation-servers.dn42 are a normal master-slave setup for providing the few official infrastructural zones.

## *.recursive-servers.dn42

## *.delegation-servers.dn42

## *.master.delegation-servers.dn42

These instances do not serve any clients. They poll the registry regularly and rebuild and resign (DNSSEC) the zones as needed. If any zone changes, all *.delegation-servers.dn42 instances are notified ([RFC1996](https://tools.ietf.org/html/rfc1996)) which then load the new zone data over AXFR ([RFC5936](https://tools.ietf.org/html/rfc5936)). The pool of masters is intentionally kept very small because of its much higher coordination needs and also the lacking support of a multi-master mode in many authoritative server implementations. The masters are only reachable over dedicated IPv6 assignments which are set up in a way that any master operator can hijack the address of a problematic master without having to wait for its operator to fix something.

Also, gatuno provides another simple [dns checker for all the top level domains](http://gatuno.dn42/dns/) in the registry. If you want to check whatever a domain is resolving or not, this tool may be useful. The tool gets in sync with the registry every 12 hours. You can schedule checks for any domain.

# DNSSEC

The set of valid KSKs can be found in the registry.

multiple services from *.delegation-servers.dn42 for redundancy.

## Dnssec

This is an example for dn42. and (fake) ds-rdata of 1 2 3 456

```conf

name: "d.f.ip6.arpa"

stub-addr: fd42:4242:2601:ac53::1

stub-addr: 172.20.129.1

```