| IPv6-Übergangsmechanismen |
|---|
| Standards Track |
| Experimental |
| Informations |
| Entwürfe |
| Veraltet |
Anything In Anything ( AYIYA ) ist ein Netzwerkprotokoll zur Verwaltung von IP- Tunneling-Protokollen zwischen getrennten IP- Netzwerken. Es wird häufig verwendet, um IPv6- Transit über eine IPv4- Netzwerkverbindung zu ermöglichen, wenn die Netzwerkadressübersetzung (NAT ) ein privates Netzwerk mit einer einzigen IP-Adresse maskiert , die sich aufgrund der DHCP- Vergabe durch Internetdienstanbieter häufig ändern kann .
Merkmale
Das Protokoll weist folgende Merkmale auf: [ 1 ]
- Tunneln von Netzwerkprotokollen innerhalb eines anderen IP-Protokolls
- Die Netzwerksicherheit wird dadurch gewährleistet, dass verhindert wird, dass getunnelte Pakete gefälscht oder wiedergegeben werden können.
- Transparente Handhabung der Netzwerkadressübersetzung
- Der Endpunkt von mindestens einem der beiden Tunnelendpunkte sollte veränderbar sein, um Mobilitätsfunktionen bereitzustellen.
Tunnelmakler
Viele Verbrauchernetzwerke werden von Internetdienstanbietern mittels Network Address Translation (NAT) bereitgestellt, was die Nutzung von IP-Protokoll-41- Tunneln ( IPv6- Tunnel in IPv4 gemäß RFC 4213 oder RFC 3056) ausschließt [ 2 ] [ 3 ] [ 4 ] , sofern die NAT-Einstellungen nicht manuell angepasst werden. In manchen Fällen ist dies unmöglich, da die NAT nicht so konfiguriert werden kann, dass Protokoll 41 an einen bestimmten Host weitergeleitet wird. Problematisch sind auch Fälle, in denen sich mehrere Endpunkte hinter derselben NAT befinden, mehrere NATs verwendet werden oder der Benutzer keinerlei Kontrolle über die NAT-Konfiguration hat. Diese Situation behindert die Verbreitung von IPv6, das eigentlich die durch NATs verursachten Unterbrechungen der Ende-zu-Ende-Kommunikation lösen sollte. NATs wurden ursprünglich aufgrund des begrenzten Adressraums eingeführt.
Dieses Problem lässt sich durch Tunneln der IPv6-Pakete über das User Datagram Protocol (UDP), das Transmission Control Protocol (TCP) oder das Stream Control Transmission Protocol (SCTP) lösen. Da sich mehrere separate Endpunkte hinter demselben NAT befinden können oder der öffentliche Endpunkt eine neue IP-Adresse erhält, ist es erforderlich, den Ursprung bestimmter Pakete zu identifizieren. Endpunkte müssen zudem in der Lage sein, beispielsweise die Quelladresse des Transportprotokolls dynamisch zu ändern, ohne dabei als derselbe Endpunkt identifizierbar zu bleiben. AYIYA ist unabhängig vom Transport- und Nutzdatenprotokoll. Ein Beispiel hierfür ist IPv6-in-UDP-in-IPv4, eine typische Konfiguration, die von IPv6- Tunnelbrokern verwendet wird .
Mobilität
AYIYA kann zur Bereitstellung mobiler Hosts verwendet werden, indem der Datenverkehr von der Heimadresse zum Home Agent über ein zugrunde liegendes Netzwerk getunnelt wird. Jeder Remote-Host, mit dem der mobile Host kommuniziert, benötigt keine AYIYA-Unterstützung. Unterstützt der Remote-Host AYIYA, kann er auch direkt einen Tunnel zum mobilen Host aufbauen. Der Remote-Host kann feststellen, ob ein Host AYIYA unterstützt, indem er DNS- Einträge abfragt und die Pakete mittels Public-Key-Kryptografie authentifiziert.
+-------------+ +------------+ ,--------. +-------------+ | Mobiler Host | <--AYIYA--> | Home Agent | <----> { Internet } <----> | Remote Host | +-------------+ +------------+ '--------' +-------------+ Die Verwendung von AYIYA zur Bereitstellung von IPv6 für einen Host bietet diesem Endpunkt bereits Mobilität, da er seine IPv6-Adresse unabhängig vom geografischen Standort verwenden kann.
Paketformat
| Bits 0 - 3 | 4 - 7 | 8 - 11 | 12 - 15 | 16 - 19 | 20 - 23 | 24 - 31 | ||||||||||||||||||||||||||
|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|---|
| 0 | Identitätslänge | Identitätstyp | Signaturlänge | Hash-Methode | Authentifizierungsmethode | Betriebscode | Nächste Überschrift | |||||||||||||||||||||||||
| 32 | Epochenzeit | |||||||||||||||||||||||||||||||
| Identität | ||||||||||||||||||||||||||||||||
| Unterschrift | ||||||||||||||||||||||||||||||||
Bei der IPv6-über-IPv4-UDP-Verbindung, dem häufigsten Anwendungsfall, besteht die Identität aus der IPv6-Adresse des Endpunkts (16 Byte) und die Signatur aus einem SHA1-Hash (20 Byte). Der Header umfasst insgesamt 8 + 16 + 20 = 44 Byte. Durch die Kapselung in UDP und IPv4 ergibt sich ein Tunnel-Overhead von 44 + 8 + 20 = 72 Byte. Über Ethernet ermöglicht dies eine MTU von 1428 Byte.
Implementierungen
Das AYIYA-Protokoll wurde in AICCU implementiert .
Referenzen
- ^ Massar, J. "AYIYA: Anything In Anything" . Ietf Datatracker . IETF .(Internet-Entwurf)
- ^ T. Hain (November 2000). Architektonische Implikationen von NAT . IETF . doi : 10.17487/RFC2993 . RFC 2993 .
- ^ "Anything In Anything (AYIYA)" . SixXS.
- ^ R. Graveman; M. Parthasarathy; P. Savola; H. Tschofenig (Mai 2007). Using IPsec to Secure IPv6-in-IPv4 Tunnels . IETF . doi : 10.17487/RFC4891 . RFC 4891 .