Zusammenfassung

  • RFC 4008 stellte Schnittstellen, Dienstkategorien und beschreibbare Parameter ins Zentrum der NAT-Verwaltung; RFC 7658 erklärt, warum diese Annahmen zu vielen Implementierungen nicht passten.
  • NATV2-MIB verkleinerte die gemeinsame Konfigurationsfläche und erweiterte zugleich die Sicht auf logische Instanzen, Adressbereiche, Teilnehmer, Pools und Zustand.

Die Schnittstelle als erste Voraussetzung

Wer dem Konfigurationsbeispiel der RFC 4008 folgt, beginnt nicht mit einer Übersetzungsregel. Zuerst entsteht in natInterfaceTable ein Eintrag mit einem vorhandenen ifIndex; der Betreiber ordnet die Schnittstelle einem privaten oder öffentlichen Adressbereich zu. Danach legt er Adresszuordnungen für dieselbe Schnittstelle an und setzt Standard-Timeouts. Die physische Schnittstelle ist damit der Startpunkt, an den sich ein beträchtlicher Teil des Modells anlehnt.

Das ist zunächst ein anschaulicher Entwurf. Pakete kommen über Schnittstellen an und verlassen das Gerät wieder; an diesen Rändern lassen sich verschiedene Adressbereiche unterscheiden. RFC 4008 verband deshalb Schnittstellen- und Zuordnungstabellen mit abgeleiteten Adress- und Portbindungen sowie einer Sitzungstabelle, die private und öffentliche Sicht auf eine Sitzung verband. Die MIB enthielt außerdem Statistiken und Timeout-Werte und sollte sowohl Konfiguration als auch Überwachung unterstützen. RFC 4008, Abschnitte 1 und 4

Die Schwierigkeit lag nicht in fehlender Detailtiefe, sondern in der Frage, welches Detail für alle Implementierungen gemeinsam sein konnte. NAT kann eine logische Funktion sein, die mehrere Schnittstellen überspannt. Eine Zuordnung kann zu einer Gruppe von Schnittstellen gehören oder intern gar nicht anhand einer Schnittstelle geführt werden. Verlangt das Managementschema dennoch genau diese Beziehung, muss sich das Gerät an die MIB anpassen, statt dass die MIB die Architektur des Geräts beschreibt.

Eine ungewöhnlich offene Rückschau

RFC 7658 nennt die Gründe für die Deprecation der Objekte aus RFC 4008. NAT-Algorithmen und Datenstrukturen unterschieden sich zwischen Implementierungen stark; dadurch entstanden inkompatible Konfigurationsparameter. Nur wenige Implementierungen konnten vollständige Konformität beanspruchen. Selbst lesbare Konfigurationswerte wie Timeouts erschwerten grundlegende Konformität. Die ausdrücklich formulierte Lehre lautet, eine MIB möglichst schreibgeschützt zu halten und nicht zur allgemeinen Offenlegung der NAT-Konfiguration zu machen. RFC 7658, Abschnitt 3

Die Schnittstellenbindung war ein konkreter Architekturkonflikt. RFC 7658 zufolge verfolgten viele NAT-Implementierungen die Schnittstelle einer Zuordnung nicht oder verbanden eine Zuordnung mit mehreren Schnittstellen. ifIndex strukturierte in RFC 4008 aber nicht nur die Schnittstellentabelle, sondern auch Zuordnungs-, Bindungs- und Sitzungstabellen. Fehlt diese Beziehung im internen Modell, kann die Implementierung die erwarteten Objekte nicht ohne Weiteres bereitstellen. Die Autoren zogen daraus den Schluss, NAT als logische, möglicherweise schnittstellenunabhängige Funktion zu behandeln.

Auch die Dienst- und Protokollbegriffe setzten zu enge Grenzen. RFC 4008 nutzte basicNat, napt, bidirectionalNat und twiceNat; RFC 7658 bezeichnet diese Kategorien als unscharf, weil Implementierungen andere Kategorien oder gar keine verwendeten. Das sind die Dienstlabels der alten MIB, nicht die Cone-NAT-Klassifikation der RFC 3489. Der Nachfolger verweist auf die Verhaltensbegriffe aus RFC 4787. Die geschlossene Protokollliste aus other, ICMP, UDP und TCP nutzte eigene Zahlenwerte und ließ beispielsweise DCCP und SCTP schlecht abbilden. NATV2-MIB greift stattdessen auf die IANA-Protokollnummern zurück.

Zwei Dokumente für einen Modellwechsel

2015 wurde der Wechsel in zwei Standards abgebildet. RFC 7658 behält die Definitionen von RFC 4008 bei, kennzeichnet die Objekte aber als deprecated. RFC 7659 definiert NATV2-MIB. Die alten Objektkennungen werden nicht stillschweigend mit neuer Bedeutung versehen. RFC 7658 RFC 7659

NATV2-MIB ist vor allem für Monitoring gedacht. Schreibgeschützte Konfiguration bleibt nur so weit enthalten, wie sie zur Interpretation von Zustand und Statistiken nötig ist. Beschreibbare Konfiguration entfällt weitgehend; ausgenommen sind Steuerung der Benachrichtigungen und Quoten für NAT-Ressourcen. Kontrolle verschwindet also nicht vollständig: Schutzgrenzen können gesetzt werden. Die MIB verspricht jedoch nicht länger eine universelle Konfigurationsoberfläche für unterschiedliche Übersetzungsmaschinen.

Das Modell rückt die logische NAT-Instanz ins Zentrum. Zuordnungen werden nicht mehr hauptsächlich über Schnittstellen organisiert. Ein Gerät kann mehrere NAT-Instanzen und beliebig viele Adressbereiche abbilden; die Tabellen erfassen außerdem Protokolle, Pools, Teilnehmer, Zustand, Statistiken und Benachrichtigungen. Diese Dimensionen sind für CGN relevant, weil öffentliche Adressen und Ports von vielen Teilnehmern geteilt werden und Ressourcen je Instanz betrachtet werden müssen.

Die Indizierung von Portzuordnungen wurde ebenfalls überarbeitet. Ziel ist, von außen sichtbaren Paketparametern leichter zum zugehörigen internen Endpunkt zurückzufinden. Das ist eine Management- und Suchhilfe, aber kein Nachweis der Teilnehmeridentität, der Paketzustellung oder des Erfolgs einer Anwendung. RFC 7659, Abschnitte 2 und 3

RFC 6888 beschreibt den Ressourcenhintergrund: Bei CGN konkurrieren Teilnehmer um Ports und Zustand; Teilnehmergrenzen können übermäßigen Verbrauch gemeinsamer Ressourcen begrenzen. NATV2-MIB kann solche Grenzen und Teile des Zustands darstellen. Die RFCs sagen jedoch nicht, welche Betreiber die Objekte tatsächlich nutzten, wie sie Schwellenwerte festlegten oder welche Ergebnisse sie erzielten. RFC 6888, Abschnitte 4 und 5

Was die Normungsgeschichte zeigt

Die NAT-MIB wurde auf der Abstraktionsebene korrigiert. RFC 4008 versuchte, NAT über eine portable Tabellenhierarchie konfigurierbar zu machen. RFC 7658 dokumentierte, warum Schnittstellenbindung, Konfigurationsparameter, Dienstkategorien und eine geschlossene Protokollliste vielen Implementierungen nicht entsprachen. RFC 7659 verkleinerte daraufhin die gemeinsame Schreibfläche und erweiterte die Sicht auf logische Instanzen und geteilte Ressourcen.

Die belegbare Schlussfolgerung bleibt begrenzt: Das Managementmodell änderte sich, um mehr Arten von Implementierungen beschreiben zu können. Daraus folgt weder, dass alle Hersteller NATV2-MIB übernahmen, noch dass sie universell verbreitet wurde oder die Übersetzungsleistung verbesserte. RFC 7659 sagt, die frühere MIB sei nur wenig implementiert worden, nennt aber keine Quote und misst auch die Verbreitung des Nachfolgers nicht.

Die Grenze zu Firewalls ist ausdrücklich. RFC 4008 und RFC 7658 sagen, dass diese MIBs keine Firewallfunktionen behandeln und nicht zu deren Konfiguration oder Überwachung verwendet werden dürfen. Ein Übersetzungseintrag ist keine Filterregel.

Auch ein Managementobjekt ist kein Dienstergebnis. Ein konfigurierter Pool ist kein aktiver Eintrag; ein Teilnehmerindex ist keine bestätigte Identität; ein Zähler braucht seinen Discontinuity-Kontext; eine Benachrichtigung beweist keine Paketzustellung. NATV2-MIB kann die Managementsicht ordnen, aber Konfiguration, Zustand, Weiterleitung, Identität und Anwendungsergebnis nicht zu einem einzigen Beleg zusammenziehen.

Die historische Lehre ist konkret: Ein Managementstandard wird zu weitgehend, wenn er implementierungsspezifische Steuerung als gemeinsame Schnittstelle festschreibt. RFC 7658 reagierte nicht mit weiteren Schnittstellenfeldern, sondern stellte die modellierte Einheit infrage. Der Nachfolger machte weniger Konfiguration universell, aber mehr logischen Kontext beobachtbar. Die Frage lautete nicht mehr nur, welche Schnittstelle eine Zuordnung besitzt, sondern welche NAT-Instanz, welcher Bereich, welcher Teilnehmer, welcher Pool und welcher Zustand durch eine Beobachtung beschrieben werden.

Quellen