Zusammenfassung

  • RFC 1877 ergänzte IPCP um vier Optionen für primäre und sekundäre DNS- und NBNS-Adressen. Vier Null-Oktette baten den Peer ausdrücklich um einen Wert im Configure-Nak.
  • Ein Nak war ein Gegenvorschlag, keine Annahme. Der Client musste den angebotenen Wert neu beantragen und dafür das passende Configure-Ack erhalten.
  • Selbst danach waren IPCP Opened, Route, Anfrage, Antwort, Datenautorität und Anwendungsnutzung eigenständige Nachweise.

Null bezeichnete fehlendes Wissen, nicht einen Server

Ein Einwahlrechner konnte IP-Pakete transportieren und trotzdem an gewöhnlichen Namen scheitern. Ihm fehlte eine Adresse für die nächste Frage. RFC 1877 fügte diese Information im Dezember 1995 dem Internet Protocol Control Protocol hinzu. Das als Informational veröffentlichte Dokument schuf keinen neuen Suchdienst, sondern erweiterte die vorhandene IP-Konfiguration über PPP.

Vier Typen bekamen feste Bedeutungen: 129 primäres DNS, 130 primäres NBNS, 131 sekundäres DNS und 132 sekundäres NBNS. Jede Option bestand aus Typ, Länge sechs und einer vier Oktette langen IPv4-Adresse. Im heutigen IANA-Register für PPP stehen diese Zuweisungen weiterhin. Ein Registereintrag belegt jedoch nur die Nummer, nicht eine aktuelle Implementierung oder Sitzung.

Der Quelltext selbst verlangt dennoch Vorsicht. In Abschnitt 1.3 nennt ein einzelner Satz der Feldbeschreibung einen primären NBNS-Server, obwohl Abschnittstitel, Diagramm und die Zuweisung von Typ 131 übereinstimmend sekundäres DNS bezeichnen. Dieser Widerspruch ist eine Grenze des Dokuments; er rechtfertigt nicht, den verirrten Satz zur Protokollsemantik zu erheben.

Der Client konnte 0.0.0.0 senden. Dieser Wert behauptete nicht, dass unter null ein Resolver liege. Er war die ausdrücklich definierte Bitte, der Peer möge im Configure-Nak eine Adresse nennen. Auch ein anderer bewusst ungültiger Wert konnte dieselbe Reaktion auslösen.

Die Ablehnung trug somit Information, ohne die Entscheidung des Clients zu ersetzen. Der entfernte Peer durfte sagen, welchen Wert er akzeptieren würde. Der lokale Peer musste erst noch entscheiden, ob er ihn erneut beantragt.

Der Nak gehörte nicht in die fertige Konfiguration

RFC 1877 übernahm Format und Verhalten der IP-Address-Option aus RFC 1332. Configure-Request enthielt den gewünschten Zustand. Configure-Nak lehnte darin enthaltene Werte ab und schlug andere vor. Configure-Reject gab eine unbekannte oder nicht verhandelbare Option unverändert zurück. Configure-Ack bestätigte den aktuellen Antrag unverändert.

Sendet der Client Typ 129 mit 0.0.0.0 und erhält 192.0.2.53 im Nak, sind Empfang, Verständnis und ein akzeptabler Vorschlag belegt. Die Übernahme ist es nicht. Dazu sendet der Client einen neuen Request mit 192.0.2.53. Erst der dazugehörige Ack macht aus dem Vorschlag eine Vereinbarung dieser Aushandlungsrunde.

Paketkennung und Reihenfolge gehören zum Beleg. Ein verspäteter Nak kann zu einem alten Versuch gehören, ein Ack kann doppelt eintreffen, ein neuer Request kann andere Werte enthalten. Wer nur das letzte Adressfeld speichert, verliert Urheber, Empfänger und Geltungszeit der Entscheidung.

RFC 1661 trennt darüber hinaus die Phasen des Links. Nach physischer Bereitschaft stellt LCP die Verbindung her. Eine verlangte Authentisierung muss enden. Danach folgt die Network-Layer-Protocol-Phase, in der jedes NCP separat geöffnet wird. Erst IPCP Opened lässt den zugehörigen IP-Verkehr zu. Die Bestätigung einer einzelnen DNS-Option ist nicht mit diesem Zustand identisch.

Vier gleiche Formen blieben zwei verschiedene Namenswelten

DNS in RFC 1034 und RFC 1035 verteilt Namen, Resolver, Server und Autorität. NBNS aus RFC 1001 und RFC 1002 gehört zur NetBIOS-Namenswelt über TCP/UDP. Das gemeinsame IPCP-Format verringerte Implementierungsaufwand, vereinheitlichte aber weder Anfragen noch Daten oder Vertrauen.

Primäre und sekundäre Adressen wurden unabhängig ausgehandelt. Waren beide vorhanden, sollte der Client die primäre zuerst versuchen. „Primär“ bezeichnete hier eine lokale Nutzungspräferenz. Es behauptete nicht, der genannte DNS-Server besitze die Masterkopie einer Zone. Gleichlautende Rollen aus verschiedenen Ebenen durften nicht zu einer Autoritätsaussage verschmolzen werden.

Teilzustände waren möglich: primäres DNS ohne sekundäres, DNS ohne NBNS oder Werte aus verschiedenen Versuchen. Es gab keinen atomaren Abschluss aller vier Optionen. Standardmäßig wurde für jede Option keine Adresse bereitgestellt. Fehlen war kein stiller Verweis auf einen geerbten Server.

Ein vereinbarter Wert konnte topologisch falsch liegen

RFC 1877 riet davon ab, die Optionen in die empfohlene IPCP-Liste aufzunehmen. Ihr Nutzen hing von der Topologie des entfernten Netzes und von der lokalen Anwendung ab. Eine syntaktisch gültige und akzeptierte Adresse konnte außerhalb der installierten Route liegen. Ein erreichbarer DNS-Dienst half keinem Programm, das NBNS erwartete. Eine Antwort konnte ankommen und trotzdem an lokaler Prüfpolitik scheitern.

Darum endet die Nachweiskette nicht mit dem Ack. Sie führt über IPCP Opened, Interface und Route, gesendetes Paket, erreichten Server, korrelierte Anfrage und Antwort, Prüfung von Autorität oder Integrität, Auswahl durch die Anwendung und sichtbares Ergebnis. Jeder Übergang hat einen anderen Produzenten.

Das Dokument behandelte Sicherheitsfragen nicht. Daraus entsteht weder Authentisierung des Peers noch Vertrauen in Server oder Antwort. Auch der Informational-Status und die fortbestehende IANA-Zuweisung beweisen keine allgemeine Unterstützung.

RFC 1877 war wertvoll, weil es die Grenze nicht überschritt. Es konnte eine Adresse zum Gegenstand überprüfbarer Zustimmung machen. Ob hinter dieser Adresse ein brauchbarer Namensdienst lag, musste die laufende Verbindung noch zeigen.