Zusammenfassung

  • RFC 3964 machte aus dem Abgleich der äußeren IPv4-Quelle mit dem eingebetteten 6to4-Präfix einen begrenzten Konsistenznachweis, nicht aber einen Identitäts-, Mandats- oder Zustellnachweis.
  • Weil der äußere Header nach der Entkapselung aus dem normalen IPv6-Pfad verschwand, mussten beide Header, die konkrete Relay-Instanz und jedes einzelne Prüfergebnis vor der Umwandlung verbunden aufgezeichnet werden.

Eine Missbrauchsbeschwerde nennt eine IPv6-Adresse. Ein Relay-Betreiber sieht vielleicht seine IPv4-Adresse in einer fremden Spur. Dazwischen liegt ein Umschlag, den niemand mehr besitzt. RFC 3964 beschrieb diese Lücke nicht als bloßes Logging-Problem, sondern als Eigenschaft der 6to4-Paketverarbeitung.

Die Grundlage hatte RFC 3056 gelegt. Aus einer globalen IPv4-Adresse entstand 2002:V4ADDR::/48. Zwischen zwei 6to4-Standorten lieferte der eingebettete Wert das IPv4-Ziel für Protokoll 41. Zwischen 6to4 und nativem IPv6 entfernte oder ergänzte ein Relay den äußeren Header.

Die Konstruktion sparte Abstimmung: Die Adresse trug einen Routinghinweis. Gleichzeitig enthielt das Paket zwei unterschiedliche Aussagen. Der äußere Header bezeichnete den am Tunnelrand beobachteten IPv4-Endpunkt. Der innere Header behauptete eine IPv6-Quelle. Das Entfernen der ersten Aussage beglaubigte die zweite nicht.

Der Abgleich prüfte Felder, keine Akteure

Wenn die innere Quelle eine 6to4-Adresse war, sollte der Relay die in 2002:V4ADDR::/48 eingebettete IPv4-Adresse mit der äußeren Quelle vergleichen. Bei Abweichung war das Paket zu verwerfen. Auch Multicast-, Broadcast-, Loopback-, private und andere ungeeignete Sonderadressen durften nicht als globale Tunnelendpunkte verwendet werden. Die Grenzen folgten Routeranforderungen wie RFC 1812 und lassen sich heute im IANA-Register für IPv4-Sonderzweckadressen nachlesen.

Eine Übereinstimmung war wertvoll. Sie bewies, dass zwei maschinenlesbare Werte unter einer bestimmten Regel zum gleichen Zeitpunkt zusammenpassten. Sie bewies nicht, wem die Adresse tatsächlich gehörte, ob die Zuweisung fortbestand, ob das Gerät als Relay beauftragt war oder ob ein Benutzer die spätere Anwendungshandlung autorisiert hatte.

Quelladressfilter konnten die Bedingung verstärken. RFC 2827 / BCP 38 verlangte, unplausible IPv4-Quellen nahe ihrem Ursprung zu stoppen; RFC 3704 / BCP 84 behandelte Mehrfachanbindungen. Wer ein 6to4-Präfix fälschte, musste dadurch auch die passende äußere Quelle fälschen und die Filter passieren. Ein erfolgreicher Filterdurchlauf blieb dennoch ein Topologie- oder Anschlussbeleg, keine Identifizierung des Handelnden.

Aus nativem IPv6 fehlte der Vergleichswert

Beim Verkehr von nativem IPv6 zu einem 6to4-Standort war die innere Quelle keine 2002:-Adresse. Der äußere Absender sollte ein Relay sein, aber im inneren Feld gab es keinen IPv4-Wert zum Vergleich. RFC 3964 stellte fest, dass ein 6to4-Router ein legitimes Relay nur schwer von einem Dritten unterscheiden konnte, der dessen Rolle vorspiegelte. Der Eingang eines Protokoll-41-Pakets war ein Transportbeleg, kein Berechtigungsnachweis.

Die Grenze ähnelt den Vertrauensmodellen für Neighbor Discovery in RFC 3756: Wer auf einem Link sprechen kann, ist nicht automatisch als Router befugt. Bei 6to4 war das weite IPv4-Netz der gedachte Link. Erreichbarkeit und Autorität lagen entsprechend weit auseinander.

Die Schutzmaßnahmen mussten deshalb einzeln bleiben: Außen-/Innen-Abgleich, Sonderadressprüfung, Richtungsprüfung, Verbot des Relayings von 6to4 zurück zu 6to4, Beschränkung auf eigene Zielpräfixe sowie Route und Rate. Ein zusammengefasstes gültig hätte verborgen, welche Frage beantwortet wurde und welche gar nicht beantwortbar war.

Entkapselung entfernte eine schwache, aber wichtige Beobachtung

Der Anhang von RFC 3964 zeigt vor der Entkapselung vier Adressen, danach nur noch die beiden inneren. Der Text weist darauf hin, dass Relays IPv4-Adressen häufig wie Link-Layer-Adressen behandelten und nicht protokollierten. So konnte ein von einem IPv4-Knoten ausgehender Angriff als IPv6-Paket weiterlaufen, während die Spur src_v4 verloren ging.

Die äußere Quelle durfte nicht überbewertet werden. Sie konnte gefälscht sein, nur den Relay statt des Urhebers bezeichnen oder unter Anycast viele Geräte vertreten. Doch ihr Wegfall machte die innere Quelle nicht glaubwürdiger. Er nahm der Untersuchung lediglich eine Beobachtung, die den Eintrittspunkt begrenzte.

Der belastbare Datensatz war eine Beziehung: Eingangsinterface, konkrete Instanz, äußeres IPv4-Paar, inneres IPv6-Paar, Zeit, Protokoll, Routenstand und jedes Prüfresultat. Die Entkapselung bildete einen eigenen Übergang; IPv6-Weiterleitung, Fernempfang und Anwendungseffekt folgten als getrennte Belege. Nur so ließ sich eine spätere Beschwerde an die tatsächlich beobachtete Grenze zurückbinden.

RFC 6169 verallgemeinerte später den Befund. Die Filter des Trägernetzes gelten nicht automatisch für innere Adressen, tunnelblinde Sicherheitsgeräte verlieren Sicht, und nur die Endpunkte können entsprechende Kontrollen ergänzen. Eine erfolgreiche Paketumwandlung war daher nicht dasselbe wie erfolgreiche Evidenzerhaltung.

Anycast fand irgendeinen Relay und verbarg den konkreten

RFC 3068 reservierte 192.88.99.1 als 6to4-Relay-Anycast-Adresse. IPv4-Routing wählte einen nahen Relay; eine fehlerhafte Instanz konnte die Route zurückziehen und einer anderen Platz machen. Das ersparte standortspezifische Konfiguration, erschwerte laut Dokument aber die Bestimmung des tatsächlich verwendeten Relays.

Eine Route zur Anycast-Adresse bewies daher nur eine Auswahl im Kontrollpfad. Sie bewies weder Dienstbereitschaft noch native IPv6-Anbindung, korrekte Prüfungen, Kapazität oder denselben Rückweg. Für Verfügbarkeit war Austauschbarkeit eine Stärke; für Rechenschaft war sie eine Lücke.

RFC 6343 dokumentierte 2011 schwarze Löcher, nicht verwaltete oder unwillige Relays, unterschiedliche Hin- und Rückwege sowie zustandsbehaftete Filter, die wechselnde äußere Quellen ablehnten. Eine Routenankündigung zog Arbeit an, ohne einen Dienstbeleg zu liefern.

RFC 7526 stufte 2015 Anycast-6to4 und 192.88.99.1 formell als veraltet ein. Der grundlegende Mechanismus aus RFC 3056 und 2002::/16 wurden ausdrücklich nicht mit abgeschafft. Eine Normentscheidung ist deshalb kein Nachweis, dass alle Konfigurationen, Routen oder Restpakete verschwunden waren.

Der Belegpfad endete nicht an der Tunnelkante

RFC 3964 unterschied Denial of Service, Reflexion, Packet Laundering, lokalen IPv4-Broadcast, Dienstediebstahl und administrativen Missbrauch. Ein Relay konnte wegen seiner äußeren Adresse wie der Ursprung erscheinen. Eine gefälschte innere Quelle konnte Antworten zu einem Opfer lenken. Nachgelagerte Protokolle konnten nur die innere Behauptung speichern.

Ein vollständiger Pfad trennt deshalb IPv4-Routenauswahl, Empfang an einem konkreten Interface, gemeinsame Sicht auf vier Adressen, einzelne Regelentscheidungen, Entkapselung, IPv6-Weiterleitung, Zielannahme, Anwendungseffekt sowie eigenständige Identitäts- und Autoritätsbelege. Schritt fünf kann erfolgreich sein, obwohl sechs bis neun offen bleiben.

Primärquellen sind der Text, der RFC-Editor-Eintrag und die Errata zu RFC 3964. Zwei bestätigte technische Korrekturen berichtigen ein Beispielziel und einen Tippfehler im Anycast-Präfix; sie belegen keinen Vorfall. Die Geschichte stützt sich außerdem auf RFC 3056, 3068, 2827, 3704, 6343, 7526, 6169, 1812 und 3756. Sie beweist keinen benannten Angriff, Herstellerfehler, Betroffenen, Umfang oder flächendeckenden Filtereinsatz.