10. Sicherheitsbetrachtungen

Zugewiesene Internetprotokollnummern [IANA-PN]
ONC-RPC-Netzwerkkennungen (netids) [IANA-NI]
Relevante Netzwerkprotokollschicht-Kennungen (NLPIDs) [IANA-NL]
Protokollregister [IANA-PR]

Die IANA hat diese Referenzen so aktualisiert, dass sie auf dieses Dokument verweisen.

IPv6 weist hinsichtlich des grundlegenden Paketformats und der Paketübertragung ähnliche Sicherheitseigenschaften wie IPv4 auf. Zu diesen Sicherheitsrisiken gehören:

Abhören, bei dem Elemente auf dem Übertragungsweg das gesamte Paket jedes IPv6-Datagramms beobachten können, einschließlich Inhalt und Metadaten.
Wiedergabe, bei der ein Angreifer eine Folge von Paketen aufzeichnet und sie an die Partei zurückspielt, die sie ursprünglich empfangen hat.
Einfügen von Paketen, bei dem ein Angreifer ein Paket mit ausgewählten Eigenschaften fälscht und in das Netz einspeist.
Löschen von Paketen, bei dem ein Angreifer ein Paket von der Übertragungsstrecke entfernt.
Ändern von Paketen, bei dem ein Angreifer ein Paket von der Übertragungsstrecke entfernt, verändert und erneut in das Netz einspeist.
Man-in-the-Middle-Angriffe (MITM), bei denen ein Angreifer den Kommunikationsstrom manipuliert, um sich gegenüber dem Empfänger als Sender und gegenüber dem Sender als Empfänger auszugeben.
Dienstverweigerungsangriffe (DoS), bei denen ein Angreifer große Mengen legitimen Datenverkehrs an ein Ziel sendet, um es zu überlasten.

IPv6-Pakete können durch die „Security Architecture for the Internet Protocol“ [RFC4301] gegen Abhören, Wiedergabe, Einfügen und Ändern von Paketen sowie MITM-Angriffe geschützt werden. Zusätzlich können Protokolle höherer Schichten wie Transport Layer Security (TLS) oder Secure Shell (SSH) verwendet werden, um den auf IPv6 aufsetzenden Anwendungsdatenverkehr zu schützen.

Es gibt keinen Mechanismus zum Schutz gegen DoS-Angriffe. Die Abwehr dieser Art von Angriffen liegt außerhalb des Geltungsbereichs dieser Spezifikation.

IPv6-Adressen sind erheblich größer als IPv4-Adressen. Daher ist es wesentlich schwieriger, den Adressraum über das Internet oder auch nur über eine einzelne Netzwerkverbindung, etwa ein lokales Netzwerk, zu scannen. Weitere Informationen enthält [RFC7707].

Es wird erwartet, dass IPv6-Adressen von Knoten im Internet sichtbarer sind als IPv4-Adressen, da Adressübersetzungstechniken weniger eingesetzt werden. Dies führt zu zusätzlichen Datenschutzproblemen, etwa weil sich Endpunkte leichter unterscheiden lassen. Weitere Informationen enthält [RFC7721].

Die Architektur der IPv6-Erweiterungsheader bietet zwar große Flexibilität, schafft aber auch neue Sicherheitsherausforderungen. Wie nachstehend angemerkt, wurden Probleme im Zusammenhang mit dem Fragment-Erweiterungsheader gelöst. Dennoch ist klar, dass bei jedem künftig entworfenen Erweiterungsheader die Sicherheitsauswirkungen gründlich untersucht werden müssen. Dazu gehört auch die Prüfung, wie der neue Erweiterungsheader mit bestehenden Erweiterungsheadern zusammenwirkt. Weitere Informationen enthält [RFC7045].

Diese Fassung der IPv6-Spezifikation löst eine Reihe von Sicherheitsproblemen, die in der vorigen Fassung [RFC2460] gefunden wurden. Dazu gehört:

Der Text wurde für den Fall überarbeitet, dass Fragmente ganze Datagramme darstellen, das heißt sowohl das Feld Fragment Offset als auch das M-Flag null sind. Wenn sie empfangen werden, SOLLTEN sie als wieder zusammengesetztes Paket verarbeitet werden. Alle anderen passenden Fragmente SOLLTEN unabhängig verarbeitet werden. Der Prozess zur Erzeugung von Fragmenten wurde geändert, damit keine Fragmente erzeugt werden, die ganze Datagramme darstellen (Fragment-Offset-Feld und M-Flag sind null). Weitere Informationen enthalten [RFC6946] und [RFC8021].
Der Absatz in Abschnitt 5 wurde entfernt, der verlangte, ausgehenden Paketen einen Fragment-Header hinzuzufügen, wenn eine ICMP-Packet-Too-Big-Nachricht eine Next-Hop-MTU von weniger als 1280 meldet. Weitere Informationen enthält [RFC6946].
Der Text wurde geändert, um zu verlangen, dass IPv6-Knoten keine überlappenden Fragmente erzeugen dürfen. Wird bei der Wiederzusammensetzung eines IPv6-Datagramms festgestellt, dass eines oder mehrere seiner Bestandteilsfragmente ein überlappendes Fragment sind, MÜSSEN das gesamte Datagramm und alle seine Bestandteilsfragmente stillschweigend verworfen werden. Es wird außerdem klargestellt, dass beim Empfang überlappender Fragmente keine ICMP-Fehlernachricht gesendet werden SOLL. Weitere Informationen enthält [RFC5722].
Der Text wurde überarbeitet, um zu verlangen, dass alle Header bis einschließlich zum ersten Header der oberen Schicht im ersten Fragment enthalten sind. Weitere Informationen enthält [RFC7112].
Die Aktualisierungen aus [RFC5095] und [RFC5871] wurden übernommen, um die Beschreibung des Routing-Headers Typ 0 (RH0) zu entfernen, die Zuweisungsrichtlinien für Routing-Header als in RFC 5871 festgelegt zu benennen und RH0 aus der Liste erforderlicher Erweiterungsheader zu entfernen.

Sicherheitsprobleme zu anderen Teilen von IPv6, einschließlich Adressierung, ICMPv6 und Path-MTU-Discovery, werden in den jeweiligen Spezifikationen behandelt.