Durch die Arbeit am Freifunk Babelnetz für die Zukunft hab ich genügend Erfahrungen gesammelt, um folgende Experimente zu wagen.

Kein IPv4 mehr auf virtuelle Maschinen zu verwenden. Da die Welt damit leider noch nicht klarkommt mit den Workaround für IPv4, dass man auf der Hardware statt IPv4 Routing und Firewalls einfach NAT64 zu verwendet. Hierzu wurde die Kernelmodule jool und jool_siit verwendet. Dazu muss man unterscheiden, ob es sich dabei um stateless oder stateful handelt.

Stateless

Der einfachste Weg ist stateless, hier wird der eingehende IPv4-Traffic direkt zu IPv6 Traffic verwandelt, ohne dabei in tiefere Protokolle wie TCP bzw. UDP nach den Ports zu schauen. Dadurch ist es nicht nötig einen state wie beim normalen NAT zu managen (mit Fragen, wie lange muss ich den TCP port offen halten, bis ich ihn für ein anderen Geräte oder Verbindung wiederverwenden kann).

Daher wird stateless NAT64 oft auch als Stateless IP/ICMP Translation kurz SIIT bezeichnet.

My example configuration (Initd/system from here):

/etc/jool/jool_siit.conf:

{
	"instance": "default",
	"framework": "iptables",

	"global": {
		"pool6": "64:ff9b::/96"
	},
	"eamt": [{
		"comment": "vm x",
		"ipv6 prefix": "2a01:4f8:150:1337::f00/128",
		"ipv4 prefix": "88.133.7.12/32"
	}, {
		"comment": "vm y",
		"ipv6 prefix": "2a01:4f8:150:1337::f01/128",
		"ipv4 prefix": "88.133.7.42/32"
	}]
}

Firewall:

# v6 to v4
ip6tables -t mangle -A PREROUTING -d 64:ff9b::/96  -j JOOL_SIIT
# v4 to v6
iptables  -t mangle -A PREROUTING -d 88.133.7.0/24 -j JOOL_SIIT

Stateful

Die Stateful kennen wir bereits von unseren großen Providern im Mobilfunknetz, wenn Sie neu sind und kein Lust habe zusätzlich ein CGN (Carrier Greate NAT) (siehe Telekom US vor 5 Jahren oder China 2018).

Unsere Smartphones erkennen dies und bauen dann wiederum ein fake-Interface um NAT46 zu machen, dies wird clat genannt. Das passende Prefix wird mittels eine DNS AAAA-Entry Anfrage von ipv4only.arpa erkannt (siehe RFC 6147). Dieses wird nur benötigt, wenn man unbedingt IPv4 benötigt (ala Skype).

My example configuration (Initd/system from here):

/etc/jool/jool.conf:

{
	"instance": "default",
	"framework": "iptables",

	"global": {
		"pool6": "64:ff9b::/96"
	},
	"pool4": [{
		"protocol": "ICMP", "prefix": "88.133.8.0/24"
	}, {
		"protocol": "TCP",  "prefix": "88.133.8.0/24", "port range": "1-62000"
	}, {
		"protocol": "UDP",  "prefix": "88.133.8.0/24", "port range": "1-62000"
	}],
	"bib": [{
		"comment": "DNS : "vm a",
		"protocol": "UDP", "ipv4 address": "88.133.8.2#53",
		"ipv6 address": "2a01:4f8:150:1337::d53#53"
	}, {
		"comment": "HTTP : "vm b",
		"protocol": "TCP", "ipv4 address": "88.133.8.2#80",
		"ipv6 address": "2a01:4f8:150:1337::3eb#80"
	}, {
		"comment": "HTTPS : "vm b",
		"protocol": "TCP", "ipv4 address": "88.133.8.2#443",
		"ipv6 address": "2a01:4f8:150:1337::3eb#443"
	}]
}

Firewall:

# v6 to v4 (with -s /src to be save from others if some route issues happen)
ip6tables -t mangle -A PREROUTING -s 2a01:4f8:150:1337::/64 -d 64:ff9b::/96 -j JOOL
# v4 to v6
iptables  -t mangle -A PREROUTING -d 88.133.8.0/24 -p tcp  -j JOOL
iptables  -t mangle -A PREROUTING -d 88.133.8.0/24 -p udp  -j JOOL
iptables  -t mangle -A PREROUTING -d 88.133.8.0/24 -p icmp -j JOOL

Mögliche Probleme

Das größte Problem ist wohl DNS, da die MTU zwischen Hardware und innerhalb der Hardware gleich bleibt und ignoriert werden kann (sobald man zusätzlich mit Tunneln arbeitet sollte man dort ebenfalls eine Auge drauf werfen).

Man benötigt eine DNS64-Server (RFC 6147) falls die eigenen IPv6only Maschinen IPv4only-Dienste (wie github.com oder hub.docker.con) erreichen möchten. Hierzu gibt es von den Internet-Giganten bereits welche für die well-known 64:ff9b::/96 Google, Cloudflare.

Weitere Probleme können entstehen, dass möglicherweise DNSSec gebrochen wird oder eine Traffic-Validierung wie bei der E-Mail Spamerkennung entstehen könnten.

Ein NAT46/clat wäre zwar die Lösung für Rechenzentren mit einem großen Netz dazwischen, doch im kleinen Hardware zu virtuelle Maschine eher witzlos und man kann dann eher wieder IPv4 nativ verwenden.

Fazit

• Geringerer Verwaltungsaufwand

Auf Seite der Hardware bleibt dieser zwar erhalten, indem statt routing nun die bin gepflegt werden muss. Doch auf Seite der virtuellen Maschinen bleibt es eben bei der Konfiguration der IPv6-Adresse

• Flexibilität

Wenn man die IPv4 Adresse in eine globalen IPv6 src-adresss verwandelt kann man so die IPv4 Adresse an einen weit entfernten Ort routen, ohne dafür extra vpn-tunnel oder spezielle routing Einträge zu erstellen. (Dafür muss man nur ein /96 für das SIIT benutzen anstelle der well-known 64:ff9b::/96)

• sparen von IPv4 Adressen

Falls man auf der Hardware etwas mehr Rechenkapazität benutzt, kann man anstelle von SIIT auch stateful NAT64 verwenden und dabei mittels statischen Einträgen einzelne Port einer IPv4-Adresse zu verschiedene Maschinen PATten. (Ja, genauso die beim normalen IPv4 NAT)