# 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: . **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)