nixos-config/docs/session-2026-09-12-ipv6-plattform.md

# Session 12.09.2026: IPv6-Mobilfunkzugang und Plattformplanung

## Übergabe für die nächste Session

Auftraggeber und Agent arbeiteten auf **tnix**. Ausgangspunkt war die
vermeintliche Blockade des eingehenden IPv6-Verkehrs durch Telekom oder
Nokia. Diese Diagnose wurde widerlegt. Ein öffentlicher HTTPS-Webserver
läuft jetzt auf tnix: <https://ipv6-test.0ff.space/>.

**Nächster angeforderter Schritt:** Traefik und eine statische Testwebsite
auf pinix über diesen direkten IPv6-Zugang bereitstellen. Der separate
[Intent](intent/pinix-ipv6-traefik-webserver.md) beschreibt die Umsetzung.
In dieser abschließenden Dokumentationsrunde wurde kein neuer Auftrag im
Intent Board gestartet und kein weiterer Dienst umgezogen.

Technische Details, Adressen, Rückbau und Messungen stehen in
[IPv6-Webtest auf tnix](ipv6-test-tnix.md). Die hier genannten Live-Zustände
wurden während der Session geprüft, zuletzt für HTTPS um 08:47 UTC; vor
weiterer Aktivierung erneut prüfen.

## Gesicherte Ergebnisse

- Aufbau: Telekom-SIM mit fester IPv6-/64-Option, APN `festip.telekom`,
  Nokia 6300 4G, USB-Tethering zum GL.iNet Mango GL-MT300N-V2, Ethernet zu tnix.
- Öffentliche Mango-Adresse beim Test:
  `2a01:598:ec1e:ce00:94dd:42ff:fe9a:627f`.
- Zentrale Fehlerquelle: `usb0` wurde zuerst von der Firewallzone `wan`
  behandelt, die noch IPv4 und IPv6 umfasste. Die nachgelagerte Zone `wan6`
  und dortige Freigaben/Zähler wurden für diesen Verkehr nicht erreicht.
  Ihr Null-Zähler bewies deshalb keine vorgeschaltete Netzblockade.
- Gegenprobe vor Änderungen: 3/3 Ping-Antworten; TCP 8080 traf Mangos
  Freigaberegel, aber ohne Listener; TCP 80 erhöhte `drop_from_wan` um vier.
- Ein temporärer Node-Webserver auf tnix lieferte über diesen Weg HTTP 200.
  Der Nutzer bestätigte den Abruf auf dem Handy: „sehe hello von tnix“.
- Danach nginx als NixOS-Dienst mit eigener statischer Seite, IPv6-Listenern,
  Let's-Encrypt-HTTP-01 und automatischer Erneuerung aktiviert.
- HTTPS extern mit normaler Zertifikatsprüfung: HTTP/2 200. Zertifikat von
  Let's Encrypt YE1, gültig bis 11.12.2026. HTTP auf 80/8080 → HTTPS.
- Cloudflare-AAAA-Eintrag für `ipv6-test.0ff.space`, DNS-only, TTL 120.
  Cloudflare dient hier nur als DNS, nicht als Proxy. blunix ist nicht im
  HTTP-Datenpfad. Der Nutzer hatte die DNS-Einrichtung ausdrücklich übertragen.
- Mango-Regeln sind jetzt in UCI gespeichert; `wan` ist IPv4-only,
  die bisherigen IPv6-Kontrollregeln liegen in `wan6`. Gezielt TCP
  80/443/8080 zu tnix, mit SNAT für den korrekten Rückweg.

## Betrieb und noch offene technische Fragen

**Überholt am 12.09.2026, später am Tag:** tnix hängt nicht mehr am
iPhone-Hotspot, sondern am Mango-WLAN `idea`. Der Absatz unten beschreibt
den Stand davor. Details: [Mango als Uplink](ipv6-uplink-tnix-mango.md).

tnix nutzt weiterhin den **iPhone-Hotspot als Default-Internetzugang**.
Der gewünschte vollständige Wechsel zum Mango wurde noch nicht durchgeführt.
Die Verbindung zum Mango läuft parallel über `enp0s31f6` mit `nogateway`.
Das Handy kann die öffentliche Testseite trotzdem unabhängig über Mobilfunk
abrufen, während es tnix den Hotspot bereitstellt.

Native IPv4-Verbindungen vom Mango schlugen fehl. Telekom-DNS und Mangos
lokaler DNS liefern aber DNS64-Antworten aus `64:ff9b::/96`. HTTPS zu
`one.one.one.one`, explizit über `[64:ff9b::101:101]`, funktionierte.
**NAT64 ist nachgewiesen; vollständiger DNS64/CLAT-Clientbetrieb noch nicht.**
tnix verwendet bisher Tailscale-DNS. NAT64 macht die Dienste nicht für
eingehende IPv4-only-Besucher erreichbar.

Beim ersten NixOS-Switch entfernte der alte dhcpcd-Prozess seine frühere
SLAAC-Adresse nach deren statischer Einrichtung. Dadurch scheiterte der
erste ACME-Auftrag. Neustart von `network-addresses-enp0s31f6` behob dies;
die erneute Ausstellung gelang. Tailscale war nicht die Warteursache.

Build, `nix flake check path:. --no-build`, Dry-Aktivierung und Aktivierung
erfolgreich; nginx und Erneuerungstimer aktiviert, zuletzt keine fehlerhaften
systemd-Units. Kein vollständiger Reboot-/USB-Reconnect-/VM-Boot-Test.
Aktivierte Generation:
`/nix/store/dy6vnjz0zqfpgqkgv53ih295zkidfrg3-nixos-system-tnix-26.11.20260902.3ed67ec`.
Der vorhandene `nixos-rebuild --store-path`-Wrapper scheiterte an NIX_PATH;
verwendet wurden das gebaute System, `nix-env` für das Systemprofil und
`switch-to-configuration switch`.

Die öffentliche SLAAC-Interface-ID hängt noch vom USB-MAC-Suffix ab.
Präfix- und Suffixstabilität beim Reconnect sind unbewiesen. Statische
öffentliche Interface-ID oder DNS-Nachführung sind noch zu entscheiden.
Ein altes Consumer-Präfix liegt zusätzlich auf Mango `usb0`.

## Nutzerpräferenzen und Architekturgespräch

Der Nutzer bevorzugt ausdrücklich **IPv6-only als öffentlichen Zugang**, um
externe Abhängigkeiten zu reduzieren. Er bevorzugt konsequent lokalen
Betrieb und nimmt Verbindungsabbrüche in Kauf. Langfristiges Ziel ist die
Plattform auf pinix, einschließlich Traefik, Headscale, LLDAP/Dex, Prosody
und GoToSocial. Das ist die Zielrichtung, keine bereits erfolgte Migration.

Gemeinsam geklärt:

- Öffentlicher IPv6-Zugang erfordert nicht das Abschalten sämtlicher interner
  IPv4-Verbindungen. Traefik kann IPv6 entgegennehmen und lokal über IPv4
  mit Anwendungen sprechen; auch VPN-Adressen können zunächst bleiben.
- NAT66 im Mango-Test übersetzt IPv6-Adressen untereinander. Telekom-NAT64
  ermöglicht ausgehenden Verkehr zu IPv4-Zielen. CLAT kann für reine IPv4-
  Anwendungen nötig sein. Diese Mechanismen sind nicht austauschbar.
- IPv4-only-Besucher erreichen einen IPv6-only-Eingang nicht. DNS/BIND/
  Namecheap können keine fehlende IPv4-Verbindung herstellen. VPS/Proxy
  oder ein anderer Anschluss wären mögliche zusätzliche Eingänge, wurden
  aber nicht als Ziel gewählt. Cloudflare-Proxy wurde nur diskutiert.
- Prosody unterstützt IPv6. Grenzen betreffen auch fremde XMPP-Server,
  ActivityPub-Föderation, Webhooks und die Erreichbarkeit von Headscale.
  Ein Kontakt mit IPv4-Handy kann über seinen IPv6-fähigen XMPP-Anbieter
  kommunizieren. Eine IPv6-Webseite allein beweist keine vollständige Föderation.
- Headscale hängt heute an Traefik, Dex/LLDAP und AdGuard auf blunix.
  Für den späteren Gesamtumzug wurde Netzwerk → Traefik → interner DNS →
  LLDAP/Dex → Headscale als sinnvolle Reihenfolge vorgeschlagen.

## DNS, Zertifikate und radikalere Varianten: noch nicht entschieden

BIND könnte autoritativen DNS und DNS-01-Prüfungen via RFC2136/TSIG
übernehmen. Das Wildcard-Zertifikat stellt weiterhin eine CA wie Let's
Encrypt aus. Als Zwischenstufe wurde die Delegation von
`_acme-challenge.0ff.space` diskutiert. Interner AdGuard-DNS, öffentlicher
autoritativer DNS und Zertifikatsausstellung sind getrennte Aufgaben.

Cloudflare-Abschied ist ein Interesse, noch keine umgesetzte oder abschließend
gewählte DNS-Architektur. Nur lokal über IPv6 erreichbarer autoritativer DNS
schließt auch Resolver ohne IPv6 aus; ein IPv6-fähiger Besucher allein genügt
dann nicht. Externe sekundäre Nameserver wären ein möglicher Kompromiss,
wurden aber nicht beauftragt.

Für `0ff.space` im normalen öffentlichen DNS bleibt ein Registrar nötig;
Namecheap ist austauschbar, die Registrierungsfunktion nicht lokal ersetzbar.
Diskutierte Alternativen ohne registrierte Domain:

- Direkte IPv6-URLs; öffentliche IP-Zertifikate sind bei Let's Encrypt
  verfügbar, aber kurzlebig und weiter CA-abhängig. Die Identität hängt
  dann stärker an der Anschlussadresse.
- Eigenes WireGuard-Netz mit lokalen Namen/DNS und eigener CA. Teilnehmende
  Geräte benötigen Einrichtung; Headscale wäre dafür nicht zwingend nötig.
- Experimentelles Yggdrasil mit schlüsselabgeleiteten, innerhalb des Netzes
  ortsunabhängigen IPv6-Adressen. Verbindungen/Peers bleiben erforderlich;
  das ist keine garantierte Erreichbarkeit ohne physische Verbindung.
- Prosody-Alpha-Modul `mod_s2s_v6mesh` für `.v6.alt` ohne öffentliche DNS-
  Infrastruktur. Beide Server benötigen das Modul; Clients brauchen manuelle
  Serveradressen. Das TLS-Vertrauensmodell muss gesondert abgesichert werden.

**Keine dieser Alternativen wurde zur Implementierung ausgewählt.** Die
Frage „eigener eingerichteter Personenkreis oder Fremde ohne Einrichtung?“
blieb offen. Bestehende GoToSocial-/XMPP-Identitäten nicht vorschnell ändern
oder die Domain auslaufen lassen; Identitätswechsel ist mehr als ein Ausfall.

## Dateien und Arbeitsstand

Implementierung: `hosts/tnix/localServices/ipv6-web-test.nix`,
`ipv6-web-test.html`, Import in `default.nix`,
`scripts/configure-mango-ipv6-web.sh`. Dokumentation: `docs/roadmap.md`,
`docs/ipv6-test-tnix.md`, überholter Support-Entwurf ausdrücklich markiert.
Router-Backups und Rückbau stehen im technischen Bericht.

Die Session-Änderungen sind **noch nicht committed**. Änderungen an
`flake.nix` und `flake.lock` lagen bereits vor Beginn vor (separater Codex-
Input/Overlay); nicht dieser Arbeit zuschreiben oder zurücksetzen. Der
Systembuild verwendete den vorhandenen Worktree einschließlich dieser
Änderungen. `memory/` wurde nicht geändert.

## Quellen aus dem Architekturgespräch

- [Telekom: feste Mobilfunk-IP und NAT64](https://geschaeftskunden.telekom.de/business/hilfe-und-service/geraete-konfigurationen/internet-festnetz/feste-ip-adresse-einrichten)
- [NAT64/464XLAT-Leitlinien](https://www.rfc-editor.org/rfc/rfc8683.html)
- [Prosody IPv6](https://prosody.im/doc/ipv6), [DNS](https://prosody.im/doc/dns)
- [Let's Encrypt: Challenges](https://letsencrypt.org/docs/challenge-types/), [IP-Zertifikate](https://letsencrypt.org/2026/01/15/6day-and-ip-general-availability)
- [lego RFC2136](https://go-acme.github.io/lego/dns/rfc2136/index.html)
- [DNS-Transport-Leitlinien](https://www.rfc-editor.org/rfc/rfc10001.html)
- [Yggdrasil](https://yggdrasil-network.github.io/about.html), [Prosody v6mesh](https://modules.prosody.im/mod_s2s_v6mesh.html)