HIPL unterstützt auch die Initiierung einer Verbindung aus einen Netzwerk hinter NAT. Die grundlegende Idee ist das der Initiator die HIP Steuerpakete und ESP Daten in UDP Pakete kapselt. Auf diesem Weg können die Pakete die NAT Box durchqueren. Um dies zu ermöglichen müssen aber Initiator und Responder die NAT Erweiterung unterstützen. Zur Zeit kann ein Responder nicht hinter NAT lokalisiert werden.
Experimente mit NAT können in einem ähnlichem Weg wie bereits in
einem vorherigen Abschnitt beschrieben durchgeführt werden. Der
einzige Unterschied ist, dass Sie dem Initiator manuell über den NAT
Status informieren müssen - verwenden Sie dazu hipconf hip
nat on. Danach können Sie den Base Exchange gemäß der
vorherigen Anweisung initiieren. Die manuelle Konfiguration ist zur
Zeit noch notwendig, da die automatische NAT Erkennung (STUN) noch
nicht implementiert ist.
Wenn Sie Probleme mit der Verwendung des NAT Codes habe um die I1
aufzunehmen (z.B. mit conntest-client-gai
(ereignet sich mit Kernel 2.6.16.5)), dann könnten Sie den Quell-HIT
Explicit angeben. Das Verfahren zum Initiieren einer Verbindung
hinter NAT ist folgendes:
tools/hipconf hip nat on
tools/hipconf add map peer_hit peer_ipv4_addr
ping6 -I source_hit dst_hit
Stellen Sie sicher, dass die Quelle ist die selbe wie in der
ip xfrm policy Ausgabe.
Wir sind uns des Problems bewußt (siehe BugID 161) und es wird
gelöst.
Auch scheint es, das der Responder nicht automatisch die Pakete zum
NAT routet, so dass ein ip route add nat_ipv4_addr dev
xx am Responder notwendig wird (ereignet sich mit Kernel
2.6.16.5).
Drei Fälle von Mobilität des Initiators wurden in den NAT Code implementiert.
Mobilität ausgehend hinter einem NAT hinter das selbe NAT: Für diesen Fall, das Standardverfahren zum Update nach dem Base Exchange, ist die Prozedur vollständig. Das Update wird in UDP Pakete gekapselt.
Mobilität von öffentlich adressiertem Netzwerk hinter ein NAT
Netzwerk:
Wenn eine HIP Verbindung zwischen zwei Hosts errichtet werden
soll, bei welcher sich beide in einem öffentlichem Netzwerk
befinden und einer in ein NAT Netzwerk wechseln soll, dann sollte
der Knoten zuerst die öffentliche Adresse löschen, die NAT
Erweiterung durch hipconf aktivieren und
dann die NAT-IP-Adresse und Route an die Schnittstelle binden.
Das Update wird ab dann auf UDP basieren und die zukünftige
Kommunikation in UDP gekapselt (beides, HIP Steuerung und
ESP-Pakete).
Mobilität von NAT Netzwerk zum öffentlich adressiertem Netzwerk:
Wenn ein Knoten eines NAT Netzwerks eine HIP Verbindung etabliert
hat und nun in ein Netzwerk mit öffentlichen IP Adressen wechseln
soll dann sollte die private IP Adresse zuerst gelöscht, die NAT
Erweiterung abgeschalten (verwende hipconf)
und anschließend die öffentliche IP Adresse inkl. Route gesetzt
werden. Danach wird die HIP Verbindung nicht mehr UDP gekapselte
Pakete senden. Auch die Update Funktion wird normale HIP Pakete
ohne UDP-Kapselung verwenden.