Bei der Ausschreibung von WAN- und Internet-Anschlüssen stellt sich oft die Frage, welche maximale Paketlänge zu fordern ist. Die Frage ist relevant, weil für verschiedene Zwecke Encapsulation erforderlich ist, zum Beispiel für die Bildung eines IPsec-Tunnels. Mein Kollege Dr. Wetzlar ist in einem Artikel darauf eingegangen.
Encapsulation oder Tunnelbildung ist immer mit einem zusätzlichen Header verbunden. Wenn einem Endgerät die auf dem Weg zu einem anderen Endgerät unterstützte Größe der maximalen Übertragungseinheit (Maximum Transmission Unit Size, MTU Size) nicht bekannt ist, kann es passieren, dass die von ihm gesendeten Pakete das Ziel nicht erreichen. Eine andere Möglichkeit ist, dass Router auf dem Übertragungspfad das Paket fragmentieren. Fragmentierung ist problematisch, weil möglicherweise Firewalls Fragmente nicht durchlassen oder Performance-Probleme bei der Zusammensetzung der Fragmente durch den Empfänger entstehen.
Deshalb gibt es die beiden Spezifikationen RFC 1191 (für IPv4) und RFC 8201 (für IPv6). Diese Spezifikationen befassen sich mit Path MTU Discovery. Die Idee hinter Path MTU Discovery ist, dass Router bei Erhalt eines Paketes, das die MTU Size des Zielsegments überschreitet, eine Fehlermeldung mit der Angabe der MTU Size zurücksenden. Dazu wird das Internet Control Message Protocol (ICMP) genutzt. Wenn die ICMP-Rückmeldung den Sender erreicht, erfährt dieser, welche MTU Size ein bestimmter Übertragungspfad hat.
Jedoch scheitert manchmal das Verfahren, zum Beispiel wenn Firewalls auf dem Übertragungspfad die ICMP-Nachricht verwerfen.
Wenn Transportnetze wie das WAN oder das Internet auch durch Encapsulation verlängerte Pakete übertragen würden, entstünde das Problem nicht. In der Regel senden Endgeräte IP-Pakete bis zur maximalen Paketlänge von 1500 Bytes inklusive des IP-Headers, aber ohne Layer-2-Header. Leider ist davon auszugehen, dass im Internet auch nur maximal 1500 Bytes lange IP-Pakete übertragen werden. Dies bedeutet: Bei Tunnelbildung über das Internet sollte Path MTU Discovery oder die manuelle Reduzierung der maximalen Paketlänge auf den Endgeräten genutzt werden.
Für Layer-2-Netze gelten IP-Standards nicht. Wenn also in einem Layer-2-WAN ein Encapsulation-Verfahren genutzt wird, sollte das nicht auf Kosten der maximalen Ethernet-Frame-Länge gehen. Diese beträgt auf den Endgeräten meistens 1514 Bytes (ohne Prüfsumme, ohne VLAN-Header). Der Encapsulation-Overhead kommt hinzu. Deshalb ist es interessant zu wissen, welche maximale Frame-Länge in typischen Provider-Diensten für Ethernet-WAN unterstützt wird.
In der Spezifikation des Dienstes EthernetConnect 2.0 der Deutschen Telekom heißt es: „Bei Verbindungen kann die Frame Size grundsätzlich zwischen 64 Byte und 1590 Byte betragen. Bei EVC zwischen zwei Anschlüssen des Typs L kann die Frame Size zwischen 64 Byte und 4400 Byte betragen.“ EVC steht für Ethernet Virtual Channel. Typ L ist der Anschluss mit 1 Gbit/s. Interessant ist, dass in einem WAN, das nur Anschlüsse des Typs L einbindet, die maximale Frame-Länge wesentlich größer sein kann als bei einem EVC mit einem anderen Typ. Der Worst Case wäre hier 1590 Bytes. Das ist etwas weniger als bei EthernetConnect der ersten Version, die 1596 Bytes unterstützte. Aber für die meisten Zwecke dürften 1590 Bytes ebenfalls ausreichen.
Einige Mitbewerber der Deutschen Telekom geben in Ausschreibungen an, auch 1600 Bytes als maximale Ethernet-Frame-Länge zu unterstützen.
Es empfiehlt sich also, diesen Parameter in WAN-Ausschreibungen bei den Bietern in Erfahrung zu bringen und zu bewerten.
