Seite 4: IPv4 und IPv6

Inhaltsverzeichnis

heisenetze: Die IPv4-Optionen eignen sich nicht dazu, dem Zielhost eine Multipath-TCP-Anforderung zu signalisieren, weil die meisten Router im Internet Pakete mit Optionen im Header schlicht verwerfen. Wie ist das mit IPv6? Wäre das Internet transparenter für IPv6-Pakete mit einem erweiterten Header, der die Signalisierungsinformation übermittelt?

Bonaventure: Da muss man Theorie und Praxis unterscheiden. Theoretisch wären wir in der Lage, einige Multipath-TCP-Informationen an IPv6-Optionen zu übergeben, die von der Größe her keiner Beschränkung unterliegen. Das würde zwar das Prinzp der Protokollschichten durchbrechen, aber das wäre ja nicht das erste Mal, dass wir gegen das Layering-Prinzip verstoßen.

Aber das Problem sind wieder die Middleboxen im Netz, die Pakete mit unbekannten Optionen verwerfen würden; bei vielen Firewalls ist das die Grundeinstellung. Der Punkt ist, dass viele Geräte ein empfangenes Paket ohne Optionen effizienter mit der Hardware verarbeiten können, während ein Paket mit Optionen sehr oft von der Software verarbeitet werden muss, was nicht so effizient ist.

In der IETF gibt es momentan Diskussionen darüber, ob man die IPv6-Optionen verwenden kann. Eine der Hauptanwendungen von Optionen in IPv6 ist die Unterstützung der Fragmentierung von Paketen. Da wurde kürzlich von den RIPE Labs ein Test durchgeführt, ob die IPv6-Fragmentierung korrekt über das Internet funktioniert. Das Ergebnis war, dass auf ungefähr 10 Prozent der getesteten Pfade die IPv6-Fragmentierung nicht einwandfrei funktioniert. Das zeigt, dass die Erweiterungsheader nicht immer unbeschadet überleben.

heisenetze: Das Problem ist also im Grunde dasselbe wie bei IPv4?

Bonaventure: Leider, ja.

heisenetze: Aber Multipath-TCP läuft genauso über IPv6 wie über IPv4?

Bonaventure: Ja, es ist völlig blind gegenüber der darunterliegenden Netzwerkschicht. Es funktioniert mit beiden.