Summary

  • RFC 1383 schlug vor, ein Zugangsgateway zu einem mehrfach angebundenen Randnetz per Reverse-DNS zu finden, statt dessen sämtliche internen Netze global anzukündigen.
  • Der beschriebene Prototyp wartete auf ICMP „Destination Unreachable“, bevor er DNS befragte. Laut RFC konnte so das erste Paket verloren gehen; ein gelistetes Gateway war noch kein Beleg für einen erreichbaren Pfad.

Ein Paket geht auf die Reise. Der Router kennt das Zielnetz nicht und meldet es als unerreichbar. Erst jetzt fragt ein anderes Programm DNS nach einem möglichen Eingang. Christian Huitemas RFC 1383 vom Dezember 1992 machte aus einer Fehlermeldung den Startschuss für die Wegsuche. So ließ sich die Idee neben dem gewöhnlichen IP-Routingcode erproben. Das erste Paket stand auf der Verlustliste.

Die damaligen Tabellen wuchsen. Huitema nannte mehr als 5.000 Netze in den NSFNET-Routen und mehr als 7.000 in EBONE. Jede weitere Ankündigung verbrauchte Speicher in Transitroutern, Platz in Routingmeldungen und Aufmerksamkeit für neue Richtlinien. Hierarchische Adressvergabe und Aggregation konnten helfen. Ein Kunde mit zwei Zugangsprovidern wollte seine Adressen aber möglicherweise behalten, statt sich an den Adressraum eines Providers zu binden.

Die Idee ähnelte dem MX-Eintrag für Post. Ein Randbereich D hätte zwei von außen sichtbare Gateways, I1 und I2. Diese kannten D intern, ohne jedes Teilnetz in globale Tabellen zu exportieren. Eine Quelle sollte per in-addr.arpa das Ziel nachschlagen, experimentelle RX-Angaben lesen, ein Gateway wählen und das Paket mit einer Quellroute dorthin führen. Der frühe Test verwendete dafür einen TXT-Eintrag mit RX, Präferenz und Gateway-IP. Einen endgültigen DNS-Typ gab es noch nicht.

Die Entscheidung sollte am Anfang fallen. Würde jeder Transitrouter DNS fragen, müsste man alle umrüsten. Unterschiedliche Antworten könnten ein Paket abwechselnd zu I1 und I2 lenken und Schleifen schaffen. Die Quelle oder ein naher Router wählte einmal und hielt den Weg konsistent. Mehrere Gateways verringerten Ausfallrisiko und Abhängigkeit von einem Anbieter. Aber DNS meldete eine mögliche Tür, keinen aktuellen Funktionstest. Bekanntermaßen unerreichbare Gateways mussten gestrichen werden; wie schnell diese Erkenntnis verfügbar war, blieb offen.

Auch die DNS-Information brauchte einen Weg. D musste seine RX-Daten auf Nameserver replizieren, die aus dem Kern des Internets erreichbar waren. Ein Wegweiser hinter der verschlossenen Tür hilft dem Absender wenig. Der beschriebene Forwarder stellte Pakete während der Suche an und ließ ihre Lebenszeit weiter ablaufen. Ohne RX-Antwort verwarf er die wartenden Pakete und markierte das Ziel als unerreichbar.

RFC 1383 empfahl die direktere Einbindung in IP-Routing, falls dessen Code geändert werden konnte: Dann müsste das erste Paket keinen ICMP-Fehler auslösen. Der RFC-Editor-Eintrag führt das Vorhaben als Experimental; die Schlussfolgerung meldete den Code noch in Entwicklung bei INRIA. Dazu kam eine Preisfrage. Kosten für eigenständige Routenankündigungen könnten Kunden in Provideradressen drängen; RX war als Alternative gedacht.

Der gemeinsame Routingzustand wäre kleiner, die Verantwortung der Quelle größer. DNS konnte ein Gateway nennen. Ob dieses Gateway Pakete tatsächlich lieferte, musste der Betrieb erst beweisen.

Sources