Zusammenfassung
- Am Eingang sollte DNS Adressen autonomer Domänen liefern. Ein äußerer IP-Header trug das unveränderte Datagramm bis zum Ausgang, wo die Hülle entfernt wurde.
- Keine Host-Änderung bedeutete verlagerten Aufwand: neue DNS-Zuordnung, Domänenadressen und -routen, besondere Grenzverarbeitung und zwanzig zusätzliche Bytes je Transitdatagramm.
- RFC 1955 war Informational und erklärte, Veröffentlichung bedeute keine Annahme durch IPng. Der Entwurf setzte global eindeutige innere IPv4-Adressen voraus und behandelte Sicherheit nicht.
Die alte Adresse reiste in einem neuen Ziel
Der Host hätte weiterhin ein gewöhnliches IPv4-Paket erzeugt. Der erste Grenzrouter sollte innere Quelle und Ziel lesen, dazu AD-Adressen nachschlagen und einen äußeren IP-Header bauen. Im Transit war das alte Datagramm Nutzlast. Der letzte Grenzrouter entfernte die äußere Schicht und übergab das Original wieder normalem Routing.
Die Nichtübersetzung war Absicht. Ein Übersetzer ändert Adressen, Prüfsummen und unter Umständen Angaben in Anwendungsdaten. ENCAPS ließ diese Bytes stehen. Es brauchte dennoch Zuordnung, Ausgangswahl, äußere Route und eine verlässliche Stelle zum Entfernen.
Das Dokument erschien im Juni 1996, beschreibt den Vorschlag aber als Nachricht an die ROAD-Gruppe vom Januar 1992, ursprünglich per E-Mail. Später wurde er im Rahmen der IPng-Papiersammlung eingereicht. Der Text setzt selbst die Grenze: Seine Veröffentlichung drückte keine Zustimmung des IPng-Bereichs aus.
Damit ist ein Entwurf belegt, kein Betrieb.
Die Zwischenlösung musste früher fertig sein
Die damalige Krise hatte verschiedene Fristen. Class-B-Nummern wurden knapp, Routingtabellen und deren menschliche Pflege wuchsen, während die vollständige Erschöpfung des IPv4-Raums weiter entfernt lag. Eine perfekte Gesamtlösung konnte für das nähere Problem zu spät kommen.
ROAD verlangte deshalb parallele Phasen. Kurzfristige Maßnahmen durften Hosts nicht verändern; langfristige Arbeit musste trotzdem sofort beginnen. ENCAPS bezeichnete sich ausdrücklich als mittelfristig. Der Entwurf wollte der bestehenden Internet-Schicht Zeit kaufen, nicht für immer gelten.
Seine Zielsetzung war breit: keine Änderungen an Hosts und den meisten Routern, keine neuen Internet- oder Routingprotokolle, keine Adressübersetzung, bestehende Adressstruktur und kleinere Tabellen. Doch die Quellen enthalten keine Installation, Messung oder Interoperabilitätsprüfung. Eine behauptete Eigenschaft bleibt ein Prüfauftrag für laufende Implementierung.
DNS lieferte die äußere Topologie
Der Eingangsrouter sollte zu innerer Quelle und Ziel die AD-Adressen ermitteln. Diese wurden äußere Quelle und äußeres Ziel. Das Domänenrouting musste daher nicht jedes innere Netz kennen.
RFC 1955 schlug vor, wenige Class-A- und Class-B-Netze für AD-Kennungen zu reservieren. Mehrere Bereiche könnten Domänen zu „commonwealths“ ordnen. Innerhalb einer Gruppe blieb Detailwissen, andere Gruppen erschienen zusammengefasst.
Grenzrouter würden passende AD-Adressen in das interne Routing von Transitdomänen einspeisen. Gewöhnliche Router konnten sie wie vertraute IP-Ziele weiterleiten. BGP, IS-IS oder OSPF galten als mögliche Berechnungsverfahren.
Kompatibilität entstand also nicht durch vollständiges Verständnis, sondern durch eine ausführbare Darstellung. Ein alter Router konnte die neue Bedeutung tragen, ohne sie zu kennen.
DNS und Routing mussten trotzdem übereinstimmen. Eine richtige Zuordnung ohne erreichbaren Ausgang war nutzlos; eine erreichbare äußere Adresse mit veralteter Zuordnung führte falsch. Selbst der erreichte Ausgang bewies noch keine innere Zustellung.
Unveränderte Bytes beseitigten keinen Zustand
Der zeitgenössische NAT-Entwurf zeigt die andere Möglichkeit. Übersetzung verlangt Änderungen an IP- und TCP-Prüfsummen, Tabellenzustand und Wissen über Adressen in Anwendungen; Verschlüsselung kann die Anpassung verhindern. ENCAPS wich diesen Eingriffen durch Erhaltung des inneren Pakets aus.
Es blieb aber abhängig von Mapping, AD-Zuweisung, Außenroute und Ausgang. Ein unverfälschtes Paket kann am falschen Ort unverfälscht ankommen.
Hinzu kam die Annahme, innere IPv4-Adressen blieben lange global eindeutig. RFC 1955 erwog ein Paar aus AD- und IP-Adresse als künftige globale Kennung. Sollten Hosts unverändert bleiben, wäre dafür NAT am Rand nötig. Sollte NAT vermieden werden, müssten Hosts selbst nachschlagen und kapseln.
Der Entwurf beseitigte die Entscheidung nicht. Er zeigte, welche ursprüngliche Zusage bei der nächsten Erweiterung aufgegeben werden müsste.
Zwanzig Bytes waren nur die sichtbare Rechnung
Genannt wurden zwanzig Bytes äußerer IP-Header und zusätzliche Arbeit an Ein- und Ausgang. Schwieriger zu messen waren neue DNS-Einträge, Verteilung der Domänenkennungen, Gruppierungsregeln, Grenzsoftware und Fehleranalyse über zwei Routen.
Cache-Lebensdauer, negative Antworten, Authentisierung der Zuordnung, einseitige Umstellung, Pfad-MTU, Fragmentierung, ICMP-Zuordnung und Ausstieg blieben unvollständig. Sicherheit wurde nicht diskutiert. Das beweist keine Unmöglichkeit; es beweist nur, dass ein Architekturblatt kein Betriebsnachweis ist.
Spätere Regeln für IP-in-IP und die erste IPv6-Spezifikation erlauben einen Vergleich der Fragen. Sie belegen keine direkte Abstammung von ENCAPS.
CIDR verlagerte andere Kosten
CIDR bekämpfte Tabellenwachstum über topologische Vergabe und aggregierbare Präfixe. Kosten entstanden in Vergabepolitik, Protokollfähigkeit, Providerbindung und Renummerierung. Es fügte nicht jedem Transitpaket eine AD-Hülle hinzu.
ENCAPS baute eine zweite Zielhierarchie um die bestehende. Beide Entwürfe wollten Zeit gewinnen, belasteten aber andere Kontrollflächen. Der Begriff Aggregation reicht nicht: Entscheidend ist, wer Tabellen pflegt, Pakete ändert, Adressen umstellt, Ausnahmen trägt und den Rückweg besitzt.
Vorschrift, Konfiguration und Ergebnis trennen
Running-Code-Primat ordnet die Beweise. Ein RFC belegt den Text. Ein DNS-Eintrag hätte Zuordnung belegt. Eine Grenzkonfiguration hätte lokale Bereitschaft gezeigt. Ein äußerer Header hätte die Kapselung an einem Messpunkt gezeigt. Ausgang, Entkapselung, innere Weiterleitung und Anwendungsergebnis brauchten eigene Nachweise.
Minimale Anfangsspezifikation kann eine Erprobung auf freiwillige Grenzen beschränken. Sie bleibt nur dann lokal, wenn Ablehnung, normaler Pfad und Rücknahme funktionieren. Wird die gemeinsame Zuordnung zur Bedingung der Gültigkeit, ist aus Hilfe Autorität geworden.
Die Realitätsschichten bleiben verschieden: vorgeschlagene Nummer, veröffentlichte Zuordnung, Cachezustand, emittierte Hülle, ausgeführte Route und empfangener Dienst. RFC 1955 ist historisch wertvoll, weil es diese Übergänge sichtbar macht, ohne Erfolg zu bescheinigen.
Quellen und Grenzen
Identität und Status liefert der RFC-Editor-Eintrag zu RFC 1955, den Mechanismus RFC 1955. Die ROAD-Lage beschreibt RFC 1380, das IPng-Verfahren RFC 1550. Die getrennte CIDR-Strategie steht in RFC 1519, der Übersetzungsvergleich in RFC 1631. Ohne Abstammung zu behaupten, begrenzen die erste IPv6-Spezifikation und IP in IP spätere Vergleiche. Der analytische Rahmen folgt Running-Code Primacy, Minimum Initial Specification und Reality Layers.
Die Quellen belegen Vorschlag und begrenzte Vergleiche, nicht IPng-Annahme, Standardisierung, Implementierung, Einsatz, Verbreitung, Leistung, Interoperabilität, Sicherheit, Betreiber, realen Verkehr, heutiges Produkt oder kausale Linie.
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
