Zusammenfassung

  • RFC 1088, als STD 48 veröffentlicht, kapselt IP-Datagramme in NetBIOS-Datagramme und bildet die Zieladresse regelbasiert auf IP.XX.XX.XX.XX ab.
  • Dadurch entfällt für diese Namensbestimmung eine physische Adressabfrage. Die Regel belegt keine Route, keine Inhaberschaft, keine Gegenstellenidentität, kein IP-Multicast und keinen erfolgreichen Anwendungsvorgang.

Eine Formel, die sich prüfen lässt, lädt zu einer falschen Art von Gewissheit ein. RFC 1088 liefert jedoch keine Behauptung über einen ganzen Rechner oder ein ganzes Netz. Sie beschreibt ein interoperables Verfahren, IP-Datagramme über den Datagrammdienst von NetBIOS zu transportieren. Das IP-Datagramm ist dabei Nutzdaten eines NetBIOS-Datagramms; seine Zielbezeichnung wird aus der IP-Adresse berechnet.

Der Name darf bis zu sechzehn Byte enthalten. Für IP-Anwendungen setzt die RFC IP. vor die vier in ASCII-Hexadezimal geschriebenen Adressbytes. Weil der Name so aus der Internetnummer hervorgeht, sei kein physischer Adressmechanismus wie ARP nötig. Die Reichweite dieser Aussage ist eng und wertvoll: Der für diesen Datagrammdienst benötigte Name ist bereits bekannt. Sie erklärt nicht, auf welchem Weg das Datagramm ankommt, ob ein Interface lebt oder wem die IP-Adresse zugeordnet ist.

RFC 791 trennt Namen, Adressen und Routen ausdrücklich. Ein Name zeigt, was gesucht wird; eine Adresse, wo es ist; eine Route, wie man dorthin gelangt. RFC 1088 nimmt eine IP-Adresse und erzeugt eine lokale Zustellbezeichnung. Der lesbare String erlaubt eine Sichtprüfung. Er erlaubt nicht, eine Route zu behaupten oder aus dem String Identität, Eigentum oder Berechtigung abzuleiten.

Lokale Einträge statt Topologie-Ermittlung

Auch der Ablauf im Host bleibt bewusst klein. Für jede unterstützte IP-Adresse fügt die Initialisierung IP.XX.XX.XX.XX in die NetBIOS-Namenstabelle ein und fügt außerdem den Gruppennamen IP.FF.FF.FF.FF hinzu. Für beide Ziele werden Empfangsanfragen für Datagramme gestellt. Bei Empfang verarbeitet der Protokollstapel die Daten und stellt die Anfrage erneut. Beim Beenden werden offene Empfangsanfragen abgebrochen und beide Namen gelöscht.

Das ist Zustand an einem Host, nicht Entdeckung einer verborgenen Mehr-LAN-Topologie. RFC 950 zeigt den Kontrast transparenter Subnetze: Bridges können dort ARP-Anfragen abfangen, den Standort eines Hosts auf einer LAN ermitteln und Caches führen müssen. RFC 1088 behauptet diese Arbeit nicht. Sie sagt im Voraus, welcher Name im definierten NetBIOS-Träger verwendet wird.

Darum ersetzt sie auch ARP nicht als allgemeines Prinzip. RFC 826 beschreibt im Ethernet-Kontext die Auflösung einer Protokolladresse in eine Ethernet-Adresse. RFC 1088 sagt für ihren Kontext nur: Die IP-Adresse liefert schon den NetBIOS-Namen, den der Datagrammdienst braucht. Eine Abfrage fällt weg. Nicht wegfallen damit Topologie, Routingentscheidung, Verfügbarkeit oder Verantwortung.

Broadcast ist kein stillschweigendes Multicast

Für Internet-Broadcast-Adressen definiert die RFC den NetBIOS-Gruppennamen IP.FF.FF.FF.FF. Sie sagt zugleich klar, dass sie keinen Versuch unternimmt, IP-Multicast-Adressen über NetBIOS-Gruppennamen zu unterstützen. Der Broadcastname ist also eine benannte Grenze, nicht der Beleg einer umfassenden Gruppensemantik.

Die Trägergrenze ist ebenso konkret: Ein NetBIOS-Datagramm kann höchstens 512 Byte Daten tragen; das ist somit die MTU für IP über NetBIOS. Kommunikationspartner müssen fragmentierte Datagramme gegebenenfalls wieder zusammensetzen. Abgeleiteter Name, Sendung, Fragmente und wieder zusammengesetztes IP-Datagramm sind getrennte Beobachtungen. Ein Betriebsprotokoll, das daraus „Ziel bestätigt“ macht, verwischt die Fehlerstelle.

Auch der erwähnte Router ist eine Bedingung, kein Befund. Ein Router, der IP sowohl in üblichen Datenlink-Protokollen als auch in NetBIOS-Datagrammen kapseln kann, erlaubt diesen Hosts die Kommunikation mit dem weiteren Internet. Das beweist nicht, dass ein solcher Router an einem Ort lief, dass für eine konkrete Adresse ein Pfad bestand oder dass die Gegenstelle erreichbar war.

Die historische Nüchternheit ist entscheidend. RFC 1088 verringerte eine lokale Auflösungsarbeit, indem sie einen Namen berechenbar machte. Aus Berechenbarkeit wurde weder Hoheit noch Autorität.

Quellen und Grenzen

Die Quellen belegen die Kapselung von 1989, die Namensform, den Empfangszustand, Broadcast-/Multicast-Grenzen und MTU sowie die Unterschiede zu IP, Subnetting und ARP. Sie belegen weder aktuelle Verbreitung noch Host-Konfiguration, Eigentum, Identität, Autorisierung, beobachtete Route, Zustellung oder Anwendungserfolg.