Zusammenfassung
- ATMP ließ gewöhnliche PPP- oder SLIP-Clients eine Heimnetzadresse nutzen, während ein entfernter NAS/Foreign Agent und ein Home Agent den Tunnel unsichtbar betrieben.
- Registrierung, CHAP-ähnliche Prüfung eines gemeinsamen Geheimnisses, eine paarlokale Tunnel ID und GRE erzeugten für IP oder IPX das Betriebsbild eines lokalen Anschlusses.
- Adresse, erfolgreiche Antwort und GRE Key belegten begrenzten Protokollzustand, nicht physischen Ort, Person, Anwendungsberechtigung, Zustellung oder IETF-Konsens.
Zuhause war eine Routingentscheidung
1997 konnte sich ein Nutzer in einen entfernten Network Access Server einwählen und dennoch eine Adresse seines Heimnetzes zeigen. Die Telefonleitung endete anderswo; das Routing erzählte „zu Hause“.
Dieser Widerspruch beschreibt ATMP. Das Protokoll bewegte den Rechner nicht. Ein Foreign Agent im NAS registrierte den Client bei einem Home Agent im Heimnetz. Beide transportierten den Verkehr durch einen Tunnel, damit andere Systeme den Client wie lokal angeschlossen behandeln konnten.
Der Client führte kein ATMP aus; gewöhnliches PPP oder SLIP genügte. NAS und Home Agent beherrschten die Mechanik. Vereinfachung am Rand bedeutete, Routingurteil an der Grenze zu konzentrieren.
Die Heimadresse konnte im Client konfiguriert, einer Nutzerkennung zugeordnet oder einem Pool entnommen werden. Der RFC ließ Zuteilung und Aktivierungsentscheidung des NAS ausdrücklich offen. ATMP konnte die ausgewählte Adresse tragen, aber nicht beweisen, wer die Wahl erlaubte oder ob sie noch zum richtigen Nutzer gehörte.
Registrierung stellte den Anschluss her
Das mobility binding verband Home Address, IP-Adresse des Foreign Agent und Tunnel ID. Es war keine Geografie, sondern eine kompakte Routinganweisung.
Der Foreign Agent bezog Home-Agent-Adresse und Geheimnis aus seiner Konfiguration. Alle zwei Sekunden sandte er eine Registration Request. Nach zehn unbeantworteten Versuchen protokollierte er das Scheitern und trennte den Client.
Der Home Agent sandte eine Challenge. Der Foreign Agent verband Authenticator und Geheimnis, berechnete MD5 und antwortete. Der Home Agent wiederholte die Rechnung. Übereinstimmung erlaubte Annahme; Fehler oder Ressourcenmangel ergaben einen anderen Result Code.
Authentifiziert wurde eine konfigurierte Beziehung zwischen Agenten. Die Person am Modem wurde nicht identifiziert, eine Anwendungshandlung nicht erlaubt und die Nutzlast nicht verschlüsselt. „Ähnlich CHAP“ bezeichnete die Bauform, nicht einen größeren Beweisumfang.
Tunnel ID machte Zustand zum Pfad
Nach Annahme vergab der Home Agent eine nur im FA–HA-Paar eindeutige ID. Er verband sie in einem control block mit Routinginformationen; der Foreign Agent speicherte sie bei der Clientsitzung.
Daten liefen in GRE, die ID im Key-Feld. Der Home Agent fand damit den Routingkontext; der Foreign Agent ordnete Pakete aktiven Clients zu. Eine unbekannte ID löste Error Notification und stilles Verwerfen aus.
So wurde die Autoritätsverschiebung sichtbar. Der Client lieferte Verkehr, die Agenten bestimmten Heimkontext, lokalen Zustandsnamen und Fortbestand der Verbindung. Die Adresse wirkte stabil, weil control blocks den physischen Wechsel auffingen.
IPX zeigte den Zusatzaufwand. Die Tunnelsteuerung blieb auf IP angewiesen. Jeder Home Agent brauchte eine unternehmensweit eigene IPX-Netznummer außerhalb seiner LANs; Clients teilten die Nummer und benötigten dennoch eindeutige Knotenadressen. Portabilität einer Schicht verlangte neue Koordination in einer anderen.
Abbau gehörte zur Wahrheit
Virtuelle Präsenz bestand nur bei gemeinsamem Lebenszyklus. Deregistration Requests wurden alle zwei Sekunden wiederholt. Eine gültige Antwort entfernte das binding und gab die ID frei. Nach zehn Fehlschlägen wurde der Fehler protokolliert und der Client dennoch getrennt.
Damit konnte der Client lokal verschwunden sein, bevor der entfernte Zustand bestätigt gelöscht war. Nach einem Neustart konnte eine ID auf einer Seite gelten und auf der anderen fehlen. Betriebswahrheit war die Übereinstimmung zweier control blocks, der Wiederholungshistorie, des aktuellen Anschlusses und der tatsächlichen Paketbehandlung – nie ein einzelnes Feld.
Privates Protokoll, öffentliche Geschichtslektion
Die IESG Note war eindeutig: RFC 2107 dokumentierte ein privates Protokoll, kein Ergebnis einer IETF-Arbeitsgruppe und keinen Standards-Track-Text. Datatracker bezeichnet es heute als Legacy ohne formalen Rang im IETF-Standardisierungsprozess.
Gerade das macht die Quelle wertvoll. Vor L2TP machte eine Produktarchitektur Netzwerkort portabel, indem sie Zustand zwischen Zugang und Heimnetz zentralisierte, diese Grenze authentifizierte und dem Tunnel einen lokalen Namen gab. Mobile IP behandelte breitere Bewegung; L2F und L2TP trennten Einwahl und Linkabschluss; GRE lieferte die Hülle. ATMP kombinierte einen engeren Satz. Die RFC-Nummer bewahrte das Design, sie machte Einsatz nicht zu Konsens.
Quellen
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
