|
|
Zeile 32: |
Zeile 32: |
| </noinclude> | | </noinclude> |
|
| |
|
| = TMP =
| |
| Gleich mehrere Probleme auf einmal löst das Protokoll AYIYA, auch unter Anything In Anything bekannt
| |
| * Der Transport geschieht bewusst nicht direkt in IPv4, sondern in einem Upper Layer Protocol
| |
| * Letztere kommen in der Regel problemlos durch NAT/PAT-Router oder CGN
| |
| * AYIYA erlaubt es, mehrere Tunnel gleichzeitig hinter einem NAT/PAT zu betreiben
| |
| * Darüber hinaus kann ein Tunnelendpunkt auch seine Adresse ändern, was dazu führt, dass selbst periodisch wechselnde IPv4Adressen die Stabilität des Tunnels nicht beeinträchtigen können
| |
| Typischerweise werden IPv6-Pakete in UDP verpackt, die dann wiederum mit IPv4 auf die Reise geschickt werden
| |
| * Die Gegenseite ist dann üblicherweise der Server eines Tunnelbrokers
| |
|
| |
| SixXS, in dessen Reihen AYIYA entwickelt wurde, ist der bekannteste Nutzer dieses Protokolls
| |
| * Die Spezifikation existiert bisher nur als Entwurf, kann aber auf der Website des SixXSProjektes heruntergeladen werden
| |
|
| |
|
| [[Kategorie:IPv6/Tunnel]] | | [[Kategorie:IPv6/Tunnel]] |
AYIYA - Tunneling von IPv4 in IPv6
Beschreibung
IPv4-Datagramme werden als Payload in IPv6-Paketen platziert
- Aus Sicht der IPv4-Endpunkte des Tunnels bildet IPv6 den Link-layer
- Die Konfiguration der Endpunkte geschieht statisch
Anhang
Dokumentation
RFC
RFC |
Titel |
Jahr |
Status
|
2473 |
Generic Packet Tunneling in IPv6 Specification |
1998 |
Proposed Standard
|
Siehe auch
Links
Weblinks