Zusammenfassung
- RFC 6666 weist
100::/64als IPv6 Discard-Only Address Block aus. Es darf innerhalb eines autonomen Systems verteilt und auf Null-Interfaces aufgelöst werden, sollte aber nicht zwischen fremden ASen ausgetauscht werden. - Der Block ist weder die Opferroute noch die BLACKHOLE-Community oder ein Paketbeleg. Erst Autorisierung, RIB, Rekursion, FIB, Zähler, externe Begrenzung und Rücknahme ergeben einen belastbaren Nachweis.
- Nick Hilliard und David Freedman verfassten das Informational RFC gemeinsam. Die Leistung liegt in einer weltweit eindeutigen Bezeichnung für eine lokal begrenzte Handlung, nicht in einem globalen Dienst oder einer Einsatzpflicht.
Der angenommene Update war noch kein Ergebnis
Ein IPv6-Dienst gerät unter volumetrischen Angriff. Ein berechtigter Operator injiziert ein /128 für das Ziel in iBGP und setzt eine Adresse aus 100::/64 als Next Hop. Alle Edge-Router akzeptieren die Route, das System meldet „Blackhole aktiv“.
An drei Eingängen erreicht die Rekursion eine statische Route zum Null-Interface. An einem vierten fehlt sie; das BGP-Objekt wird nicht zu einem brauchbaren FIB-Eintrag. Ein fünfter Router exportiert wegen einer fehlerhaften Policy das Verwerfungspräfix an einen Nachbarn. Ein einheitlicher Kontrollzustand verdeckt drei Paketresultate.
Das ist kein reales Ereignis, sondern ein Modell für die Grenze zwischen standardisierter Bedeutung und operativem Beweis.
Weltweit eindeutig, betrieblich lokal
Zielbasiertes RTBH ändert den Next Hop der angegriffenen Adresse, damit Last an den Eingängen endet, bevor sie interne Links und Systeme beansprucht. In IPv4 wurden dafür oft private Adressen benutzt, die am Rand statisch auf Null zeigten. Das funktionierte, lieh aber einem Produktionsmechanismus einen fremden Namensraum. Dokumentationsadressen waren dafür noch ungeeigneter.
RFC 6666 verlangte deshalb einen eigenen IPv6-Block. IANA führt 100::/64, die übliche Form von 0100::/64, als Discard-Only Address Block. Er ist keiner Endpartei zugeteilt. Im aktuellen Register sind Source, Destination und Forwardable wahr, Globally Reachable dagegen falsch.
Forwardable erlaubt Routing und rekursive Auflösung im kontrollierten Bereich. Die fehlende globale Erreichbarkeit setzt die Außengrenze. Der Block muss intern wie ein Unicast-Next-Hop funktionieren, darf aber nicht zum interdomainen Ziel werden.
Das Register koordiniert Bedeutung. Es installiert keine Nullroute, genehmigt kein Opferpräfix, wählt keinen Eingang, verwirft kein Paket und trägt nicht den Ausfall legitimer Nutzer. Der Betreiber kontrolliert die Ausführung.
Drei getrennte Steuerflächen
Ziel-RTBH opfert das Angriffsziel, um den Rest zu schützen. Quell-RTBH verbindet Routing mit uRPF und verwirft Pakete, deren behauptete Quelle über den Verwerfungspfad aufgelöst würde. Autorität, Schaden und Messung unterscheiden sich; ein Beleg gilt nicht für beide.
Null und Sinkhole sind ebenfalls verschieden. Null vernichtet das Paket. Ein Sinkhole leitet es zur Analyse und kann ausgewählten Verkehr zurückführen. Der gemeinsame Begriff „Blackhole“ darf nicht verdecken, ob Daten aufgezeichnet wurden oder legitimer Verkehr einen weiteren Weg hatte.
Auch 100::/64 und die BLACKHOLE-Community aus RFC 7999 sind nicht identisch. Der Adressblock liefert die interne Rekursion. Die Community ist ein Hinweis am Opferpräfix. Ein Nachbar entscheidet nach Vereinbarung und eigener Policy, ob er sie beachtet, und muss die Ankündigungsberechtigung prüfen. Ohne explizite Konfiguration sollte Hardware nicht allein wegen der Community verwerfen.
Der Empfang der Community belegt Absicht, nicht Routenannahme, FIB, Verwerfung oder Propagationsgrenze. Ein AS kann 100::/64 intern verwenden, ohne einen Dritten um BLACKHOLE-Behandlung zu bitten.
Innen vorhanden, außen abwesend
RFC 6666 erlaubt, den ganzen Block oder Teile davon intern dynamisch zu tragen und auf einigen oder allen IPv6-Routern zu Null zu führen. Das Wort „einigen“ lässt eine echte Architekturentscheidung: nur an bekannten Eingängen oder als einheitliche interne Absicherung. Topologie und Einsatzziel bestimmen die Wahl.
An der Außengrenze gilt das Gegenteil. Der Block und seine Subnetze sollen weder angekündigt noch akzeptiert werden; auch Verkehr dorthin soll die Drittgrenze nicht überschreiten. Ein Leak kann zusätzliche Last in ein bereits angegriffenes Netz ziehen.
Gesund ist der Zustand nur asymmetrisch: innen dort auflösbar, wo die Policy ihn braucht, außen vollständig gefiltert. Ein einzelnes Lämpchen „Route vorhanden“ kann das nicht ausdrücken.
Sechs Belege
Der Autoritätsbeleg nennt Genehmiger, exaktes Opferpräfix, Umfang, Grund, Beginn und Ablauf. Er verhindert fremde Präfixe und unbefristete Altalarme.
Der Kontrollbeleg hält Triggerroute, Community, Next Hop, Empfänger und Policy-Entscheidung fest. Längenfilter, Ursprung, RPKI oder ein fehlerhaftes Attribut können die Aktivierung stoppen. Annahme bleibt ein RIB-Ereignis.
Der FIB-Beleg zeigt an jedem vorgesehenen Eingang die Auflösung des Opfers über 100::/64 zum erwarteten Verwerfungsinterface. Controller- oder Reflector-Sicht genügt nicht.
Der Paketbeleg verbindet örtliche Zähler mit sauberen Testpaketen. Null kann fehlenden Verkehr, den falschen Eingang, defekte Telemetrie oder eine fehlende Aktion bedeuten.
Der Begrenzungsbeleg prüft Adj-RIB-Out, Filter und Nachbar-Policies. Das Schweigen eines öffentlichen Collectors ist kein universeller Negativbeweis.
Der Wiederherstellungsbeleg versieht Trigger-Rücknahme, FIB-Bereinigung, Normalroute und Ende der Genehmigung mit Zeitstempeln. Ein kumulativer Zähler beschreibt Vergangenheit.
Legitime Erreichbarkeit ist der Preis
Ziel-Blackholing schützt das größere System, indem es die angegriffene Adresse für Angreifer und legitime Nutzer unerreichbar macht. Das ist der Tausch, keine Fußnote. Das kleinste praktikable Opferpräfix begrenzt Kollateralschaden, macht Verwerfung aber nicht zu Verfügbarkeit.
Nach der Aktivierung muss geprüft werden, ob gemeinsame Links entlastet, Nachbardienste erreichbar und keine weiteren Ziele angegriffen wurden. „Traffic sank“ reicht nicht, wenn das Werkzeug den Rückgang selbst durch Vernichtung erzeugt.
Präzision statt persönlicher Besitzanspruch
Hilliards IETF-Profil führt sechs RFCs. RFC 6666 entstand mit David Freedman, durchlief die IETF-Prüfung und erschien als Informational. Es ist weder persönlicher Standard noch allgemeiner Befehl.
Die bleibende Idee ist nüchtern: Produktionskontrollen brauchen einen eigenen Namensraum statt geliehener Privat- oder Dokumentationsadressen. Der Name muss zugleich die Grenze zeigen. 100::/64 ist dann nützlich, wenn alle seine Aufgabe erkennen und niemand es als globalen Dienst behandelt.
Quellen
- RFC 6666: A Discard Prefix for IPv6
- IANA-Register für besondere IPv6-Adressen
- RFC 3882: Configuring BGP to Block Denial-of-Service Attacks
- RFC 5635: Remote Triggered Black Hole Filtering with uRPF
- RFC 7999: BLACKHOLE Community
- Nick Hilliard im IETF Datatracker
- Öffentliches ipSpace-Profil von Nick Hilliard
Mitgliederbriefing
Detaillierter Profilkontext
Melden Sie sich mit der richtigen Mitgliedschaftsstufe an, um das vollständige Briefing und die Quellennotizen freizuschalten.
Nur für Strategic Circle
Strategic Circle
Offen für alle Leser. Schalten Sie Profil-Briefings nach Beitritt und Anmeldung frei.
Strategic Circle beitretenNur für Leadership Alliance
Leadership Alliance
Für qualifizierte Inhaber von IP-Assets und Management; melden Sie sich an, um Leadership-Alliance-Briefings freizuschalten.
Leadership Alliance beitreten
