Zusammenfassung

  • RFC 919 wählte ein Hostfeld aus lauter Einsen für „alle Hosts“ und definierte 255.255.255.255 als nicht weitergeleiteten lokalen Broadcast.
  • RFC 922 übertrug die Konvention auf Subnetze, ohne das IP-Datagramm zu verändern.
  • RFC 1122 standardisierte die Einsen beim Senden und empfahl weiterhin die Erkennung älterer Null-Formen beim Empfang.

Als ein Ziel nicht mehr nur einen Rechner bezeichnete

Die ursprüngliche IP-Spezifikation enthielt kein einheitliches Verfahren, um ein Datagramm an alle zu senden. RFC 919 knüpfte an die Broadcast-Fähigkeit lokaler Netze an und definierte ein Ziel, das mehrere Hosts gleichzeitig als für sich bestimmt erkennen konnten.

Der Dienst war absichtlich unzuverlässig, ungeordnet und möglicherweise doppelt. Jeder empfangende Host musste außerdem Verarbeitungsaufwand tragen. Broadcast war daher kein zuverlässiger Gruppenversand.

Die Wahl der Einsen

Für die Interoperabilität wurde eine Hostnummer benötigt, die „alle Hosts“ bedeutete. RFC 919 wählte den Wert mit ausschließlich Eins-Bits, weil er wahrscheinlich keinem echten Host zugewiesen war.

255.255.255.255 bezeichnete alle Hosts im direkt angeschlossenen physischen Netz und durfte nicht weitergeleitet werden. 36.255.255.255 bezeichnete dagegen alle Hosts des Netzes 36; ein Gateway konnte das Datagramm dorthin transportieren und erst am Ziel in einen Link-Broadcast umsetzen. Die Position der Bits bestimmte also die Reichweite.

Nullfelder standen weiterhin für „nicht spezifiziert“ oder für Netznotation. Der Standard entschied sich für Einsen, ohne ältere Systeme mit Null-Broadcasts sofort verschwinden zu lassen.

Die Hierarchie der Subnetze

RFC 922 übertrug die Logik auf Netzwerk-, Subnetz- und Hostfelder, ohne das IP-Datagramm zu ändern. Je nachdem, welche Felder nur Einsen enthielten und welche Adressmaske galt, konnte das Ziel das lokale physische Netz, ein entferntes physisches Netz, ein bestimmtes Subnetz oder alle Subnetze eines IP-Netzes umfassen. Gateways durften das Datagramm außerdem nicht auf dem physischen Netz erneut aussenden, über das es eingegangen war.

Auch an der ARP-Grenze war Erkennung entscheidend. Ein ARP-Server durfte nicht auf eine Anfrage nach einer Broadcast-Adresse antworten. Sonst konnten Hosts, die das Sonderziel nicht erkannten, Schleifen und eine starke Vervielfachung der Aussendungen erzeugen.

Standardisierte Sender, tolerante Empfänger

RFC 1122 nennt vier Standardformen: die begrenzte Rundsendung {-1,-1}, die an ein Netz gerichtete Form {network,-1}, die an ein Subnetz gerichtete Form {network,subnet,-1} und die an alle Subnetze gerichtete Form {network,-1,-1}.

Hosts mussten diese Formen erkennen und sollten auch die nicht standardisierten Varianten akzeptieren, die -1 durch Nullen ersetzten, darunter Formen aus 4.2BSD-Nachfolgern. Beim Senden durfte eine Schnittstelle wählen; der Standard sollte jedoch die Form mit lauter Einsen sein.

Das war eine asymmetrische Migration: Alte Eingaben wurden toleriert, während standardisierte Ausgaben die Mehrdeutigkeit verringerten. Beim Senden an eine Broadcast-Adresse der Sicherungsschicht musste das IP-Ziel eine gültige Broadcast- oder Multicast-Adresse sein. Traf ein Rahmen per Link-Broadcast ein, sollte der Host ihn still verwerfen, wenn sein IP-Ziel weder Broadcast noch Multicast war.

Warum der begrenzte Umfang robuster war

RFC 1122 empfahl die begrenzte Rundsendung für das angeschlossene Netz. Sie setzte nicht voraus, dass alle Rechner Netzwerknummer und Maske gleich interpretierten. Ob gerichtete Broadcasts weitergeleitet wurden, blieb eine Entscheidung der Gateways aus Sicherheits- und Leistungsgründen.

Die Geschichte lautet daher nicht einfach „Einsen besiegen Nullen“. Einsen wurden zur standardmäßigen Ausgabe, Nullen blieben als Kompatibilitätseingabe erhalten. Daraus entstand ein gemeinsamer Adressvertrag, aber keine Garantie für zuverlässige Zustellung oder obligatorische Weiterleitung.

Quellen