Zusammenfassung

  • RFC 5180 beschreibt ein reproduzierbares Laborprofil für IPv6-fähige Geräte. Der Messwert gilt für die ausgeführten Framegrößen, Ziele, Präfixe, Ports, Richtungen, Nachbarzustände, Headerketten, Filter und Softwarestände.
  • Der Hop-by-Hop-Test ist bewusst kein gewöhnlicher Throughput-Test: 1, 10 und 50 Prozent Last werden mit Ressourcentelemetrie kombiniert. Seit RFC 8200 muss der Bericht außerdem die explizite Verarbeitungskonfiguration des Knotens festhalten.

Labor A sendet 1518-Byte-Frames an ein Ziel über einen Port. Labor B mischt Framegrößen, randomisiert Ziele, aktiviert mehrere Ports und lässt einen Filter nach Transportinformationen hinter Extension Headers suchen. Beide schreiben 100 Gbit/s in die erste Zeile. Wer nur diese Zeile vergleicht, vergleicht Bezeichnungen statt ausführbaren Versuchsaufbau.

Ein Engineering-Audit beginnt deshalb nicht beim Ergebnis, sondern bei dessen Herkunft. RFC 5180 erschien 2008 als Informational RFC. Es ergänzt RFC 2544 um IPv6-spezifische Empfehlungen und verwendet die Terminologie aus RFC 1242. Wiederholbarkeit, Varianz und die statistische Aussagekraft kleiner Trial-Mengen sind ausdrücklich Teil der Auswertung. Der Methodenname allein ist kein Testprotokoll.

Framegröße und Zielmenge sind Messgrößensteuerung

Für Ethernet nennt RFC 5180 64, 128, 256, 512, 1024, 1280 und 1518 Byte. Kleine Frames erzwingen bei gleicher Bitrate deutlich mehr Entscheidungen pro Sekunde. Große Frames erleichtern einen hohen Gbit/s-Wert. Ein Audit muss deshalb die komplette Kurve sehen und prüfen, welche Verteilung zur späteren Last passt.

Auch die physikalische Referenz ist nicht exakt beliebig. Theoretische Ethernet-Maxima unterliegen einer Taktabweichung von plus oder minus 100 ppm. Bei Packet over SONET kann Bit Stuffing die Framerate verändern. Eine Tabelle mit zwei Nachkommastellen ist keine Garantie, dass der Versuch diese Genauigkeit tragen kann.

Eine einzelne Source-Destination-Kombination beansprucht möglicherweise einen warmen, schmalen Lookup-Pfad. Randomisierte Ziele beanspruchen einen anderen. RFC 5180 verlangt erst die einzelne Kombination und danach die Wiederholung mit zufälligem Ziel. /48, /64, /126 und /128 dienen als relevante Präfixgrenzen. Ohne Range, Verteilung und Seed ist die Wiederholung nicht auditierbar.

Port- und Richtungsgrenzen dürfen nicht verschwinden

Single-Port-Tests charakterisieren die Weiterleitung an einer Schnittstelle. Multi-Port-Tests charakterisieren die Skalierung der Plattform. Line Cards können Fabric, Speicher, Lookup-Ressourcen oder einen Softwarepfad teilen. Ein Interface-Ergebnis mal Portzahl ist eine Modellannahme, keine Chassis-Messung.

RFC 5180 empfiehlt bidirektionalen Verkehr, weist jedoch darauf hin, dass ein bidirektionales Ergebnis nur die schwächere Richtung sichtbar macht. Bei asymmetrischem Aufbau liefern unidirektionale Tests die notwendige Auflösung. Ingress kann andere Filter verwenden als Egress; kleine Requests können großen Responses gegenüberstehen. Ein aggregierter grüner Wert benennt den Engpass nicht.

Die Koexistenzmatrix erweitert diese Grenze. IPv4-only und IPv6-only werden durch 90/10, 50/50 und 10/90 ergänzt. Shared Resources können sich unter Mischlast anders verhalten. Ein reiner IPv6-Run darf in einem Audit nicht als Beleg für ein gemischtes Produktionsprofil erscheinen.

Hop-by-Hop ist eine Pfadprüfung

Extension Headers sollen einzeln und zusätzlich in einer Kette getestet werden. Für den Vergleich von Verkehr mit und ohne Header soll eine gemeinsame kleinste Framegröße gewählt werden. Andernfalls erzeugt die Framegeometrie den vermeintlichen Protokollunterschied.

Beim Hop-by-Hop Header ändert RFC 5180 das Ziel. Der Tester bietet 1, 10 und 50 Prozent der Interfacebandbreite an und beobachtet Ressourcen. Nicht der normale Maximaldurchsatz, sondern der Verarbeitungseffekt steht im Mittelpunkt. CPU und Speicher sollen out-of-band erfasst werden, unabhängig von den Interfaces mit Testverkehr. Damit lassen sich Hinweise auf Hardwarepfad, Recirculation, Software Forwarding oder Control-Plane-Druck gewinnen.

Die historische Fassung braucht jedoch einen Versionsvermerk. RFC 5180 bezog sich auf das Verarbeitungsmodell von RFC 2460. RFC 8200 erwartet später eine Hop-by-Hop-Prüfung entlang des Pfads nur, wenn ein Knoten dafür ausdrücklich konfiguriert ist. RFC 7045 hatte bereits Ignore oder Slow Path auf Hochleistungsroutern beschrieben. RFC 9098 erläutert begrenzte Lookup-Tiefe, Recirculation, Softwarepfade und Drops.

Ein aktueller Prüfbericht muss daher Konfiguration, Optionsinhalt, Rate, Dauer, Schutzpolicy und Ressourcenkurve enthalten. Identische Pakete können auf zwei Konfigurationen verschiedene Maschinen ausführen. Der Durchsatz allein identifiziert den Pfad nicht und beweist keine Angriffsfestigkeit.

Neighbor State und Policy gehören in die Abweichungsliste

Statische Nachbarn sind erlaubt; dynamisches Neighbor Discovery wird bevorzugt, wenn das Testwerkzeug die Caches aktiv hält. Simulierte Endpunkte liegen einen Hop hinter dem DUT, um NS/NA-Stürme durch Neighbor Unreachability Detection zu vermeiden.

Damit ist Neighbor State kein nebensächliches Setup. Statischer Eintrag, laufendes Refresh und Cache-Ablauf führen andere Zustandsübergänge aus. Ein Produktionsfehler beim Neuaufbau wird durch einen statischen Labortest nicht widerlegt.

Filter und Routing-Table-Größe verändern ebenfalls die Ausführung. Muss ein Gerät hinter einer Headerkette Layer-4-Information finden, kann ein tiefer Parser oder eine andere Stage aktiv werden. Ein Run ohne Policy bewertet nicht den Pfad, dessen Sicherheitsfunktion später verkauft wird.

Das Audit trennt zudem System Recovery nach Overload vom Reset eines Geräts oder der Software. Back-to-back Frames werden wegen hoher kurzfristiger Varianz für IPv6 nicht mehr empfohlen. Eine Metrik auszulassen kann methodisch sauberer sein, als einen instabilen Wert zu konservieren.

Die Laborgrenze ist Teil des Befunds

Die Benchmarktopologie muss unabhängig sein. Testverkehr darf weder in Produktion noch ins Managementnetz gelangen. Gemessen wird als Black Box von außen; Benchmark-spezifische Fähigkeiten sollen nicht existieren. Diese Regeln verhindern eine Sondermaschine für die Vorführung.

Sie belegen zugleich, dass Produktion nicht gemessen wurde. Routing Churn, konkurrierende Queues, gemeinsame Failure Domains, gemischte Builds, Betriebsrichtlinien und Nutzerergebnis wurden gezielt entfernt. Der Schluss darf sie nicht ohne neuen Beleg zurückholen.

Sogar der Adressraum trägt diese Grenze. Der publizierte RFC enthielt einen verifizierten technischen Erratumseintrag. Das aktuelle IANA-Register führt 2001:2::/48 als Benchmarking und als nicht global erreichbar. Ein korrekter Laborpräfix ist Teil der Belegkette.

Der Scope endet auch vor bestimmten Technologien. RFC 8219 behandelt Translation und Encapsulation separat und ergänzt Fragen zu State Tables und Overload. Dual Stack lässt sich mit RFC 2544 und RFC 5180 untersuchen; eine stateful Transition-Funktion benötigt andere Ausführungsevidenz.

Ein auditfähiger Ergebnisdatensatz

Jeder Wert braucht eine unveränderliche Profile-ID. Darunter stehen Gerät und Build, Features, Ports und Medium, Topologie, Testwerkzeug und Taktannahmen, Frameserie, Adress- und Präfixverteilung, Neighbor Mode, Extension Headers, Filter, Routen und Control Traffic, Richtung, IP-Mix, Offered Load, Dauer, Trial-Zahl, Loss, Latency, Sample-Verteilung, out-of-band Ressourcen, Recovery-Methode und Abweichungen.

Die Rollen bleiben getrennt: Method Owner formuliert die Frage, Lab Operator bewahrt die Ausführung, Statistikreviewer bewertet die Streuung, Release Owner belegt Build-Gleichheit, Operations validiert die Extrapolation durch sichere Produktionsbeobachtung. Keine Unterschrift deckt automatisch die nächste Realitätsschicht ab.

Ein Benchmark wird dadurch nicht geschwächt. Er wird davor geschützt, als Nachweis für ein System zu dienen, das er nie ausgeführt hat.

Quellen

  1. RFC 5180 — HTML
  2. RFC 5180 — Text
  3. RFC-Editor-Informationsseite
  4. IETF Datatracker Dokument
  5. Datatracker-Historie
  6. Datatracker-Referenzen
  7. RFC-5180-Errata
  8. RFC 2544
  9. RFC 1242
  10. RFC 8200
  11. RFC 7045
  12. RFC 9098
  13. RFC 4861
  14. RFC 8201
  15. RFC 6890
  16. IANA IPv6 Special-Purpose Address Registry
  17. RFC 8219
  18. Heng Lu — Realitätsebenen
  19. Heng Lu — minimale Spezifikation und freiwillige Übernahme
  20. Heng Lu — Vorrang von Running Code