Zusammenfassung

  • NAT konnte an einer Netzgrenze global eindeutige IPv4-Adressen einsparen. Anwendungen, die Adresswerte voraussetzten, brauchten jedoch mehr als eine Umschreibung des IP-Headers.
  • Die historische Warnung von RFC 2993 betraf die Verteilung der Restarbeit: Anwendungsgateways, abgestimmte Änderungen auf Endsystemen, lokale Namensverwaltung und Support – nicht nur ein Gerät im Routerpfad.

Ein Übersetzer kann seine konfigurierte Umschreibung korrekt ausführen und eine Anwendung dennoch ohne Verbindung zurücklassen. Die Übersetzungstabelle muss nicht fehlerhaft sein. Das Problem kann entstehen, wenn dieselbe Adresse im privaten Netz ein Gerät bezeichnet, außen in einen anderen Wert übersetzt wird und im Nachrichtentext der Anwendung eine weitere Kopie stehen bleibt.

Diese Spannung war schon im Vorschlag von 1994 angelegt. RFC 1631 stellte Network Address Translation als schrittweise Antwort auf den Druck bei IPv4-Adressen vor: Netze am Rand konnten interne Adressen wiederverwenden, während ein Grenzgerät nur den Verkehr übersetzte, der in den globalen Adressraum hinausging. Das Dokument benannte auch den Tausch: Die Ende-zu-Ende-Bedeutung einer IP-Adresse nahm ab, dafür entstand zusätzlicher Zustand im Netz. Bei mehreren Ausgängen mussten die Übersetzer dieselben Zuordnungen konsistent verstehen. Das war eine praktikable Brücke, keine kostenfreie Architektur.

Im November 2000 betrachtete Tony Hain in RFC 2993 sechs Jahre wachsendes Interesse und zunehmende Nutzung von NAT. Die Frage lautete nicht mehr nur, ob ein Router eine Adresse durch eine andere ersetzen konnte. Entscheidend war, ob ein Dienst weiter funktionierte, wenn die Adresse an einer Stelle auftauchte, die der Übersetzer nicht untersuchte.

Die Antwort hing von der Anwendung ab. Eine einfache Verbindung zwischen zwei Endpunkten über ein einzelnes NAT ließ sich womöglich bewältigen. Manche Protokolle führten IP-Adressen jedoch in ihrer Nutzlast mit; andere setzten für Prüfsummen, Authentisierung oder Sicherheitsverarbeitung einen konsistenten Header voraus. Ein Übersetzer, der nur den Header betrachtet, konnte nicht all diese Annahmen korrigieren. Application Layer Gateways (ALGs) und Proxys konnten helfen, mussten dafür aber das jeweilige Protokoll verstehen. RFC 2775 hatte früher im selben Jahr Ähnliches festgehalten: Für eine neue adressabhängige Anwendung musste auch das ALG oder der Proxy aktualisiert werden.

„Transparent“ wurde damit zu einem bedingten Versprechen. Wenn eine Anwendung die übersetzte Adresse weder offenlegte noch von ihr abhing, konnte die Grenzfunktion unbemerkt bleiben. Andernfalls musste jemand die Umgehungslösung an allen Orten koordinieren, an denen die Anwendung lief. RFC 2993 stellte den relativ einfachen Fall mit zwei Endpunkten redundanten NAT-Pfaden und Mehrpunktanwendungen wie gemeinsam bearbeiteten Dokumenten gegenüber. Der Koordinationsaufwand wachse geometrisch mit der Zahl der Endpunkte, heißt es dort.

Das Dokument liefert weder Gleichung noch gemessene Kostenkurve; es beschreibt ein Architekturproblem der Skalierung, kein Versuchsergebnis.

Redundanz brachte eine weitere Zustandsabhängigkeit. Zwei Übersetzer auf alternativen Pfaden mussten die Zuordnungen eines Geräts einheitlich verstehen. Blieb der Verbindungszustand auf einem Pfad zurück und wechselte der Verkehr auf den anderen, konnte dort eine neue Zuordnung entstehen. Die Rückkehr zur ursprünglichen Route stellte die Unterhaltung nicht zwingend wieder her. Die Paketadresse war also nicht der gesamte Zustand; auch die NAT-Zuordnung und ihre Position im Pfad zählten.

Die Kosten konnten zwischen Organisationen wandern. RFC 2993 merkte an, dass ein vom Internetanbieter betriebenes NAT dessen Support an einer Stelle vereinfachen, zugleich aber die lokale Adress- und Namensverwaltung ausweiten könne. Das ist eine im Dokument beschriebene Lastverschiebung, keine Messung eines überall gestiegenen Gesamtkostenwerts. Nach einer Fusion musste die lokale Administration womöglich doppelt verwendete private Adressen bereinigen, interne und externe DNS-Antworten abstimmen oder eine Anwendungskorrektur koordinieren, die für den Anbieter zuvor unsichtbar war.

Bei Sicherheit wurde der Unterschied zwischen Übersetzung und Zugriffspolitik besonders wichtig. RFC 2993 warnte, NAT – vor allem Port Address Translation – könne den Eindruck einer Sicherheitsgrenze erwecken, ohne die ausdrücklich beabsichtigte Zugriffskontrolle einer Firewall. Das Dokument erörterte außerdem Kompatibilitätsprobleme bei IPsec, DNS-Verhalten und SNMPv3-Authentisierung. Diese Mechanismen hängen von Protokoll und Konfiguration ab; sie beweisen nicht, dass jedes NAT jedes Sicherheitsprotokoll unwirksam macht. Der Übersetzer verändert adressabhängige Nachweise, entscheidet aber nicht selbst, welcher Verkehr erlaubt ist.

Spätere Dokumente machten die Arbeit sichtbarer, belegen aber nicht ihr Verschwinden. RFC 3022 ersetzte 2001 RFC 1631 mit einer Beschreibung des traditionellen NAT. RFC 3235 veröffentlichte 2002 Hinweise für NAT-freundliches Anwendungsdesign. Daraus folgt weder, dass RFC 2993 eine bestimmte Einführung verursachte, noch dass jede Software diese Hinweise befolgte. Sichtbar wird, dass eine Grenztechnik eine eigene Literatur zum Anwendungsdesign hervorbrachte.

Der historische Beitrag von RFC 2993 ist kein Urteil, dass NAT immer scheitert. Er trennt die Adressersparnis an der Grenze von der darüber hinaus nötigen Kompatibilitätsarbeit. Der Übersetzer konnte an einem Gateway sitzen; die Reparatur konnte Updates auf vielen Endpunkten, konsistenten Zustand über mehrere Pfade und lokale Kontrolle über Namen erfordern. Das Netz ließ die Arbeit nicht verschwinden. Es änderte, wer sie bemerken und koordinieren musste.

Quellen