Zusammenfassung

  • RFC 950 ergänzte ICMP Address Mask Request und Reply, damit ein bootender Host die 32-Bit-Maske seines LAN lernte; ohne Antwort verwendete er einen classful Fallback, den der Text selbst als möglicherweise falsch bezeichnete.
  • RFC 1122 beschränkte Antworten auf ausdrücklich konfigurierte authoritative agents: Eine Maske zu lernen verlieh kein Antwortrecht, und die erste akzeptierte Reply schloss das Fenster.
  • DHCP lieferte die Maske später mit weiterer Konfiguration und konnte alte Discovery- und Supplier-Rollen schalten; RFC 6918 stufte die ICMP-Typen 17 und 18 schließlich als Deprecated ein.

Die Adresse enthielt den lokalen Rand nicht

RFC 950 wählte eine 32-Bit-Maske, weil eine Organisation selbst bestimmen musste, welche Bits ihres lokalen Adressteils Subnetz und Host bezeichneten. Die interne Struktur ließ sich nicht aus der globalen IPv4-Adresse allein ablesen.

Der Wert steuerte Forwarding. Der Host maskierte eigene Adresse und Ziel; Gleichheit bedeutete direkte Zustellung, Ungleichheit einen Gatewayweg. Eine falsche Maske veränderte daher, wer als Nachbar galt.

Ein Rechner mit Speicher konnte eine Datei lesen. Disklose Workstations brauchten beim Netzstart Adresse, Gateway, Nameserver und Maske. RFC 950 bevorzugte bereits eine gemeinsame Lieferung durch einen Bootserver, definierte aber für die einzelne Maskenfrage eine ICMP-Lösung.

Nach mehreren unbeantworteten Versuchen blieben drei Wirklichkeiten möglich: Das Netz war dauerhaft isoliert, verwendete keine Subnetze und hatte keinen Agenten, oder alle Gateways waren vorübergehend ausgefallen.

Schweigen erlaubte eine reversible Entscheidung

Die Beobachtung unterschied diese Zustände nicht. Als konservativen Fallback wählte RFC 950 die Maske der Internet-Netznummer, also die classful Interpretation ohne Subnetz.

Der Text sagte ausdrücklich, dass sich die Wahl als falsch erweisen konnte. „Sicher“ meinte nur, sie solle keine Übertragung verhindern, die sonst erfolgreich wäre. Schweigen bewies keine unsubnetted Topologie.

Negative Evidenz rechtfertigte somit eine begrenzte Betriebsaktion. Sie wurde nicht zur positiven Aussage über den Verwaltungsplan.

Der Host musste weiterarbeiten und durfte dafür annehmen. Er durfte die Annahme nicht als erlernte Wahrheit behandeln.

Die Frage ging an das gemeinsame Medium

Ein Address Mask Request wurde im LAN gebroadcastet. Ein Gateway oder ein Host in dessen Rolle antwortete mit der Maske des Eingangs-Subnetzes. War die Quelladresse null, weil der Anfragende sie noch nicht kannte, wurde auch die Reply ausgestrahlt.

Das Format bestand aus Type, Code null, Checksum, Identifier, Sequence Number und der 32-Bit Address Mask. Spätere Register führen Request als Typ 17 und Reply als Typ 18.

Identifier und Sequence konnten korrelieren, doch RFC 950 erlaubte, sie zu ignorieren. Es nahm eine richtige Maske pro LAN an. Mehrere Gateways durften antworten, sofern ihre Werte übereinstimmten.

Korrelation schuf keine Autorität. Die Verbindung zu einer Anfrage sagte nicht, ob der Absender für das LAN sprechen durfte. Die Maske war gemeinsame Attachment-Konfiguration, keine Clientpräferenz.

Der zurückkehrende Agent korrigierte alte Starts

Der Fallback blieb reparierbar. Beim Start sollte ein Gateway eine unaufgeforderte Reply broadcasten. Ein Host mit abweichender Schätzung änderte seine Maske.

So erreichte die Korrektur Hosts, die längst nicht mehr retransmittierten. Der Agent stellte kein altes Gespräch wieder her, sondern veröffentlichte den lokalen Wert bei seiner Rückkehr erneut.

RFC 950 verbot Replies aus einer geratenen Maske. Sonst würde jeder Timeout-Host seine provisorische Folgerung als offizielle Konfiguration wiederholen und ein kurzer Ausfall viele falsche Herausgeber erzeugen.

Private Nutzung und öffentliche Ausgabe waren getrennt. Ein Fallback hielt Betrieb aufrecht, war aber keine Delegation.

Autorität entstand aus ausdrücklicher Konfiguration

RFC 1122 verlangte, dass nur ein authoritative agent Reply sendet und diese Rolle ausdrücklich konfiguriert ist. Host oder Gateway konnten gewählt werden; die Geräteklasse verlieh sie nicht.

Der Empfang einer Reply übertrug die Rolle nicht. Eine gelernte Maske durfte nicht als Grundlage eigener Antworten dienen. Wissen und Mandat blieben verschieden.

Die Discussion nennt sorglos antwortende Hosts mit ungültigen Masken als ernstes Ärgernis. Nicht nur die Form des Werts, sondern die administrative Auswahl des Sprechers war die Lösung.

Das Paket authentisierte die Auswahl nicht kryptografisch. Der Standard bestimmte den berechtigten Akteur; Segmentkontrolle und korrekte Konfiguration mussten die Regel durchsetzen.

Die erste Antwort gewann

RFC 1122 erlaubte statische und dynamische Quellen bei konfigurierbarer Auswahl. Bei aktivem Discovery retransmittierte der Host. Die erste Reply für die lokale Adresse, angefordert oder spontan, setzte die Maske; spätere wurden still ignoriert.

First-wins verhinderte Oszillation durch Duplikate und verspätete Antworten. Es war keine Authentisierung. Eine plausible Fälschung konnte vor dem richtigen Agenten eintreffen.

Ein Reasonableness Check sollte unter anderem all-one ablehnen und null oder gesetzte oberste acht Bits verlangen. Das fand manche Absurdität, bewies jedoch nicht die Verwaltungsabsicht.

Bei deaktivierten Maskenmeldungen fragte der Host nicht und ignorierte Replies. Protokollerkennung allein öffnete keine Konfigurationsänderung.

Ein Wert pro LAN bündelte das Risiko

Die Ein-Wert-Annahme vereinfachte mehrere Agenten und machte genaues Matching entbehrlich. Ein falscher gemeinsamer Wert konnte dafür alle entdeckenden Hosts betreffen.

Ein mehrfach angebundener Host brauchte eine Maske je LAN. Sie gehörte zur Adresse auf einer Schnittstelle, nicht zur globalen Identität des Rechners.

Die isolierte Frage trennte die Maske von Adresse, Router und weiteren Bootdaten. Jede Antwort konnte einzeln richtig sein und dennoch einen anderen Zeitpunkt oder Kontext beschreiben.

Spätere Konfiguration vergrößerte deshalb die Einheit, in der zusammengehörige Fakten konsistent geliefert wurden.

DHCP verwaltete zunächst die Koexistenz

RFC 2131 beschrieb RARP für Adressen, ICMP für Maske oder Router, BOOTP für Parametersammlungen und weitere Mechanismen. DHCP verband Adressvergabe und Konfiguration in einem zustandsbehafteten Austausch.

ICMP verschwand nicht sofort. Mask Request blieb erwähnt, und die Subnet Mask blieb Schnittstellenparameter.

RFC 2132 zeigt den Übergang. Option 1 trägt vier Oktette Subnet Mask. Zusammen mit Router Options muss sie zuerst stehen, damit der Client die Adressen unter der richtigen Grenze interpretiert.

Option 29, Perform Mask Discovery, schaltet ICMP-Anfragen. Option 30, Mask Supplier, schaltet Antworten. Der neue Kanal lieferte den Wert und regierte die alten Rollen.

Eine DHCP-Anweisung zum Supplier war explizite Konfiguration. Eine gehörte ICMP-Reply blieb unzureichend. Die Autoritätsgrenze überdauerte den technischen Übergang.

Die Konfigurationseinheit wurde größer

Ein Server, der eine Adresse vergab oder bestätigte, konnte die zugehörige Maske in derselben Beziehung liefern. Das Schweigen eines Hilfsprotokolls musste nicht länger allein über Subnetting entscheiden.

DHCP wurde dadurch nicht unfehlbar. Herkunft und Zusammenhang waren aber sichtbarer, und der Legacy-Pfad ließ sich ausdrücklich schließen.

Die Optionen 29 und 30 belegen Migration statt sofortiger Entfernung. Betreiber konnten direkt liefern, redundantes Discovery abschalten oder die alte Funktion bewusst behalten.

Die einzelne Broadcastfrage verlor praktisch an Wert, bevor der Registerstatus die Ablösung formalisierte.

Deprecated bewahrte die historische Koordinate

RFC 6918 stufte mehrere ICMPv4-Typen herab. Address Mask Request und Reply seien für Hostkonfiguration durch Mechanismen wie DHCP ersetzt worden.

Das löschte keine Nummer und maß nicht null Implementierungen. Neue Entwürfe sollten keine Abhängigkeit schaffen; das Register folgte der veränderten Praxis.

RFC 7279 listet Typ 17 und 18 als Deprecated. Die historischen Werte bleiben sichtbar, damit alte Bytes nicht inkompatibel neu interpretiert werden.

Die Abfolge war graduell: lokale Einzelfrage, strenge Agentenregel, DHCP-gesteuerte Koexistenz und formale Deprecation.

Was eine beobachtete Reply belegt

Typ 18 in einem Mitschnitt belegt eine ICMP-Nachricht mit behaupteter Maske und sichtbaren Strukturfeldern. Identifier und Sequence können sie einer Anfrage zuordnen, obwohl frühe Praxis das nicht verlangte.

Sie beweist weder Agentenkonfiguration noch administrative Richtigkeit, Installation beim Empfänger oder Abwesenheit einer früheren Antwort. Syntaktische Plausibilität ist keine Befugnis.

Eine unbeantwortete Request zeigt nur, dass im Intervall keine Reply beobachtet wurde. Nichtexistenz, Ausfall, Filter und Verlust sehen gleich aus. Der Fallback belegt die Hostregel, nicht die Topologie.

Das bleibende Prinzip trennt Datum, lokale Entscheidung und Mandat. Antwort und Schweigen können Betrieb steuern, aber nicht von selbst das Recht erzeugen, andere zu konfigurieren.

Quellen und Grenzen

Der geschlossene Bestand umfasst RFC 950, RFC 1122, RFC 2131, RFC 2132, RFC 6918 und RFC 7279. Er belegt Design, Anforderungen, Koexistenz und Status, aber keine Verbreitung, Senderberechtigung, Herstellerkonformität oder Richtigkeit einer konkreten Maske.