Zusammenfassung

  • RIPE NCC zufolge unterstützten 86 Prozent der Clients das IPv6-only-Konferenznetz mit NAT64 für IPv4-Verkehr.
  • Im Hauptraum schaltete das Team drei AP-Funkmodule ab und sechs zusätzliche Access Points ein; kleinere Probleme blieben.

Drei Funkmodule aus, sechs zusätzliche Access Points an. Diese Änderung im Hauptraum steht im Abschlussbericht von RIPE 93 direkt neben einer Zahl, die viel eleganter klingt: 86 Prozent der Clients unterstützten das IPv6-only-Netz. Die Prozentzahl beschreibt die Fähigkeit der Geräte; die Funkänderung dokumentiert den Betriebsaufwand vor Ort.

Das Konferenznetz in Sofia lief über fünf Etagen. Die technische Leitung berichtete, dass die interne Verkabelung ordnungsgemäß funktionierte. IPv6-only-Clients erhielten ausschließlich eine IPv6-Adresse; NAT64 übersetzte den IPv4-Verkehr. Die 86 Prozent zeigen, dass ein großer Teil der Geräte diesen Pfad nutzen konnte.

Der gemeldete Fehler lag vor dem Übersetzer. Einige Access Points ließen weiterhin Solicited-Node-Multicast für IPv6 Neighbor Discovery fallen. Damit ermittelt ein Gerät die Link-Layer-Adresse eines Nachbarn. RFC 4861 beschreibt den Ablauf: Der Absender schickt eine Neighbor Solicitation an die Solicited-Node-Multicast-Adresse des Ziels und wartet auf eine Antwort. Nach diesem Austausch kann der Client Verkehr an NAT64 zur Übersetzung weiterleiten.

Das Team hatte denselben oder einen ähnlichen Fehler bei jüngsten RIPE-Meetings bereits gesehen. Ein Gerätehersteller hatte eine Behebung gemeldet; in Amsterdam traten die Symptome laut RIPE aber weiter bei Access Points derselben Generation auf. Das Team setzte einen NDP fixer auf der Firewall ein. Menno Schepers sagte, das habe beim verlorenen Multicast geholfen. Im Hauptraum deaktivierte das Team dann die Funkmodule dreier AP und schaltete sechs weitere Geräte ein. Im Nebenraum und im Kaffeebereich trat dasselbe Muster nicht auf. Einige kleinere Probleme blieben dennoch bestehen.

Das ist ein konkreter Technikbericht; für die Servicequalität braucht es eine zweite Zahlenreihe. „86 Prozent unterstützen das“ beschreibt die Gerätefähigkeit. Schepers sagte, das WLAN habe im Hauptraum „zumindest die meiste Zeit“ ordnungsgemäß funktioniert. Das Protokoll nennt weder die Clientzahl noch Ergebnisse je Raum oder den NAT64-Graphenexport; diese Werte würden zeigen, ob die gemeldete Fähigkeit zuverlässigen Dienst ergab und ob die dargestellten Richtungen zusammenpassen.

Eine Frage aus dem Publikum betraf die NAT64-Grafik. Zwei Linien wirkten zu symmetrisch, falls sie Ein- und Ausgangsverkehr zeigten. Schepers hielt sie für leicht unterschiedlich und sagte, er werde nachsehen; der Sitzungsleiter kündigte ebenfalls eine Prüfung an. Das Transkript hält die Nachfrage und den zugesagten Graphencheck fest.

RFC 6146 beschreibt NAT64 als Verbindung für IPv6-Clients zu IPv4-Servern. Diese Übersetzung passiert an einer anderen Stelle als die WLAN-Nachbarerkennung. Der Gateway-Verkehr zeigt übersetzte Pakete; Verbindungsergebnisse je Raum zeigen, ob die Clients den ersten Link-Schritt schafften. Beschriftete Graphen machen die verglichenen Richtungen lesbar.

Das Team schaltete Funkmodule ab, setzte zusätzliche Access Points ein, installierte einen Umweg und bat die Teilnehmenden um Fehlermeldungen. Der Bericht zeigt die Kompatibilitätsquote neben dem Betriebseinsatz: Der IPv6-only-Test bestand für viele Geräte, während in einem Raum weiterhin ein Techniker die Verbindung am Laufen hielt.

Primärquellen: Transkript der RIPE-93-Abschlussplenarsitzung · Sitzung zum RIPE-93-Technikbericht · RFC 4861 · RFC 6146.