WavebreakMediaMicro - Fotolia
IPv6: Die Funktionen der neuesten Spezifikation
Die IPv6-Spezifikation wird nun zu einem umfassenden Internetstandard. Neue IPv6-Funktionen bieten Verbesserungen für Zuverlässigkeit, Betrieb und Sicherheit im Enterprise-Bereich.
Es ist jetzt 20 Jahre her, dass die Internet Engineering Task Force, kurz IETF, den ersten Request for Comments (RFC) veröffentlichte, der zur Entwicklung von IPv6 führte. Im Jahr 2017 veröffentlichte die IETF ihren jüngsten Request for Comments für IPv6, RFC 8200, der empfahl, IPv6 und eine Reihe von IPv6-Funktionen zum Teil eines Internetstandards zu machen.
IETF-Standards durchlaufen mehrere Stufen, vom Proposed Standard über den Draft Standard bis zum Internet Standard.
Proposed Standards stehen am Anfang des Standardisierungsverfahrens für Protokollspezifikationen und bedeuten, dass die Spezifikation generell stabil und wohlverstanden ist. Allerdings erfordern sie keine Implementierung oder Betriebserfahrung mit den dazugehörigen Protokollen.
Ein Draft Standard – der nächste Schritt – setzt neben einer erfolgreichen Betriebserfahrung mindestens zwei unabhängige und interoperable Implementierungen der Spezifikation voraus. Eine Spezifikation erhält den Status Internet Standard, wenn signifikante Implementierungen und eine erfolgreiche Betriebserfahrung vorliegen. Das ist der höchste Status, den eine Protokollspezifikation der IETF erreichen kann.
Dieser Artikel untersucht einige der wichtigsten Änderungen in der überarbeiteten IPv6-Spezifikation sowie Kontroversen, die während des Veröffentlichungsprozesses entstanden.
Die IPv6-Kernspezifikation und wie sie sich verändert hat
Die IPv6-Kernspezifikation – RFC 2460 – hat seit ihrer ersten Fassung erhebliche Änderungen erfahren. Die neuen IPv6-Funktionen sind auf Zuverlässigkeit ausgerichtet und konzentrieren sich zudem auf Überlegungen hinsichtlich Betrieb und Sicherheit.
Zu diesem Zweck enthält die überarbeitete Spezifikation eine Sicherheitsanalyse von IPv6, mit Verweisen auf einige der in den letzten Jahren durchgeführten Untersuchungen, insbesondere im Bereich der IPv6-Adressierung. Andere Verbesserungen betreffen die Extension Headers und Fragmentierung von IPv6.
Zum Beispiel erlaubte die ursprüngliche IPv6-Spezifikation sogenannte Overlapping Fragments – das heißt Fragmente, die das gleiche Datensegment des unfragmentierten Originaldatagramms abdecken. Die Verwendung von Overlapping Fragments zur Umgehung von Sicherheitskontrollen war bereits bei IPv4 äußerst populär. Doch selbst als es für sie in der Welt von IPv6 keine legitime Berechtigung mehr gab, galten Overlapping Fragments nach wie vor als zulässig. Solche Fragmente wurden schließlich durch den 2009 veröffentlichten RFC 5722 für unzulässig erklärt. Infolgedessen enthält die neue Spezifikation diese Aktualisierung und verbietet Overlapping Fragments.
Die Originalspezifikation ermöglichte es auch, dass Pakete mit Extension Headers in mehrere Fragmente aufgeteilt wurden. Mit anderen Worten: Der Kopfbereich der oberen Schicht – zum Beispiel TCP – konnte in einem anderen Fragment als dem ersten vorhanden sein, wie in Abbildung 1 zu sehen ist.
Dies verhinderte grundsätzlich Stateless Filtering von IPv6-Paketen und wurde durch den im Jahre 2014 veröffentlichten RFC 7112 verboten. Das Verbot bleibt bestehen: Das erste Fragment eines Datagramms muss die gesamte IPv6-Header-Kette enthalten.
Ein anderer Bereich, auf dem IPv6 die Geschichte von IPv4 wiederholte, ist die Nutzung von Predictable Fragment Identification Values, die bei IPv4 auf verschiedene Arten missbraucht wurden, etwa für die Implementierung von Port-Scanning-Angriffen im Stealth-Modus. Die bevorstehende Überarbeitung der IPv6-Spezifikation verweist auf RFC 7739 für mögliche Algorithmen zur Generierung von Fragment Identification Values.
Atomfragmente nun Bestandteil der IPv6-Funktionen
Eine weitere Verbesserung im Zusammenhang mit der IPv6-Fragmentierung bezieht sich auf sogenannte Atomfragmente. Im Wesentlichen besagte die ursprüngliche IPv6-Spezifikation, dass bei Erhalt einer Packet-Too-Big-Nachricht vom Internet Control Message Protocol Version 6 (ICMP) über eine Maximum Transmission Unit (MTU) kleiner als 1280 Byte der empfangende Host in alle nachfolgend gesendeten Pakete dieser Kommunikation einen Fragment Header einfügen muss (siehe Abbildung 2).
Hacker nutzten diese Funktion für DoS-Attacken (Denial of Service) aus. Deshalb wurde das Feature in der aktualisierten Spezifikation gestrichen. Stattdessen werden Atomfragmente auf andere Weise verarbeitet, so wie von RFC 6946 ursprünglich vorgesehen.
Darüber hinaus entfernt die bevorstehende Überarbeitung auch die Spezifikation für Routing Header Type 0, die ebenfalls als DoS-Angriffsvektor identifiziert wurde.
Wie bei jeder Änderung einer bestehenden Spezifikation kam es zu Kontroversen um einige der vorgeschlagenen IPv6-Funktionen. Die heftigste Debatte drehte sich um das Einfügen von Extension Headers durch Middleboxes.
IPv6 ist immer schon ein End-to-End-Protokoll gewesen. Deshalb wurde es intermediären Systemen nie gestattet, IPv6-Pakete zu modifizieren. Ausnahme bildet die Verringerung des Hop-Limits. Doch eine Technologie namens IPv6 Segment Routing – größtenteils basierend auf Middleboxes, die IPv6 Extension Headers hinzufügen und entfernen – entfachte eine äußerst hitzige Diskussion darüber, ob die überarbeitete IPv6-Spezifikation das Einfügen und Entfernen von Extension Headers durch Middleboxes erlauben sollte.
Diese Streitigkeiten hielten bis zur endgültigen Annahme der überarbeiteten IPv6-Spezifikation zur Veröffentlichung als RFC an und wurden beigelegt, indem man am Status quo festhält: Das Einfügen und Entfernen von Extension Headers durch Middleboxes ist verboten.
Folgen Sie SearchNetworking.de auch auf Twitter, Google+, Xing und Facebook!
