Misc on SLXH.nl

Nuclear energy in the Netherlands

Sat, 15 Jun 2024 15:01:52 +0200

There is an active debate in The Netherlands about building nuclear energy. This article attempts to provide a summary of the reasons for/against nuclear energy. Please let me know if you feel that facts have been misrepresented or are out of date.

First, let’s state the goal of a nuclear power plant:

A nuclear power plant should provide a reliable and cheap base load with zero CO₂ emissions in an energy independent (of non-EU countries) manner and be completed in 2035.

Discussions usually tend to focus on one of the talking points below, which I have split along the lifecycle of a nuclear power plant. I have purposfully skipped over the CO₂ emissions and safety of a nuclear power plant, as these do not seem to be contentious topics.

Building a nuclear power plant

Who is going to build it?

There are no great options:

Rosatom, which is a Russian state corporation. Consider that energy independence from Russia is a major driver behind the push to alternative energy sources (because of the invasion of Ukraine).
China General Nuclear Power Group (CGN), which is a state-owned Chinese company. Consider, again, that energy independence is one of the stated goals of a nuclear energy.
Korea Electric Power Corporation (KEPCO), a Korean company. They have delivered a large amount of nuclear power pants in Korea and are currently building one in the United Arab Emirates. They have not been involved in building a plant in Europe (yet). KEPCO has been involved in falsifying safety documents.
Framatome/EDF, a French company. Famatome has had quality control issues in the past, and their only operational reactor design (EPR) has been completely redone because it was too complicated. There is currently a single project for building these new reactors in the planning phase.
Start from scratch: Design our own nuclear reactor with the expertise that we still have in the Netherlands. I don’t think anybody considers this a realistic option at this point.

This means that there is no proven design available that we can and want to build. It is possible to build a power plant with either KEPCO or Framatome/EDF if we really want to commit to nuclear energy, but this is going to require faith in the new player and design respectively.

This overview skips over small moduler reactor (SMR) designs, which are not currently operational outside of experiments in China and Russia.

How long is it going to take to build one?

The short answer is that no one knows: Most projects in Europe were built using the complicated EPR design, so any other design could be completed faster.

The following table show the power plants projects in the EU and UK in the last 25 years:

Name	Status	Finished	Builder	Duration	Cost
Civaux	Completed	2002	EDF	16 years	$4.1 billion
Olkiluoto 3	Completed	2023	Areva/TVO	18 years	€11 billion
Mochovce 3/4	Construction	2023-2025	Slovenské elektrárne	22 years	€4.6 billion
Flamanville 3	Construction	2024	EDF	17 years	€8.5 billion
Hinkey Point C	Construction	2029-2031	EDF/CGN	16-18 years	£31–35 billion

Based on this it takes at least 15 years between government authorisation and completion. Additionally, there needs to be some time for government planning, tenders, etc.

Realistically, this means that it takes 20 years to actually construct a nuclear power plant.

Operating a nuclear power plant

Cost vs renewables

While the operating costs of a nuclear power plant are fairly low, the cost of electricity includes construction and decomissioning. Because of this, there is often fixed or guaranteed minimum price for nuclear energy. This used to be the case for offshore wind, but is no longer the case with the latest tenders.

The following graph (source) shows the learning curves for various energy sources:

Note that solar panels and wind both trend down, while nuclear energy trends upwards. This is also reflected in the latest real numbers:

Name	Kind	Year	Price/MWh
Mochovce 3	Nuclear	2023	€61
Borssele IV	Offshore wind	2016	€55

And estimates for 2030:

Kind	Price/MWh
Nuclear	€50-€100
Offshore wind	€30-€40
Onshore wind	€40-€60
Solar panels	€30-€60

Considering we are talking about the base load, energy storage estimates for 2030 should also be taken into account (source):

Kind	Duration	Price/MWh
Battery	1 h	€38-€106
Battery	8 h	€76-€218
Battery	2000 h	>€1000
Pumped hydro	1 h	€18-€28
Pumped hydro	8 h	€24-€42
Pumped hydro	2000 h	>€400
Hydrogen	2000 h	€140

Reports mixing these prices depending on various energy distributions come to similar conclusions:

KIVI estimates that the combination of hydrogen storage and offshore wind comes out to €65-€78 per MWh, equivalent to their estimate for nuclear energy.
Kalavasta & Berenschot come to the conclusion that nuclear energy is slightly (€1-3 billion/year) more expensive in most scenarios.
The latest scenario study comissioned by the government reports that nuclear energy is only really viable in the most optimistic scenarios. The authors also note that increased investments in nuclear energy show a decrease in investements in renewables.

Base load

The concept of a base load comes from our current use of energy in which we have a fairly predictable pattern with a base and peak demand of electricity.

However, this is not necessarily a given: Dynamic energy pricing can shift the use of electricity to better match supply: Considering that overcapacity is inevitable, and that households make up only 29% of electricity consumption, businesses may have a strong incentive to change their usage patterns.

Raw materials

The following image from latest scenario study shows the geopolitical risk for aquiring the raw materials for energy sources:

The risk for nuclear energy is similar to wind, but a lot higher than Solar and battery storage.

It is important to note that we can enrich our own uranium in the Netherlands, so only the procurement of the uranium is an issue.

Waste

We currently do not have solution for storing nuclear waste, but there are a few options:

Store it in clay anywhere in the Netherlands.
Storing it in halite in the north of the Netherlands. This might not be a politically viable option considering the current handling of gas extraction and waste water storage in those regions.

There are no actual plans, which means that the costs are extremely unclear. This also impacts the costs above.

Conclusion

If we look back at the stated goals for a nuclear power plant:

Providing a reliable base load is possible, but might not be needed. Nuclear energy is at least as expensive as renewables combined with storage.
It would provide energy with (close to) zero CO₂ emissions. (I have skipped passed this issue above as it is not really contentious).
Energy independence is possible if we don’t let China or Russia build/operate the power plants. This, however, requires the use of unproven reactor designs.
Having a nuclear reactor operational in 2035 is not feasible. Even if we start today, it is unlikely that the power plant will provide energy in 2040.

Looking at the data raises the following political questions:

Should the government assume the (financial) risk of building a nuclear power plant?
Should the government invest in unproven nuclear energy instead of proven renewables?
Is having a reliable base load needed if we change how and when we use electricity?

NAT64 performance

Wed, 31 Mar 2021 20:07:06 +0200

This post is an update of my previous post about NAT64. That post describes the following setup:

 IPv4 IPv4
Internet ────── Router ────── NAT64
IPv6 │ │ IPv6
└────────── Host
IPv6

This has the following components in the network:

A router that routes IPv6 and routes or NATs IPv4.
A NAT64 server that performs thanslation of IPv4 and IPv6.
A host that only has IPv6 connectivity.

The is to use the NAT64 server both ways: the NAT64 server is used for IPv4 connectivity (looking at you, GitHub), and to reach the IPv6-only hosts over IPv4.

Currently, I still use Tayga for this setup. The main downside of Tayga is it’s (low) performance. This performance is the main reason various hosts in my network still have an IPv4 address. I have also replaced my home router with a PCEngines APU, which should perform much better than the Edgerouter Lite it replaced.

Alternatives

There are various alternatives to Tayga:

OpenBSD’s PF (using af-to).
Jool can perform both (stateful) NAT64 and (stateless) SIIT.
map646 only performs stateless NAT64.

The latter two have been compared against Tayga in this paper, which found the following performance:

Solution	frame/s	Mbps (est.)
Jool	230000	2760
Tayga	120000	1440
map646	60000	720

Note that the throughput for Tayga is significantly greater than I was able to achieve in my previous post (252 Mbps). Additionally, the performance of Jool looks interesting…

Test setup

The following devices are used for testing the performance of Tayga, Jool and PF:

	PCEngines APU	Ryzen 2600X	Ryzen 4650G
CPU	AMD GX-412	AMD Ryzen 5 2600X	AMD Ryzen 5 PRO 4650G
NIC	Intel i211AT	Intel X550-T2	Mellanox ConnectX-3 EN
RAM	2GB DDR3-1333	32GB DDR4-3200	32GB DDR4-3200

Both the PCEngines APU and the Ryzen2600X are used as NAT64 device, while the Ryzen 4650G is used to measure performance.

Fresh installations of OpenBSD 6.8 and Debian Bullseye are used for the tests. No performance tuning is done.

Tests are performed using iPerf3 using a single TCP flow on a single link (in full duplex). The best of three measurements is used as the result.

A few notes:

Note that these numbers do not include overhead from Ethernet, IP or TCP (5-6%).
The network, and the devices, may be somewhat in use.
Only a single full-duplex link is used.

This means that the results below should be taken with a grain of salt.

Different types of NAT

Tayga, Jool and PF work differently:

Tayga and PF (and Jool in NAT64 mode) masquerade the original IP. Tayga can do so using an (optional) dynamic pool, and static mappings.
PF also masquerades the IPv6 address in the NAT46 flow.
Jool (in SIIT mode) does a stateless translation between IPs. This means that the original IP also has to be one from the pool.
Jool (in SIIT mode) translates all IPv4 traffic.

Example translations for NAT64:

	Orig From	Orig To	NAT From	NAT To
Tayga	*	64:ff9b::10.64.0.10	10.64.0.0/24	10.64.0.10
Jool	64:ff9b::10.64.1.10	64:ff9b::10.64.0.10	10.64.1.10	10.64.0.10
PF	*	64:ff9b::10.64.0.10	10.64.0.1	10.64.0.10

Example translations for NAT46:

	Orig From	Orig To	NAT From	NAT To
Tayga	10.64.1.10	10.64.0.10	2001:db8::10.64.1.10	2001:db8::10.64.0.10
Jool	10.64.1.10	10.64.0.10	2001:db8::10.64.1.10	2001:db8::10.64.0.10
PF	*	10.64.0.10	2001:db8::1	2001:db8::10.64.0.10

Results

Performance on the PCEngines APU in Mbps:

	IPv4	IPv6	NAT64	NAT46
Tayga	903	887	199	197
Jool	-	869	805	825
PF	646	488	572	444

Performance on the Ryzen 2600X in Mbps:

	IPv4	IPv6	NAT64	NAT46
Tayga	8478	8361	2971	2807
Jool	-	7819	8193	8091
PF	6292	5006	2354	5440

As a bonus: performance of Jool in a container on the Ryzen 4650G in Mbps:

	IPv4	IPv6	NAT64	NAT46
Jool	15216	14406	14426	10097

This means the performance of the solutions, when compared to the line rate, is as follows:

Solution	Platform	NAT64	NAT46
Tayga	PCEngines APU	21%	21%
Tayga	Ryzen 2600X	31%	29%
PF	PCEngines APU	50%	47%
PF	Ryzen 2600X	25%	58%
Jool	PCEngines APU	85%	88%
Jool	Ryzen 2600X	88%	86%

Conclusion

While Tayga claims that it “can saturate gigabit Ethernet on modest PC hardware”, this is clearly not the case for the ‘modest’ PCEngines APU. However, on a modern desktop CPU all solutions were able to attain performance exceeding 1 Gbps.

The clear winner in terms of performance is Jool, which is able to achieve almost 90% line rate on both platforms.

PGP and DNS

Thu, 22 Dec 2016 17:33:07 +0100

Recently, I looked at all the ways GnuPG can retrieve PGP keys from the internet to see which of these methods are actually useful. This blog post describes a summary of my conclusions.

GnuPG modern (2.1.16) can retrieve keys from the internet using the following mechanisms:

cert: a DNS CERT PGP record as defined in RFC-4398
pka: a DNS CERT IPGP record, also defined in RFC-4398 or a DNS TXT record, depending on the version of GnuPG. This uses an HTTP request to a location defined in the record to retrieve the key.
dane: a DNS OPENPGPKEY record, as defined in RFC-7929.
wkd: via an HTTP GET to a file in the .well-known (RFC-5785) directory. This is experimental and defined in a RFC draft.
keyserver: The common way to retrieve keys via keyservers.

So next to the common way to retrieve keys (which I will not discuss) there are four other mechanisms: two fully relying on DNS, one using a mix of DNS and HTTP(S) and one only using HTTP(S).

For testing the DNS records I used a PowerDNS (4.0.1) server on a DNSSEC signed domain (which I recommend). Note that DNSSEC is not required (not even for the DANE mechanism).

CERT record

The CERT record is quite straightforward: it is a data record in which one can place the base64 encoded information for a public key. This data (which I will call [DATA]) can be generated with:

gpg --export-options export-minimal --export F4DFA1D665C135D6 | base64 -w0

Which results in the same data as what is contained in an ASCII-armored key (except for line endings), which is formatted like:

-----BEGIN PGP PUBLIC KEY BLOCK-----
[DATA]
=[checksum]
-----END PGP PUBLIC KEY BLOCK-----

The DNS record for the identity asdf at slxh.eu looks like any the following:

asdf.slxh.eu. 86400 IN CERT PGP 0 0 [DATA]

Where PGP can be replaced by the number 3. This is required for PowerDNS.

The record is quite straight forward and it works, but only for a single key:

$ gpg2 -v --auto-key-locate=clear,cert,local --locate-keys <address>
...
gpg: auto-key-locate found fingerprint 646B0F089DD5022CF5BA29F9F4DFA1D665C135D6
gpg: automatically retrieved '<address>' via DNS CERT

Pros:

Easy to set up

Cons:

Large record which needs to be transferred over TCP
Not located at a nice place in the DNS
Only retrieves public keys from a single record (but a single record can contain multiple keys)

DANE: OPENPGP record

The dane mechanism works in a similar way to CERT, but it uses a well-defined location. The record looks like (see the CERT section for generating [DATA]):

7a5b775b45836845e91cb23b59ed7ff45d1732c7aa8415952beeb7d2._openpgpkey.slxh.eu 86400 IN OPENPGPKEY [DATA]

The compatibility format can also be generated by gpg2:

gpg --export-options export-dane --export F4DFA1D665C135D6

Which results in:

$ORIGIN _openpgpkey.slxh.eu.
7a5b775b45836845e91cb23b59ed7ff45d1732c7aa8415952beeb7d2 TYPE61 \# 1695 (
98330457e504ee16092b06010401da470f01010740752c0c3aa3bf6841a33076
...
34d3c8c4f8aaa94f53e10daff07633d2a3eea38dbd409d44d9600d9a755a0e
)

Pros:

Easy to setup with software that accepts the output of gpg2
Well defined location

Cons:

Large record which needs to be transferred over TCP
Only retrieves public keys from a single record (but a single record can contain multiple keys)

PKA: Public Key Association

The PKA record in GnuPG 2.1.16 uses the CERT IPGP record to store the fingerprint of the public key and a location where the key can be retrieved. The record has its own location and local part of the email address is hashed. There is also a TXT variant, but GnuPG does not use this for lookups any more.

GnuPG also has options for automatically doing lookups and increasing trust if the fingerprint matches on verification:

--verify-options parameters
...
pka-lookups
Enable PKA lookups to verify sender addresses. Note that PKA is based on DNS, and
so enabling this option may disclose information on when and what signatures are
verified or to whom data is encrypted. This is similar to the "web bug" described
for the --auto-key-retrieve option.
pka-trust-increase
Raise the trust in a signature to full if the signature passes PKA validation.
This option is only meaningful if pka-lookups is set.

GnuPG can also create the DNS record for you:

gpg --export-options export-pka --export F4DFA1D665C135D6

Which shows the required records for zone files:

$ORIGIN _pka.slxh.eu
yyjm39f54qomwmcejnmojaspwa86esqj TYPE37 \# 26 0006 0000 00 14 646B0F089DD5022CF5BA29F9F4DFA1D665C135D6

This output, however, is only for compatibility purposes and does not contain a URL for key retrieval.

The actual format can be generated from this information (I have made a script that does just that). The regular record looks like:

yyjm39f54qomwmcejnmojaspwa86esqj._pka.slxh.eu 3600 IN CERT 6 0 0 FGRrDwid1QIs9bop+fTfodZlwTXW

With a provided URL, in this case https://slxh.eu/keys/pgp/65C135D6, it becomes:

yyjm39f54qomwmcejnmojaspwa86esqj._pka.slxh.eu 3600 IN CERT 6 0 0 FGRrDwid1QIs9bop+fTfodZlwTXWaHR0cHM6Ly9zbHhoLmV1L2tleXMvcGdwLzY1QzEzNUQ2

The 6 may be replaced with IPGP.

The lookup of the fingerprint works. The retrieval of the key, however, does not: instead of using the provided URL it asks the server for a key with a specific URL (a PKS lookup), resulting in a Page Not Found error. This means that gpg does use the server specified in the record but ignores the URL, resulting in gpg claiming there are no keys to be retrieved. A solution to this is to simply use a keyserver (like https://sks-keyservers.net) in the record.

In my opinion this record is most useful for simply verifying the fingerprint, in which case the URL is not needed.

Pros:

Easy to setup with software that accepts the output of gpg2
Can automatically improve trust
Small DNS record
Well defined location

Cons

Does not retrieve the key from the specified location but from a keyserver instead.
Only retrieves the key for a single record

WKD: Web Key Directory

The Web Key Directory mechanism leverages the .well-known directory to store keys. Exporting to this location is relatively easy:

$ gpg2 --with-wkd-hash -k F4DFA1D665C135D6
pub ed25519/F4DFA1D665C135D6 2016-09-23 [SC] [expires: 2018-09-23]
646B0F089DD5022CF5BA29F9F4DFA1D665C135D6
uid [ full ] ...
yyjm39f54qomwmcejnmojaspwa86esqj@slxh.eu
...
$ gpg --export F4DFA1D665C135D6 > yyjm39f54qomwmcejnmojaspwa86esqj

Note that the key cannot be ASCII-armored.

The created file (yyjm39f54qomwmcejnmojaspwa86esqj) then needs to be placed on the webserver for slxh.eu, so that it is accessible at: https://slxh.eu/.well-known/openpgpkey/hu/yyjm39f54qomwmcejnmojaspwa86esqj

The export can contain multiple public keys, but in that case gpg2 will throw an error (No fingerprint) while still importing the keys. Also: only the identities for which a lookup was done are imported.

Pros:

Easy to setup
No cumbersome DNS record
Well defined location

Cons

Only retrieves the identity for which a lookup was done

Conclusion

All of the provided methods have drawbacks. Here is what I recommend:

Primarily use WKD, it is easy to maintain and works the best. Additional security can be provided by using DNSSEC and HTTPS (and DANE/TLSA).
Use OPENPGPKEY over CERT PGP. OPENPGPKEY does everything that CERT PGP does, but better. Security is provided by DNSSEC.
Use PKA only for storing fingerprints. Using it when verifying keys might be useful.

Update 2017-02-16

GnuPG 2.1.18 added a DNS lookup to WKD via a SRV record. The given example is:

_openpgpkey._tcp IN SRV 0 0 0 wkd.foo.org.
IN SRV 0 0 0 wkd.example.net.
IN SRV 0 0 4711 wkd.example.org.

Which would fetch from:

https://wkd.example.org:4711/.well-known/openpgpkey/submission-address

Explained as follows:

Note that the first two SRV records won’t be used because foo.org and example.net do not match example.org. We require that the target host is identical to the domain or be a subdomain of it. This is so that an attacker modifying the SRV records needs to setup a server in a sub-domain of the actual domain and can’t use an arbitrary domain. Whether this is a sufficient requirement is not clear and needs further discussion.

These changes add some flexibility to WKD lookups. The requirement to have the server as subdomain makes sense, but note that when an attacker has full control of the DNS this is circumvented without much hassle.

NAT64 for servers

Wed, 23 Nov 2016 16:06:17 +0100

This post details the setup of the additional steps required to deploy a IPv6-only server bedind NAT64 with Tayga.

This post uses the documentation prefix (2001:db8::/32), replace this with your own prefix. This can be a ULA prefix.

The basis is explained in a post by Luuk Hendriks.

Goal

The goal is to reach an IPv6-only webserver behind a dual stack router. This is done by using NAT64 on a third device to reach the server.

 IPv4 IPv4
Internet ────── Router ────── Tayga
IPv6 │ │ IPv6
└────────── Server
IPv6

In this case, the Router is an Edgerouter Lite and the Tayga and webserver are running on the same physical device in separate LXC containers.

Unbound

The main difference in the setup is that I use Unbound instead of PowerDNS. The configuration is really simple, in /etc/unbound/unbound.conf.d/dns64.conf:

server:
module-config: "dns64 validator iterator"
dns64-prefix: 2001:db8:64::/96

Tayga

For the two-way NAT, the Tayga configuration requires static-mappings:

# Main config
tun-device nat64
prefix 2001:db8:64::/96
ipv4-addr 10.64.0.1
dynamic-pool 10.64.0.0/24
data-dir /var/spool/tayga
# Static mappings
map 10.64.0.10 2001:db8::10 # Server 1
map 10.64.0.11 2001:db8::11 # Server 2

I have used a subnet (2001:db8:64::/96) above as prefix. This allow access to local (RFC1918) IPv4 addresses through NAT64. If this is not needed, use the Well-Known Prefix: 64:ff9b::/96.

The mapping is simple: create an IPv4 address inside the dynamic pool and map that to the IPv6 address that needs to be reached.

Route

In a regular setup, the IPv4 range is only required internally on the host running Tayga. For this setup, however, the 10.64.0.0/24 range needs to be routed to the device running Tayga.

Just like the linked post, I use an Edgerouter. The following route needs to be added:

set protocols static route 10.64.0.0/24 next-hop 10.0.0.64 distance 1

Where 10.0.0.64 is the IPv4 address of the device running Tayga.

After this route is setup, it should be possible to ping the devices mapped in Tayga.

Port forwards

If the mappings work, it should now be possible to forward ports to the mapped addresses. For a webserver this would be:

edit port-forward rule 10
set description "HTTP(S)"
set forward-to address 10.64.0.10
set original-port 80,443
set protocol tcp

If everything went well the webserver should now be reachable from the IPv4-WAN address, while only having an IPv6 address.

Final notes

I have not noticed any drawbacks to this setup except for performance. The results of some measurements from a computer in my network to the server show that the NAT transition has a performance of about 250 Mbps.

From	To	(Mbps)
	IPv4	IPv6
IPv4	927	252
IPv6	199	918

This means that the main bottleneck is the performance of Tayga, though this only matters with internet connections faster than 250 Mbps.

X.509 IPsec on EdgeOS

Thu, 31 Dec 2015 13:13:50 +0100

Configuring X.509 based IPsec on an Edgerouter running EdgeOS.

Preparation

Create a directory in /config for persistent storage of the certificates. Eg:

mkdir /config/ipsec
cd /config/ipsec

Generation of Certificates

For IPsec to work reliably, you need three certificate files:

CA-certificate: ca.crt, obtain this from your CA.
Server certificate: server.crt
Server private key: server.key

Running a CA is outside of the scope of this document, though a script (/usr/lib/ssl/misc/CA.sh) is provided to make it very easy. There are other blog posts documenting this. Personally, I prefer to use the openssl commands directly. I also advise to run the following as root (sudo -i).

First, generate a certificate signing request (CSR) for the CA to sign, replace the subject with your own values:

openssl req -new -newkey 4096 -nodes -out server.csr \
-keyout server.pem \
-subj "/C=NL/ST=/L=/O=SLXH/CN=ipsec.slxh.nl"

This private key needs to be converted to a RSA private key for the IPsec daemon on EdgeOS:

openssl rsa -in server.pem -out server.key

Change the permissions on the files:

chmod u=r,go= server.pem server.key
chown root: server.pem server.key

This CSR can now be signed by your CA. After you get the signed certificate, place in next to the private keys.

IPsec on EdgeOS

Follow the instructions provided by Ubiquiti or the ones found on their forum, with the following exceptions:

set vpn l2tp remote-access ipsec-settings authentication mode x509
set vpn l2tp remote-access ipsec-settings authentication x509 ca-cert-file /config/ipsec/ca.crt
set vpn l2tp remote-access ipsec-settings authentication x509 server-cert-file /config/ipsec/server.crt
set vpn l2tp remote-access ipsec-settings authentication x509 server-key-file /config/ipsec/server.key

Adding a certificate revocation list (CRL) is optional, but advised:

set vpn l2tp remote-access ipsec-settings authentication x509 crl-file /config/ipsec/ca.crl

Commit and save:

commit
save

Firewall

Again, follow the instructions provided by Ubiquiti. It can also be configured in the CLI (check the rule numbers first):

edit firewall name WAN_LOCAL rule 23
set action accept
set description "L2TP/IPsec"
set destination port isakmp,l2f,4500
set protocol udp
exit
edit firewall name WAN_LOCAL rule 24
set action accept
set description "ESP (IPsec)"
set protocol esp
commit
save

IPsec should now be working.

Misc on SLXH.nl

Nuclear energy in the Netherlands

Building a nuclear power plant

Who is going to build it?

How long is it going to take to build one?

Operating a nuclear power plant

Cost vs renewables

Base load

Raw materials

Waste

Conclusion

Other talking points and questions

NAT64 performance

Alternatives

Test setup

Different types of NAT

Results

Conclusion

PGP and DNS

CERT record

DANE: OPENPGP record

PKA: Public Key Association

WKD: Web Key Directory

Conclusion

Update 2017-02-16

NAT64 for servers

Goal

Unbound

Tayga

Route

Port forwards

Final notes

X.509 IPsec on EdgeOS

Preparation

Generation of Certificates

IPsec on EdgeOS

Firewall