From 6cfd85708172213dd335f4ad3e00fe4976e44ce9 Mon Sep 17 00:00:00 2001 From: Christoph Emsenhuber Date: Tue, 16 Jun 2026 19:37:57 +0200 Subject: [PATCH] =?UTF-8?q?Call-Quality=20=F0=9F=94=8D=20IPv6-Stand:=20Liw?= =?UTF-8?q?est=20kein=20natives=20v6,=206to4=20am=20LAN=20untauglich?= MIME-Version: 1.0 Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit - Liwest bietet kein natives IPv6 (techn. Support bestätigt). - Christophs 6to4-Versuch am Mac mini/LAN NICHT nutzbar (stf0 down, keine globale v6, kein v6-Route/Internet) → kein funktionierendes v6 auf Christophs Seite; ap1/TP4 bleibt v4-only. - 6to4 = legacy/relay/hohe Latenz → keine Basis für Echtzeit-Medien; saubere Alt bei Bedarf = 6in4-Tunnelbroker (HE). - Geli-seitiger CGNAT-Bypass (ihr natives v6, Telegram-Reflector-Leg) bleibt davon unberührt — der billige Hebel braucht Christoph-v6 nicht. Co-Authored-By: Claude Opus 4.8 --- docs/call-quality-diagnosis.md | 11 ++++++++--- 1 file changed, 8 insertions(+), 3 deletions(-) diff --git a/docs/call-quality-diagnosis.md b/docs/call-quality-diagnosis.md index 4287cc5..42ba426 100644 --- a/docs/call-quality-diagnosis.md +++ b/docs/call-quality-diagnosis.md @@ -68,8 +68,12 @@ lässt die **Congestion-Control kollabieren**. Roaming/Handover ist additiver Ne **IPv4 = CGNAT bestätigt:** WAN-IP `100.72.62.31` ∈ **100.64.0.0/10** (RFC 6598), außen `94.154.138.11`. **IPv6 = nativ öffentlich:** Prefix `2a0e:7a02:31c:3000::/56`, **kein CGNAT auf v6** (Prefix rotiert ~30 h → DDNS nötig). DNS = Quad9 (`2620:fe::fe:11`) + ISP-EDNS0 (`37.60.7.2`). -- **Christophs Anschluss (Check 2026-06-16):** **kein Client-IPv6** (Mac mini ohne globale v6, `curl -6` scheitert) → - ap1/TP4 ist **v4-only** (kein DHCPv6-PD); Liwest-v6 am FB unbestätigt. **IPv6-Pfad blockiert auf Christophs Seite.** +- **Christophs Anschluss (Stand 2026-06-16):** **Liwest bietet KEIN natives IPv6** (vom techn. Support bestätigt). + Christoph hat ersatzweise **IPv6 via 6to4** eingerichtet — **aber am Mac mini/LAN NICHT nutzbar** (verifiziert: + `stf0` down/`flags=0`, keine globale v6, kein v6-Default-Route, `curl -6`/`ping6` scheitern). ap1/TP4 ist **v4-only** + (kein DHCPv6-PD). **Fazit: kein funktionierendes IPv6 auf Christophs Seite.** ⚠️ **6to4 ist ohnehin + relay-abhängig/legacy/hohe Latenz → KEINE solide Basis für Echtzeit-Medien.** Saubere Alternative bei Bedarf: + **6in4-Tunnelbroker** (z. B. Hurricane Electric, geroutetes /48, stabil) statt 6to4. --- @@ -175,7 +179,8 @@ auf dieser Senderichtung**, nicht reiner Random-Loss. + Peering nach AT schildern. CGNAT-Opt-out/öffentliche v4 nur nötig, falls v6-Weg nicht tragfähig. - **(strukturell, TP10 — NUR Notnagel, kein Default):** eigener Medienpfad (WG-über-v6 FB↔ap1, dann self-hosted Jitsi/SIP) **erst erwägen, wenn die Messung „Transit-Rohr" sagt** — also wenn auch v6 staut und der ISP nicht - hilft. Für den CGNAT-Fall **nicht nötig** (Gelis vorhandenes v6 reicht). Bräuchte dann Christoph-v6 (ap1 IPv6-PD) + DDNS für Gelis rotierendes /56. + hilft. Für den CGNAT-Fall **nicht nötig** (Gelis vorhandenes v6 reicht). ⚠️ **Christoph-seitig v6 blockiert** + (Liwest kein v6; 6to4 untauglich für RT-Medien) → bräuchte erst **6in4-Tunnelbroker (HE)** + DDNS für Gelis rotierendes /56. ---