AYIYA: Unterschied zwischen den Versionen
Keine Bearbeitungszusammenfassung |
|||
| Zeile 16: | Zeile 16: | ||
== Anhang == | == Anhang == | ||
=== Dokumentation === | === Dokumentation === | ||
<!-- | |||
===== RFC ===== | ===== RFC ===== | ||
{| class="wikitable big options col1center col3center" | {| class="wikitable big options col1center col3center" | ||
| Zeile 22: | Zeile 23: | ||
|- | |- | ||
| [https://www.rfc-editor.org/info/rfc2473 2473] || Generic Packet Tunneling in IPv6 Specification || 1998 || Proposed Standard | | [https://www.rfc-editor.org/info/rfc2473 2473] || Generic Packet Tunneling in IPv6 Specification || 1998 || Proposed Standard | ||
|} | |} | ||
--> | |||
=== Siehe auch === | === Siehe auch === | ||
Version vom 3. Juni 2025, 16:12 Uhr
AYIYA - IPv6-Pakete UDP verpacken
Beschreibung
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
Anhang
Dokumentation
Siehe auch