Zusammenfassung

  • RFC 7872 maß drei konkrete Sondenformen gegen historische Web-, Mail- und Nameserver-Mengen. Die Werte sind keine internetweite Verlustrate für 2026.
  • Die Klammerwerte schätzen nur innerhalb bereits verlorener Pakete den Anteil außerhalb des Ziel-AS. Pfad- und Organisationszuordnung blieben unsicher; Absicht und Herstellerkonformität wurden nicht bewiesen.

Kontrolle endet nicht am Zielnetz

Eine Zielorganisation kann sich für einen IPv6-Extension-Header entscheiden. Verwirft ein Transitnetz das Paket vorher, kann das Ziel diese Entscheidung nicht ausüben. Der operative Wert von RFC 7872 liegt deshalb in der Frage, wo Kontrolle über Nutzbarkeit tatsächlich ausgeübt wird.

Die Messwerte selbst sind datiert. Das Informational RFC erschien im Juni 2016 und berichtet Messungen vom August 2014 sowie eine Wiederholung vom Juni 2015 mit ähnlichen Ergebnissen. Eine später aktualisierte Dokumentseite ist keine neue Messkampagne.

Aus World IPv6 Launch und Alexa Top 1 Million entstanden je drei Adressmengen: Webserver über AAAA, Mailserver über MX und danach AAAA, Nameserver über NS und danach AAAA. Duplikate, nicht globale Unicast-Adressen und als unerreichbar eingestufte Ziele wurden entfernt.

DO8 enthielt einen acht Byte langen Destination-Options-Header mit PadN. HBH8 nutzte einen ebenso langen Hop-by-Hop-Header. FH512 erzeugte ungefähr zwei 512-Byte-Fragmente. Alle Sonden verwendeten TCP und den jeweiligen Dienstport.

Damit sind weder alle Optionen und Headerketten noch alle Größen, Transporte, Regionen oder Richtlinien geprüft. Das Experiment beschreibt genau diese Pakete in genau diesen Mengen.

Klammer und Hauptwert haben verschiedene Nenner

Der Hauptwert jeder Zelle ist die beobachtete Gesamtverlustrate. Die Klammer enthält die Best-/Worst-Case-Schätzung, welcher Anteil der verlorenen Pakete in einem anderen AS als dem Ziel-AS verworfen wurde.

In der Webmenge von World IPv6 Launch verlor DO8 11,88%; von diesen Verlusten wurden 17,60% / 20,80% außerhalb des Ziels verortet. HBH8 verlor 40,70%, mit 31,43% / 40,00% außerhalb. FH512 verlor 30,51%, mit 5,08% / 6,78%.

Über Web, Mail und Nameserver reichten die World-IPv6-Launch-Werte für DO8 von 11,88 bis 17,07%, für HBH8 von 40,70 bis 48,86% und für FH512 von 30,51 bis 39,17%. In den Alexa-Mengen lagen sie bei 10,91–21,33%, 39,03–54,12% und 28,26–55,23%.

Die Zuordnung schwankte stärker: Bei Alexa-Webverlusten betrug der geschätzte externe Anteil 46,52% / 53,23% für DO8 und 53,64% / 61,43% für FH512. Bei Alexa-Nameservern lag HBH8 bei 50,64% / 81,00%. FH512 für World-IPv6-Launch-Mail kam dagegen auf 2,91% / 12,73%.

81% bedeutet also nicht, dass 81% aller HBH8-Pakete im Transit verloren gingen. Es ist die obere Zuordnungsgrenze innerhalb einer bereits verlorenen Teilmenge.

Ein sichtbarer Hop ist keine eindeutige Organisation

Die Studie verglich einen Traceroute mit Extension Header und einen ohne. Der letzte antwortende Knoten des ersten heißt M, der folgende M+1. Filtert ein Gerät vor der Weiterleitungsentscheidung, wird M+1 als Verlustpunkt angenommen; filtert es danach, könnte es M sein. Gewählt wurde die erste Annahme.

Außerdem wird derselbe Pfad vorausgesetzt, obwohl das RFC ausdrücklich Abweichungen zulässt. Load-Balancing oder Routingänderungen können die scheinbare Grenze verschieben.

Auch die Adresse identifiziert den Betreiber nicht sicher. Peering-Adressraum kann von beiden Seiten stammen, IXP-Adressraum vom Exchange. Der Betreiber von M+1 kann organisatorisch zum dort oder zum danach gemappten AS gehören. Eine Organisation kann mehrere ASN betreiben, während die Messung verschiedene ASN als verschiedene Organisationen behandelt.

Im Best Case werden unklare Fälle dem Ziel zugeschlagen, im Worst Case einem anderen AS. Die Spanne dokumentiert Unwissen; sie benennt keinen Schuldigen.

Spätere RFCs liefern Mechanismen, keine rückwirkende Diagnose

RFC 7872 kann beabsichtigte Richtlinie, ungeeigneten Standardwert, Bug, Parsergrenze oder andere Ursachen nicht trennen. Ein Verlust im Ziel-AS mag leichter lokal änderbar sein, ist aber nicht harmlos. Ein Transitverlust entzieht dem Ziel die Wahl.

RFC 9098 erläutert variable Analyse, Slow Paths, Ressourcenverbrauch und Umgehungsrisiken. RFC 9288 gibt fähigkeitsabhängige Transit-Empfehlungen. RFC 9673 aktualisiert die Hop-by-Hop-Verarbeitung mit begrenzter, konfigurierbarer Arbeit. Das erklärt mögliche Mechanismen, nicht das Motiv eines Geräts im Jahr 2014.

RFC 7045 ist ein normativer Bezug und RFC 8200 die IPv6-Spezifikation. Beide beweisen weder Implementierung noch Verhalten eines bestimmten Herstellers. „Keine Antwort“ ist Beobachtung, „Verlust nahe dieser Grenze“ bedingte Folgerung, „absichtliche Sperre durch Betreiber X“ eine unbelegte Attribution.

Für die heutige Entscheidung neu messen

Festzulegen sind Headerfolge, Optionen, Längen, Transport, Ports, Paketgröße und Fragmentierung. Dazu gehört eine Kontrollsonde ohne Extension Header zu denselben Endpunkten und Zeiten, gesendet von mehreren autorisierten Standorten.

Paketbytes, Zeit, Antworten, Pfad und Routingzustand werden archiviert. Kontrollierte Endpunkte liefern Captures und Zähler. Traceroute grenzt ein, wenn Pfadgleichheit und Filterzeitpunkt als Unsicherheiten bestehen bleiben.

DO, HBH und Fragmentierung werden getrennt und nach Kunden-, Peer-, Transit-, IXP- und Zielpfaden segmentiert, soweit die Stichprobe trägt. Änderungen an BGP, Policy, Plattform oder Anwendung lösen eine Wiederholung aus. Ein verdächtiger externer Rand wird zuerst mit reproduzierbaren Paketdaten an den Betreiber gegeben.

Die belastbare Aussage lautet: Diese Konstruktion funktionierte oder scheiterte für diesen Dienst, von diesen Quellen, über diese Pfade, in diesem Zeitraum. Sie trägt eine konkrete Entscheidung, nicht ein Urteil über das Internet.