Die Header des IPv6

17.11.1995

Im Vergleich zur bisherigen Version 4 haben sich bei der neuen Protokollgeneration auch einige Felder des Headers geaendert oder sind weggefallen. So heisst nun das Feld "Protocol" "Next Header". Umbenannt wurde auch das "Length"-Feld in "Payload Length". Es umfasst nun nicht mehr das gesamte IPv6-Paket, sondern nur das Paket nach dem Header.

Die "Header Checksum" sucht der User dagegen vergebens, sie wurde entfernt. Das duerfte Auswirkungen auf andere Protokolle wie das Serial Line Interface Protocol (SLIP) haben, die ohne Checksum unter IPv6 wohl nicht mehr verwendet werden koennen. Das Feld "Header Length" fehlt ebenfalls, ist jedoch aufgrund der festen Header-Laenge unter IPv6 nicht mehr erforderlich. Neu hinzugefuegt sind die "Flow Labels", um mit der Einfuehrung von "Traffic Classes" in Routern ein spezielles Handling fuer Daten wie Video- oder Audiouebertragung zu realisieren.

Ausgelagert sind die "Fragmentation Fields", die nun in einem eigenen Header implementiert sind. Diese werden benutzt, um Payloads, die groesser als die Maximum Transfer Unit (MTU) sind, an ihr Ziel zu schicken. Einen eigenen Header gibt es zudem fuer das Routing. Dieser wurde entworfen, um das Source Demand Routing Protocol (SDRP) zu unterstuetzen.

Auch in Sachen Sicherheit bietet das Protokoll der naechsten Generation zwei Neuigkeiten. So sind nun bereits auf Protokollebene Header fuer "Authentification" und "Privacy" vorgesehen. Der Authentification-Header dient dabei der Authentifizierung und vollstaendigen Sicherung der IPv6-Pakete. Zur Geheimhaltung und fuer die Vollstaendigkeit der zu verschluesselnden Daten ist der "Privacy-Header" konzipiert, der immer das letzte nicht verschluesselte Feld in einem IPv6-Paket ist. Dabei haben die Datenpakete, um eine unbefugte Verkehrsanalyse zu erschweren, immer eine feste Laenge, egal wie viele Daten verschickt werden. Inkonsequent ist jedoch hier im Bezug auf die Datensicherheit die Moeglichkeit, die genannten Fragmentation-Header zu verwenden. Ein weiteres Problem ergibt sich daraus, dass der Privacy-Header in der Protokolldefinition nur den Status "recommended" (empfohlen) traegt. Um nun alle Router-Hersteller dazu zu verpflichten dieses Feature zu implementieren, gibt es Ueberlegungen, den Statuts in "required" (erforderlich) zu aendern.