Zusammenfassung

  • RFC 2097 ließ ein entferntes Endsystem konkrete NetBIOS-Namen beim Peer anmelden. Dieselbe Aushandlung konnte einige Namen annehmen und für andere unterschiedliche Fehler liefern.
  • NBFCP machte außerdem Peer-Klasse, Multicast-Takt und -Priorität sowie die mögliche Pflicht zu einem zwölf Oktett langen IEEE-MAC-Header sichtbar.
  • Opened und Added=0 waren lokale Belege. Sie bewiesen weder weltweite Eindeutigkeit noch Identität, Berechtigung, LAN-zu-LAN-Verbindung, vollständige Zustellung, Sitzungserfolg oder Sicherheit.

Eine Fernzugangsleitung kann elektrisch aktiv sein, LCP abgeschlossen haben und bereits die Network-Layer-Protocol-Phase von PPP erreicht haben, während ein von der Anwendung benötigter Name auf der Gegenseite noch keinen Platz besitzt. RFC 2097 machte diese Lücke beobachtbar.

Das im Januar 1997 veröffentlichte PPP NetBIOS Frames Control Protocol wies 0x803f dem NBFCP-Kanal und 0x003f den NBF-Datagrammen zu. Seine Topologie war bewusst eng: Ein Endsystem durfte einen Peer oder dessen angeschlossenes LAN erreichen. Zwei LANs miteinander zu verbinden, schloss der Text wegen der Grenzen und Abwehrmechanismen von NetBIOS-Namen aus.

Träger öffnen und Namen zulassen waren getrennte Vorgänge

PPP teilte die Arbeit in Phasen. LCP stellte den Datenlink her, konfigurierte und prüfte ihn; Authentisierung und Qualitätsprüfung konnten folgen. NBFCP durfte erst in der Network-Layer-Protocol-Phase verkehren. NBF-Datagramme waren erst nach Opened zugelassen.

Für Endsysteme verlangte RFC 2097 dennoch Name-Projection. Der Absender listete die 16-Oktett-Namen auf, die der entfernte Peer seinem Netz hinzufügen sollte, und kennzeichnete jeden als Einzel- oder Gruppennamen. Das ein Oktett breite Length-Feld begrenzte eine Option auf vierzehn Namen; größere Mengen brauchten mehrere Optionen.

Dies war kein pauschales Fähigkeitsmerkmal. Eine Station konnte mehrere Namen für verschiedene Dienste oder Rollen brauchen. Der Peer musste jeden einzeln in seine lokale Netzsicht aufzunehmen versuchen.

Teilweise Annahme blieb als vollständige Liste sichtbar

Konnte der Empfänger nicht alle Namen hinzufügen, musste er ein Configure-Nak mit der vollständigen Liste senden. Erfolgreiche Einträge trugen Added=0; andere erhielten einen eindeutigen Fehler, etwa Duplikat in der lokalen Tabelle, volle Tabelle, auf dem entfernten NetBIOS verwendeter Name, erkannter Konflikt, Definition durch eine andere Umgebung oder erschöpfte Ressourcen.

Die Liste war Vorschlag und Quittung zugleich. Zwei gemeinsam angeforderte Namen konnten verschieden enden. Der Sender sollte die erfolgreichen Namen erneut beantragen, durfte NBFCP aber beenden, wenn die Anwendung die ganze Menge benötigte. Das Netz entschied mit einer Teilannahme nicht über die Bedeutung des fehlenden Namens.

Auch Zeit war Teil des Belegs. Das Hinzufügen von Namen dauerte meist etwa drei Sekunden und traf damit auf den möglichen PPP-Standardwert des Neustart-Timers. RFC 2097 empfahl zehn Sekunden während der Namenskonfiguration. Eine frühe Wiederholung konnte Ungeduld des Steuerkreises statt Abwesenheit des Peers messen.

Added=0 stützt deshalb nur die Aussage: In diesem Austausch meldete dieser Peer, diesen Namen hinzugefügt zu haben. Eine konsistente Sicht aller Segmente, Namensserver oder Bridges folgt daraus nicht. RFC 1001 wies selbst auf mögliche Inkonsistenzen nach Fehlern hin.

Die Peer-Klasse war Selbstauskunft, keine Identität

Peer-Information konnte Implementierungsklasse, Haupt- und Nebenversion und einen optionalen Namen tragen. Die Anfangswerte unterschieden PPP-NetBIOS-Gateway, Server mit nur lokalem Zugriff, NBF-Bridge und Endsystem.

Das war operativ relevant: Eine Bridge bot eine andere Weiterleitungsfläche als ein Server, der nichts an andere Systeme weitergab. Die Option war aber nur empfohlen, und die Werte kamen vom Peer selbst. RFC 2097 band sie nicht kryptografisch an ein geprüftes Gerät, Unternehmen oder einen Betreiber.

Multicast-Politik konnte einen erreichbaren Dienst verbergen

Manche NetBIOS-Anwendungen brauchten Multicast, andere nicht. Multicast-Filtering handelte daher Höchstperiode und Priorität aus. Null forderte die Weitergabe aller Multicasts. Ein normaler Wert bis sechzig Sekunden begrenzte die Häufigkeit. 0xFFFF bezeichnete je nach Request oder Nak eine angeforderte beziehungsweise nicht vorhandene Angabe. Das Prioritätsbit entschied zwischen Multicast und gerichteten Paketen.

Bandbreitenpolitik wurde damit zu Anwendungsverhalten. Link und Namen konnten funktionieren, während eine von häufigen Ankündigungen abhängige Anwendung defekt wirkte. Die Periodenvereinbarung beschrieb Behandlung, nicht die Ankunft jedes Pakets.

Zwölf Oktette änderten die zulässige Hülle

NBF trat mit 802.3-Ethernet-, 802.5-Token-Ring-, DIX-Ethernet- und FDDI-Headern auf. Manche PPP-Implementierungen brauchten den kompletten Header zum Bridging, andere nur IEEE-Adressen, Gateways mitunter gar keine MAC-Felder.

IEEE-MAC-Address-Required drückte diese Abhängigkeit aus. Standardmäßig fehlte der MAC-Header. Nach erfolgreicher Aushandlung begann jedes NBF-Datagramm mit zwölf Oktetten Ziel- und Quelladresse. Weil dies erst nach der LCP-Aushandlung der MRU feststand, musste der Empfänger NBF-Pakete annehmen, die die MRU um zwölf Oktette überschritten.

Die Zahl der unteren Schicht war also nicht der gesamte Paketvertrag. Ein beobachteter Header bewies die Darstellung, nicht Weiterleitung oder Empfang.

Opened war Erlaubnis, kein Ergebniszertifikat

Die vier Optionen trennten Fakten, die Betriebsanzeigen gern in eine grüne Lampe pressen: zugelassene Namen, behauptete Peer-Rolle, Multicast-Behandlung und Frame-Form. Opened erlaubte NBF auf diesem Link unter diesen Bedingungen.

Ein Sicherheitsversprechen gab es nicht. Der Abschnitt Security Considerations erklärte Sicherheit für unbehandelt. NBFCP authentisierte weder Menschen noch Maschinen, berechtigte keinen Namen, verschlüsselte nicht und bewies keine Integrität. Der Ausschluss von LAN-zu-LAN-Anwendungen bewahrte die Grenze zwischen lokaler Projektion und allgemeinem Routing.

IANA führt bis heute beide Protokollwerte, die vier Optionen, Ergebniscodes und Peer-Klassen. Das belegt stabile Kennungen, nicht aktuelle Nutzung oder Produktkonformität. Auch das Fehlen registrierter Errata ist keine Interoperabilitätsmessung.

Der Unterschied zu RFC 1088 ist klar: RFC 1088 leitete einen NetBIOS-Namen mechanisch aus einer IPv4-Adresse ab. RFC 2097 erzeugte keinen Namen; es brachte eine vom Peer gewählte Menge an einen entfernten Zulassungspunkt und lieferte Ergebnisse pro Eintrag.

Aus Lu Hengs späterem Blick auf Minimum Initial Specification und Running-Code Primacy wirkt NBFCP wie eine gemeinsame Schicht, die nur überprüfbare Interoperabilitätszusagen enthält. Das ist redaktionelle Einordnung, kein Beleg für die Absicht des RFC-Autors. Historisch genügt: Sobald Namen, Peer-Rolle, Multicast und Frame-Form eigene Quittungen erhielten, war Link-up nicht mehr gleich Zugang.

Quellen