Zusammenfassung

  • RFC 2452 ließ tcpActiveOpens und die meisten TCP-Verwaltungsobjekte für IPv4 und IPv6 gemeinsam gelten; es duplizierte nicht jedes Maß pro IP-Familie.
  • Für IPv6 ergänzte ipv6TcpConnIfIndex die vier Endpunktwerte, weil diese auf einem Knoten mit mehreren Schnittstellen eine Tabellenzeile nicht immer eindeutig bestimmten.

Wenn vier Felder nicht eindeutig sind

Eine Verbindungstabelle zeigt lokale Adresse und Port sowie entfernte Adresse und Port. Das sieht nach einem vollständigen Schlüssel aus. IPv6-Adressen besitzen jedoch einen Geltungsbereich. Eine Link-Local-Adresse ist innerhalb ihres Links sinnvoll, aber nicht zwangsläufig auf allen Schnittstellen eines verwalteten Knotens einzigartig. Derselbe Adresswert kann daher zu unterschiedlichen Schnittstellenkontexten gehören.

RFC 2452 ergänzte im Dezember 1998 ipv6TcpConnIfIndex als fünften Index der IPv6-TCP-Zeile. Die neue Koordinate vervollständigte den Schlüssel des Verwaltungsobjekts. Sie wurde weder ein fünftes Feld im TCP-Header noch änderte sie die Transport-Tupel, die über das Netz übertragen werden. Die Trennung ist wichtig: Ein Index kann eine Tabellenzeile eindeutig machen, ohne die Identität der Verbindung auf der Leitung neu zu definieren.

Warum die Zähler nicht ebenfalls getrennt wurden

RFC 2452 sagte, dass die IP-Version für das Verhalten der meisten TCP-Objekte unerheblich sei. Eine Implementierung musste IPv6-Adressen unterstützen, brauchte aber kein neues „TCPng“. tcpActiveOpens zählt beispielsweise direkte Übergänge von CLOSED nach SYN-SENT, unabhängig davon, welche IP-Version die Verbindung zwischen ihren Endpunkten nutzt.

Ein gemeinsamer Zähler erhält damit die Bedeutung desselben TCP-Ereignisses. Er sagt nicht, ob der Anstieg über IPv4 oder IPv6 entstand, welche Verbindung betroffen war oder welcher Prozess ihn ausgelöst hat. Und die RFC-Aussage beschreibt einen externen Verwaltungsvertrag; sie belegt nicht, dass jedes Gerät intern einen Speicherbereich für beide Familien verwendete.

Die Verbindungstabelle war die konkrete Ausnahme. RFC 2012 verwendete den vier Oktette langen SMIv2-Typ IpAddress, der IPv6-Endpunkte nicht darstellen kann. RFC 2452 definierte deshalb ipv6TcpConnTable nur für IPv6-zu-IPv6-Verbindungen; IPv4 blieb in der älteren tcpConnTable. Eine neue, versionsübergreifende Tabelle hätte Änderungen an RFC 2012 und an IPv4-only-Implementierungen verlangt. Die parallele Tabelle hielt den alten Pfad zunächst intakt. Weil später eine Aktualisierung erwartet wurde, erhielt das neue MIB-Modul eine Identität unter dem experimentellen MIB-Zweig.

Der Index benennt Kontext, keine Person

Die Bedeutung des Schnittstellenwerts hing von den Adressen ab. War die entfernte Adresse Link-Local und die lokale nicht, bezeichnete der Index eine lokale Schnittstelle am selben Link wie der entfernte Endpunkt. Sonst zeigte er auf die mit der lokalen IPv6-Adresse verbundene Schnittstelle. Ein Wert ungleich null entsprach derselben Schnittstelle wie der gleich nummerierte ipv6IfIndex und sollte während der Verbindung konstant bleiben.

Wenn sich die Schnittstelle nicht ermitteln ließ, durfte der Wert null sein; ::0 als lokale Wildcard-Adresse war ein mögliches Beispiel. Null bezeichnete keine geheime Schnittstelle mit der Nummer null. Es hielt fest, dass die Zuordnung unbekannt war. Wer die Lücke nachträglich mit der wahrscheinlichsten Schnittstelle füllt, ersetzt eine ausdrücklich erhaltene Unsicherheit durch eine unbelegte Behauptung.

Auch die Zeile selbst war flüchtig. Sie verschwand beim Übergang nach CLOSED oder kurz danach. Die Tabelle beschrieb somit eine aktuelle Verwaltungsbeobachtung, keine dauerhafte Identität eines Servers, Prozesses, Benutzers oder Dienstes. Weder vier Endpunktwerte noch der Interface-Index beweisen Gegenstellenidentität, Adressbesitz, Erreichbarkeit oder Anwendungserfolg.

Die IPv6-Tabelle erbte außerdem das schreibbare deleteTCB(12), mit dem eine Verbindung auf dem verwalteten Knoten beendet werden konnte. Der bereits veröffentlichte Artikel zu RFC 2012 behandelt diese Eingriffsgeschichte; hier ist sie nur ein begrenzter Hinweis auf die Sensibilität der Oberfläche. Ein genauer Index gewährt keine Berechtigung und beweist nicht, was die Gegenstelle oder Anwendung erlebt hat.

RFC 4022 ersetzte 2005 RFC 2012 und RFC 2452 durch ein IP-versionsunabhängiges TCP-MIB und nutzte generische Adresskonventionen, statt die IPv6-Tabelle mitsamt fünftem Index unverändert fortzuführen. RFC 4001 stellte InetAddressType und InetAddress samt zonenqualifizierter Formen bereit; RFC 4007 beschrieb IPv6-Geltungsbereiche und Zonen. 2017 stufte RFC 8096 RFC 2452 in einem getrennten Schritt auf Historic zurück und markierte die alten IPv6-spezifischen MIB-Module für die Repositorypflege als obsolete. Technische Ablösung und historische Neuklassifizierung waren zwei verschiedene Ereignisse.

Quellen