Zusammenfassung

  • RFC 3056, 2001 von Brian Carpenter und Keith Moore gemeinsam verfasst, definierte 6to4 als eine optionale, temporäre Brücke und wies Sites ausdrücklich an, zu nativem IPv6 zu wechseln, sobald es verfügbar wurde. Sein Lebenszyklusproblem war daher nicht ein fehlendes Ablaufdatum, sondern die Schwierigkeit, dieses Etikett wirksam zu machen, nachdem die Bereitstellung einfach und verteilt geworden war.
  • Christian Huitemas Anycast-Erweiterung reduzierte die Konfiguration, die zum Finden eines Relays erforderlich war, machte den erfolgreichen Dienst jedoch von Routing-Bereich, Überwachung, Fehlerisolierung sowie unabhängig verwalteten Vorwärts- und Rückwärtspfaden abhängig. Spätere Betriebserfahrungen zeigten, wie zerbrechlich dieses Abkommen für Benutzer werden konnte, die nicht wussten, dass 6to4 aktiv war.
  • Carpenters Ratschlag von 2011 verwandelte verstreute Symptome in einen rollenspezifischen Betriebsbericht: Black Holes, variable Verzögerungen, Path-MTU-Fehler, irreführende Diagnosen und Helpdesk-Kosten. Dan Wings und Andrew Yourtchenkos Happy Eyeballs begrenzten daraufhin einige clientseitige Verzögerungen, ohne den zugrunde liegenden 6to4-Pfad zu reparieren.
  • RFC 7526, verfasst von Ole Troan und herausgegeben von Carpenter als IETF Best Current Practice, erklärte Anycast 6to4 im Jahr 2015 für veraltet und verschärfte die Standardeinstellungen. Es erklärte jedoch nicht das grundlegende Unicast-6to4 oder das IPv6-Präfix 2002::/16 für veraltet – eine Grenze, die für das Verständnis sowohl der technischen Entscheidung als auch Carpenters Rolle dabei wesentlich ist.

Vorübergehend von Natur, beständig im Betrieb

„Es ist nicht als dauerhafte Lösung gedacht." Dieser Satz erscheint in der einleitenden Beschreibung vonRFC 3056, veröffentlicht im Februar 2001 von Brian Carpenter und Keith Moore. Die Einschränkung war nicht in einem Anhang versteckt, der die Autoren vor späterer Kritik schützen sollte. Sie war Teil der Definition des Mechanismus: 6to4 war optional, vorübergehend und sollte isolierten IPv6-Sites die Kommunikation über ein IPv4-Netzwerk ermöglichen, bevor native IPv6-Konnektivität verfügbar war. Dasselbe Dokument besagte, dass Sites zu nativen IPv6-Präfixen und -Konnektivität migrieren sollten, sobald ihre Anbieter dies ermöglichten. Vorübergehendkeit war daher eine architektonische Prämisse, kein nachträglicher Anstrich.

Vierzehn Jahre später kamRFC 7526zu dem Schluss, dass 6to4 im Anycast-Modus für den breiten Internet-Einsatz ungeeignet war. Zwischen diesen Aussagen liegt die eigentliche Geschichte. Es ist nicht das bekannte Moralspiel, in dem ein Erfinder eine fehlerhafte Technologie veröffentlicht und schließlich tötet. Carpenter war einer von zwei Autoren des ursprünglichen Mechanismus; er hat weder Christian Huitemas Anycast-Design verfasst noch Produktstandards, Relay-Betreiber, Routing-Richtlinien oder Benutzerakzeptanz kontrolliert. 2015 war Ole Troan der Autor des Ablehnungsdokuments und Carpenter dessen Herausgeber. Sowohl das ursprüngliche Design als auch die spätere Best Current Practice waren Produkte, die in einer technischen Gemeinschaft arbeiteten, keine proprietären Handlungen unter dem Kommando einer Person.

Die schärfere Frage ist, wie ein ausdrücklich temporärer Mechanismus genug Beständigkeit erlangte, um 2011 eine betriebliche Beratung und 2015 eine formelle, begrenzte Ablehnung zu erfordern. Die Antwort beginnt mit einem gewöhnlichen Übergangsgeschäft. 6to4 bot genau den Vorteil, dass es das vorhandene IPv4-Internet als Träger nutzen konnte, ohne dass jedes zwischengeschaltete Netzwerk IPv6 unterstützen musste. Es senkte die unmittelbare Koordinierungslast für eine IPv6-Site. Aber die Last verschwand nicht.

Sie verlagerte sich auf Adresskonstruktion, automatisches Tunneln, Relay-Verfügbarkeit, Routing-Ankündigungen, Filterung, Pfadsymmetrie und Fehlerdiagnose. Je einfacher der Einstieg in den Übergangszustand wurde, desto unwahrscheinlicher war es, dass alle Parteien, von denen der Dienst abhing, einen gemeinsamen Betriebsplan teilten.

Diese Unterscheidung ist zentral für Carpenters Bilanz. Ein temporäres Etikett kann die Entwurfsabsicht regeln; es kann nicht von sich aus installierte Software, Standardeinstellungen oder unabhängig betriebene Netzwerke regeln. Die 2011 veröffentlichtenAdvisory Guidelines for 6to4 Deployment, verfasst von Carpenter und als IETF-Konsensdokument veröffentlicht, berichteten von langen Wiederholungsverzögerungen, vollständigen Ausfällen und Benutzern, die nicht wussten, dass 6to4 lief. Die Beratung gab nicht vor, dass das Wort „vorübergehend" im Jahr 2001 einen Timer in jedem späteren Host und Router erzeugt hatte. Sie behandelte Beständigkeit als einen zu bewirtschaftenden Betriebszustand.

Die Antwort von 2015 testete die ursprüngliche Grenze, ohne sie neu zu schreiben. Die IETF erklärte nicht jedes Paket, das 6to4 verwendet, für illegitim, beanspruchte nicht die gesamte Adressarchitektur oder behauptete, der Mechanismus habe nie funktioniert. Sie erklärte den Anycast-Übergangsmechanismus und seine bekannte IPv4-Relay-Adresse für veraltet, riet von seiner Aufnahme in neue Implementierungen ab und verlangte standardmäßig deaktiviertes Verhalten, wo er verblieb. Gleichzeitig ließ sie ausdrücklich das grundlegende Unicast-6to4 und 2002::/16 außerhalb der Ablehnung.

Das Ergebnis war weniger dramatisch als ein universeller Ruhestand und disziplinierter: Ziehen Sie den Teil zurück, für den der weit verbreitete, unverwaltete Betrieb die deutlichsten Schadensnachweise erbracht hatte, und bewahren Sie gleichzeitig eine genaue Darstellung dessen, was die Entscheidung nicht abdeckte.

Der Mechanismus und die durch Bequemlichkeit verborgenen Verpflichtungen

Carpenters und Moores Entwurf löste ein spezifisches Bootstrap-Problem. Eine Site mit einer global eindeutigen IPv4-Adresse konnte ein 48-Bit-IPv6-Präfix unter 2002::/16 ableiten, indem sie diese IPv4-Adresse einbettete. IPv6-Pakete, die die Site verließen, konnten mit Protokoll 41 in IPv4-Pakete gekapselt werden. Für den Verkehr zwischen 6to4-Sites lieferte die eingebettete Adresse dem Border Router das benötigte IPv4-Ziel; für den Verkehr zwischen einer 6to4-Site und nativem IPv6 verband ein Relay-Router die beiden Domänen. Der Reiz war konkret: Isolierte IPv6-Domänen konnten über ein IPv4-Weitverkehrsnetz mit begrenzter manueller Konfiguration und ohne explizite Tunnel zwischen jedem Site-Paar kommunizieren. Diese Designelemente und Grenzen sind inRFC 3056festgelegt.

Das Adressformat tat mehr, als nur ein Etikett zuzuweisen. Es koppelte die Erreichbarkeit einer IPv6-Site an eine IPv4-Adresse, die global eindeutig und korrekt eingebettet sein musste. Die kapselnden und entkapselnden Knoten mussten Adressen ablehnen, die aus privatem, Broadcast-, Multicast- oder Loopback-IPv4-Raum abgeleitet waren. Auch die Adressauswahl war wichtig: Wenn sowohl native als auch 6to4-Adressen verfügbar waren, benötigten die Endpunkte kompatible Entscheidungen, und das Dokument bevorzugte standardmäßig natives IPv6, wenn beide Peers beide Formen hatten. Dies waren keine dekorativen Implementierungsdetails.

Es waren Bedingungen, unter denen die Abkürzung eine nutzbare Route darstellte und nicht nur eine IPv6-ähnliche Adresse.

Die Relay-Grenze fügte eine weitere Klasse von Verpflichtungen hinzu. Ein Relay, das Verkehr in Richtung einer nativen IPv6-Domäne transportierte, musste 2002::/16 innerhalb eines geeigneten Bereichs ankündigen und den durch diese Ankündigung angezogenen Verkehr tatsächlich akzeptieren. Carpenter und Moore warnten davor, dass eine falsche Richtlinie Nichterreichbarkeit oder perverse Verkehrsmuster erzeugen könnte. Sie beschrieben verwaltete Optionen, einschließlich expliziter Standardrouten oder Routing-Beziehungen zwischen 6to4-Routern und bereiten Relays.

Die Vereinbarung ging davon aus, dass ein Betreiber entscheidet, welchen Verkehr ein Relay zu transportieren bereit ist, und die Routensichtbarkeit mit dieser Entscheidung in Einklang bringt. Mit anderen Worten: 6to4 beseitigte die Notwendigkeit, die dazwischenliegende IPv4-Cloud aufzurüsten, aber es beseitigte nicht die Notwendigkeit rechenschaftspflichtiger Ränder.

Selbst die Übergangssequenz des ursprünglichen Dokuments legte einen langen Schweif offen. Eine Site konnte mit 6to4 beginnen, ein natives Präfix hinzufügen, wenn native Konnektivität eintraf, die Adressauswahl entscheiden lassen, welcher Pfad während der Koexistenz verwendet wurde, und die 6to4-Konfiguration erst entfernen, nachdem ihre Nutzung aufgehört hatte – möglicherweise Jahre später. Diese stufenweise Vorgehensweise war für die Kontinuität sinnvoll. Dennoch bedeutete sie auch, dass der Ausstieg von Beobachtung und Handeln an jeder bereitgestellten Site abhing.

Es gab kein zentrales Ereignis, das beweisen konnte, dass jede Abhängigkeit verschwunden war. Die technische Dezentralisierung des Mechanismus führte daher zu einer Dezentralisierung des Lebenszyklus: Die Partei, die in der Lage war, einen temporären Pfad zu aktivieren, gehörte auch zu den Parteien, die bemerken mussten, wann es sicher war, ihn zu entfernen.

Die ursprüngliche Spezifikation sah sogar diagnostische Undurchsichtigkeit vor. Eine im Trägernetzwerk erzeugte IPv4-„Unreachable"-Meldung kehrte zum 6to4-Router zurück, der oft nicht genügend Informationen hatte, um eine brauchbare ICMPv6-Fehlermeldung an den ursprünglichen IPv6-Knoten zu liefern. Das IPv4-Netzwerk konnte folglich von der IPv6-Seite aus wie eine nicht diagnostizierbare Verbindungsschicht erscheinen. Diese Beobachtung sagte nicht jeden späteren Fehler voraus, aber sie identifizierte das strukturelle Problem: Die Kapselung überschreitet eine administrative und diagnostische Naht.

Ein Fehler unterhalb des Tunnels kann real sein, während die Sicht des Endpunkts oberhalb des Tunnels unvollständig bleibt.

Deshalb wäre es irreführend, 6to4 entweder als mühelos oder einfach defekt zu beschreiben. Seine Bequemlichkeit war an Bedingungen geknüpft. Unter verwaltetem Routing, korrekter Adressauswahl, global gültiger Adressierung, funktionalen Relays und kompatibler Filterung konnte es die versprochene temporäre Konnektivität bereitstellen. Die Lebenszyklusschwierigkeit trat auf, wenn das sichtbare Benutzerversprechen – automatisches IPv6 über IPv4 – von den weniger sichtbaren Betriebsdisziplinen getrennt wurde, auf denen dieses Versprechen beruhte.

Die Einstiegskosten des Designs waren im Vergleich zur nativen Bereitstellung niedrig; seine Sicherstellungskosten waren verteilt.

Anycast senkte die Konfiguration und erhöhte die Koordinationsanforderungen

Der nächste Schritt war nicht Carpenters Design.RFC 3068, verfasst von Christian Huitema im Juni 2001, führte ein Anycast-Präfix und eine Anycast-Adresse für 6to4-Relays ein. Sein Ziel war es, die Konfiguration für Netzwerke zu vereinfachen, die nicht am IPv6-Inter-Domain-Routing teilnahmen und ansonsten ein Standard-Relay finden und konfigurieren mussten. Ein 6to4-Router konnte Verkehr an die bekannte IPv4-Adresse 192.88.99.1 leiten; das Routing würde ihn zu einem verfügbaren Relay führen, das das zugehörige Präfix ankündigt. Dies machte die Relay-Erkennung automatisch und bot routingbasiertes Failover zu einem anderen Relay, wenn eines aufhörte, den Dienst anzukündigen.

Die Erweiterung adressierte ein echtes Benutzerfreundlichkeitsproblem in der ursprünglichen verwalteten Vereinbarung. Ein kleines Netzwerk könnte ein Relay nur über das Internet finden und eine schlechte Leistung erleiden oder gar keins konfigurieren. Anycast machte „welches Relay?" zu einer Routing-Antwort statt zu einer Konfigurationsaufgabe pro Benutzer. Diese Verschiebung machte 6to4 für kleine Netzwerke und einfache Gateways zugänglicher. Sie änderte auch den Charakter der Abhängigkeit. Der Benutzer wählte kein benanntes, bereitwilliges Relay mehr aus.

Das Routingsystem wählte eine Instanz hinter einer gemeinsamen Adresse aus, und die ausgehende Instanz musste nicht das Relay sein, das später ausgewählt wurde, um Rückverkehr von nativem IPv6 zu transportieren.

Huitemas Dokument stellte klar, dass Anycast betriebliche Sorgfalt erforderte. Da der sendende Router die Relay-Instanz nicht direkt identifizierte, konnten intermittierende Ausfälle schwer zuzuordnen sein. Die Spezifikation verlangte angemessene Überwachungs- und Fehlerisolierungsverfahren. Ein Relay sollte sofort aufhören, die Route zum Anycast-Präfix einzuspeisen, wenn seine Relay-Funktion ausfiel, während eine entsprechende Unicast-Adresse einem Betreiber helfen konnte, ein bestimmtes Relay zu testen.

Das Design erkannte auch an, dass das nächste Relay zu einer 6to4-Site möglicherweise nicht die beste Route zum nativen Ziel bot, und verwies eine mögliche Umleitung auf weitere Studien. Der praktische Einsatz, so hieß es, würde Überwachungs- und Testwerkzeuge, sich weiterentwickelnde Managementpraktiken und Betriebserfahrung erfordern.

Diese Qualifikationen sind wichtig, weil der Anycast-Lebenszyklus nicht allein danach beurteilt werden kann, ob 192.88.99.1 ein elegantes Erkennungsgerät war. Das Dienstversprechen existierte nur, solange mehrere Aussagen übereinstimmten: Die Route führte irgendwohin Nützliches; das erreichte Relay akzeptierte den Verkehr des Senders; das Relay behielt native IPv6-Konnektivität; die Überwachung zog eine schlechte Route schnell zurück; ein Rückrelay kündigte 2002::/16 in der Nähe des Ziels an; Protokoll 41 überlebte zwischengeschaltete Filter; und beide Richtungen erfüllten die Sicherheitsrichtlinie.

Anycast reduzierte die Konfiguration, die diese Wahlmöglichkeiten dem Benutzer offenlegte. Es beseitigte die Wahlmöglichkeiten nicht.

Dies ist eine wiederkehrende Form des technischen Lock-ins. Es muss keinen Lieferantenvertrag oder eine absichtlich geschlossene Schnittstelle beinhalten. Ein Mechanismus kann klebrig werden, weil Bequemlichkeit Zustand an Orten verteilt, an denen kein einzelner Betreiber ein vollständiges Inventar hat. Sobald Hosts, Heim-Gateways, Transitnetzwerke, Relays, Firewalls und Inhaltsnetzwerke unabhängige Annahmen über denselben Pfad treffen, wird die Entfernung zu einer Koordinationsübung.

Ein Benutzer kann eine Adresse und eine Standardroute besitzen, die gültig aussehen, obwohl der dahinter liegende Dienst nicht bereit, nicht erreichbar oder beeinträchtigt ist. Die sichtbare Konfiguration überlebt, während die institutionelle Vereinbarung, die sie zuverlässig machen würde, fehlt.

Der Anycast-RFC verbarg dieses Risiko nicht, und es sollte Carpenter in keinem Fall angelastet werden. Huitema war der Autor. Carpenter erscheint in der Danksagung der Arbeitsgruppendiskussion, aber das ist keine Autorschaft des Anycast-Mechanismus. Der korrekte analytische Punkt ist allgemeiner: Standardsdokumente können Managementannahmen genau darlegen, aber die Bereitstellung in großem Maßstab kann dennoch das Merkmal auswählen, das sich automatisch anfühlt, und nicht die Disziplinen, die Automatisierung zuverlässig machen. Spätere Beweise offenbarten keine geheime Absicht.

Sie zeigten, dass die Betriebsannahmen im öffentlichen Internet nicht zuverlässig realisiert wurden.

Sicherheitsanalyse verwandelte Offenheit in eine Betriebshaftung

Bis 2004 hatten die Sicherheitsfolgen des automatischen Tunnelns eine eigene Analyse erhalten.RFC 3964wurde von Pekka Savola und Chirayu Patel verfasst, nicht von Carpenter. Es identifizierte zwei Merkmale hinter einem Großteil des Risikos: 6to4-Router mussten Protokoll-41-Verkehr von anderen 6to4-Routern und Relays akzeptieren und entkapseln, während Relay-Router Verkehr akzeptieren mussten, der nativen IPv6-Knoten zugeordnet war. Die resultierende Vertrauensoberfläche machte Denial-of-Service, reflektierten Denial-of-Service und Adressspoofing in mehreren Szenarien einfacher.

Das Sicherheitsproblem bestand nicht einfach darin, dass Tunneln existierte. Es bestand darin, dass das automatische Design erweiterte, wer ein gekapseltes Paket zur Verarbeitung präsentieren konnte, während die inneren und äußeren Adressbeziehungen nicht selbstauthentifizierend waren. Savola und Patel beschrieben Prüfungen, die nicht-globale IPv4-Adressen zurückweisen, eingebettete IPv4- und 6to4-Quellinformationen zur Übereinstimmung bringen, verhindern konnten, dass ein Relay Verkehr zwischen zwei 6to4-Zielen hin und her wirft, und unsinnige native-zu-native-Pakete, die durch den Tunnel ankommen, verwerfen konnten.

Diese Prüfungen waren Voraussetzungen für eine relativ sichere Implementierung, kein Versprechen, dass jede Bedrohung verschwand.

Diese Einschränkung ist wichtig. Die Analyse kam zu dem Schluss, dass selbst mit korrekten Prüfungen einige Bedrohungen für einen 6to4-Entwickler oder Relay-Betreiber schwierig oder unmöglich vollständig zu lösen blieben. Spoofing und Reflexion hingen teilweise von Filterung außerhalb der Kontrolle des Mechanismus ab. Ein Relay konnte auch schwer von der Quelle von Missbrauch zu unterscheiden sein, da es Verkehr entkapselte oder wieder einkapselte, was Untersuchungs- und Verwaltungslasten für seinen Betreiber erzeugte.

Mehrere automatische Tunnelmechanismen, die Protokoll 41 gemeinsam nutzten, konnten eine strenge Klassifizierung noch erschweren, da das Paket keine separate Kennung für den Übergangsmechanismus trug.

Diese Beweise ändern, wie der temporäre Handel bewertet werden sollte. Ein Relay war nicht nur ein hilfreicher Weiterleitungspunkt, der für den Übergang gespendet wurde. Es war eine Sicherheitsdurchsetzungsfläche, ein potenzielles Ziel, ein möglicher Verstärker und ein administrativer Kontaktpunkt. „Kostenloses Relay" beschrieb das Fehlen einer direkten Konfiguration oder Zahlung durch den Benutzer; es bedeutete nicht, dass das Relay keine Betriebskosten hatte. Überwachung, Filterung, Protokollierung, Kapazität und Incident-Handling waren Teil des Dienstes, auch wenn der Benutzer sie nie sah.

Keine dieser Erkenntnisse gehört persönlich Carpenter. Savola und Patel führten die Analyse durch und dokumentierten die Bedrohungen. Noch beweisen die Bedrohungen, dass jeder 6to4-Pfad unsicher war oder versagte. Ihre Bedeutung im Lebenszyklus ist beweiskräftig: Sie zeigten, dass ein sicherer Betrieb mehr erforderte als die Implementierung des kurzen Weiterleitungspfads. Der Sicherheitsnachweis des Mechanismus hing vom Verhalten an Routern, Relays und Netzwerkrändern ab, einschließlich Akteuren, die sich nicht gegenseitig zwingen konnten. Als diese Beweise zunahmen, verlagerte sich die Beweislast.

Es reichte nicht mehr zu zeigen, dass der Mechanismus zwei Domänen verbinden konnte; die fortgesetzte weit verbreitete Nutzung musste gegen die Kosten abgewogen werden, ein offenes, automatisches Relaysystem vertrauenswürdig zu halten.

Die Beratung von 2011: Von der Protokollmöglichkeit zu benutzersichtbaren Beweisen

Carpenters direktester individueller Beitrag zum späteren Lebenszyklus des Mechanismus warRFC 6343, den er als informativen IETF-Community-Konsensbericht nach öffentlicher Überprüfung verfasste. Sein Zweck war praktischer Natur, nicht beichtend. Er richtete sich an Internetdienstanbieter, Inhaltsanbieter und Implementierer, einschließlich Netzwerke, die selbst kein IPv6 anbieten, da ihre Kunden und Helpdesks dennoch von 6to4 betroffen sein konnten.

Die Einleitung der Beratung kehrt den Standpunkt einer Protokollspezifikation um. Anstatt zu fragen, ob Pakete unter angegebenen Bedingungen gekapselt und weitergeleitet werden können, fragt sie, was ein Benutzer erlebt, wenn diese Bedingungen nur teilweise erfüllt sind. Die Antwort umfasste lange Wiederholungsverzögerungen oder vollständige Fehler. Einige Endsysteme und Kundenrouter unterstützten 6to4, und einige Geräte aktivierten es standardmäßig, so dass Benutzer auf den Mechanismus stoßen konnten, ohne zu wissen, dass er aktiv war. Wenn sie Hilfe suchten, war die zugrunde liegende Ursache schwer zu diagnostizieren.

Das Dokument bezeichnet die Beobachtung, dass viele Helpdesks rieten, IPv6 ganz zu deaktivieren, als anekdotisch; es behauptet keine universelle Umfrage.

Diese Anekdote offenbart dennoch eine wichtige kausale Umkehrung. 6to4 sollte die frühe IPv6-Nutzung fördern, wo nativer Dienst fehlte. Wenn ein beeinträchtigter 6to4-Pfad Benutzern und Supportmitarbeitern beibrachte, dass „IPv6" das zu deaktivierende Ding war, konnte das Übergangswerkzeug das Vertrauen in die Zieltechnologie beschädigen. Der Fehler war nicht nur ein verlorenes Paket. Es war eine irreführende Zuschreibung an der menschlichen Schnittstelle: Die automatische Brücke versagte unsichtbar, während die breitere Protokollfamilie die Schuld erhielt.

Die Beratung unterschied zwischen Router 6to4 und Anycast 6to4. Das ursprüngliche Router-Design setzte eine verwaltete, kooperative Konfiguration voraus, einschließlich eines Relays, das bereit war, ausgehenden Verkehr zu transportieren. Die Anycast-Variante beseitigte die Notwendigkeit für einen Benutzer, diese Vereinbarung zu treffen, indem sie eine Standard-Relay-Adresse bereitstellte. In der Praxis sagte Carpenters Konsensbericht, dass nur wenige, wenn überhaupt, öffentliche Bereitstellungen den verwalteten Router-6to4-Empfehlungen folgten und dass Anycast 6to4 vorherrschte.

Ein Host oder Gateway konnte eine globale IPv4-Adresse sehen, ein IPv6-Ziel auflösen und daraus schließen, dass das Senden an 192.88.99.1 funktionieren würde. Diese Schlussfolgerung konnte falsch sein, obwohl jeder lokale Indikator plausibel aussah.

Die aufgezeichneten Fehler bildeten eine Kette und keinen einzelnen Fehler. Ein ausgehendes Black Hole konnte existieren, wenn eine Route zum Anycast-Präfix akzeptiert wurde, aber zu einem Filter, einem unwilligen Relay oder nirgendwo Nützlichem führte. Ein eingehendes Black Hole konnte auftreten, nachdem das ausgehende Paket ein Relay erreichte und das native Ziel antwortete, weil ein Protokoll-41-Filter das zurückkehrende gekapselte Paket blockierte. Ein Rückrelay konnte fehlen, oder ein Relay, das Erreichbarkeit zu 2002::/16 ankündigte, könnte Verkehr zurückweisen, den es angezogen hatte.

Wenn beide Richtungen existierten, konnten unverwaltete und möglicherweise unterschiedliche Relays dennoch große oder variable Umlaufzeiten erzeugen.

Path-MTU-Entdeckung erzeugte einen trügerischeren Fehler. Die Kapselung reduzierte die nutzbare Path-MTU. Kleine Diagnosepakete und sogar der anfängliche TCP-Handshake konnten erfolgreich sein, während größere Datenpakete verschwanden, wenn „Packet Too Big"-Informationen nicht korrekt reisten oder die Behandlung der maximalen Segmentgröße fehlschlug. Ein Benutzer könnte daher eine Site erreichen, eine andere nur anpingen und keinen offensichtlichen Hinweis sehen, dass der Tunnel die Trennlinie war.

Dies ist ein Fehler mit höheren Kosten als eine saubere Ablehnung, weil erfolgreiche Vorbereitungen einen Betreiber auf die falsche Diagnosespur schicken.

Andere Fehler legten die Kopplung zwischen Adressbeweis und Realität offen. Ein global aussehender IPv4-Wert, der wie privater Raum verwendet wurde, konnte ein 6to4-Präfix ohne gültigen Rückweg erzeugen. Carrier-Grade-Address-Translation konnte die Annahme brechen, dass die eingebettete Adresse den erreichbaren Tunnelendpunkt darstellte. Einige Implementierungen aktivierten sich Berichten zufolge sogar mit privaten IPv4-Adressen, entgegen der ursprünglichen Spezifikation. Reverse-DNS-Prüfungen konnten auch 6to4-Clients zurückweisen, denen Delegationen fehlten.

Keine dieser Bedingungen war universell; zusammen machten sie ein Symptom wie „Webseiten sind langsam" mit zu vielen Ursachen kompatibel.

RFC 6343 enthielt Messungen aus Experimenten, machte sie aber nicht zu einer universellen Bereitstellungsstatistik. Es zitierte beobachtete 6to4-Verbindungsfehlerraten von 9–20 Prozent in einem Experiment und 9–19 Prozent in einem anderen, unter ihren angegebenen Methoden. Es beschrieb auch einen Gesamtverlust, gemessen als Bruchteil eines Prozents der Versuche an Dual-Stack-Inhaltsservern, da nur eine Teilmenge der Clients 6to4 versuchte. Die Beratung stellte ausdrücklich eine erhebliche erfolgreiche Nutzung fest. Die disziplinierte Schlussfolgerung ist daher nicht, dass ein fester Anteil des Internets kaputt war.

Es ist, dass Fehler unter den untersuchten 6to4-Versuchen wesentlich waren, während selbst ein kleiner aggregierter Anteil für Anbieter von Bedeutung sein und Benutzerverzögerungen und Supportnachfrage erzeugen konnte.

Das Dokument brachte diese Fehler mit finanziellen Auswirkungen für Inhaltsanbieter und wahrscheinlichen Helpdesk-Kosten in Verbindung, lieferte aber keine genaue Gesamtsumme und schrieb diese Kosten nicht Carpenter zu. Herstellervorgaben, Betreiberrouting, Relay-Verhalten, Firewalls und Client-Fallback bestimmten bestimmte Ergebnisse. Carpenters rechenschaftspflichtige Handlung bestand darin, die Mechanismusevidenz und Betriebsevidenz in einem Bericht zusammenzustellen, der die betroffenen Rollen benannte. Er verwandelte die verteilte Bereitstellungsgeschichte nicht in eine Geschichte über seinen eigenen Erfolg oder Misserfolg.

Diese Formwahl ist wichtig. Ein Rückblick, der um die persönliche Absicht herum geschrieben wurde, hätte fragen können, ob die Autoren von 2001 recht gehabt hatten. Die Beratung fragte stattdessen, was jeder aktuelle Akteur tun könnte. Anbieter und Implementierer wurden angewiesen, Anycast 6to4 nicht standardmäßig zu aktivieren und Implementierungen zu korrigieren, die auf privaten Adressen aktiviert wurden. Netzwerke ohne IPv6 wurden angewiesen, zu überprüfen, ob die Route zur Anycast-Adresse explizit, stabil, angemessen nah und von einem bereitwilligen Relay akzeptiert wurde.

Netzwerke mit nativem IPv6 wurden ermutigt, Benutzer von 6to4 wegzuführen und sicherzustellen, dass sie nicht versehentlich zu Relays geworden waren. Transit- und Inhaltsanbieter erhielten separate Leitlinien zu Routing, Rückweg, Kapazität und Filterung.

Diese rollenspezifische Struktur ist ein Beweis für technische Rechenschaftspflicht, weil sie der Kontrolle folgt. Ein Anbieter kann eine Standardeinstellung ändern, aber nicht jede Transitroute reparieren. Ein Zugangsanbieter kann Erreichbarkeit testen oder einen expliziten Fehler zurückgeben, aber kann kein entferntes Inhaltsnetzwerk zwingen, ein Rückrelay zu betreiben. Ein Inhaltsanbieter kann ein Relay in der Nähe seiner Server platzieren, aber kann kein fehlerhaftes Gateway eines Benutzers entfernen.

Die Zuweisung von Ratschlägen an den Akteur mit der relevanten Kontrollfläche vermeidet zwei entgegengesetzte Fehler: ein kollektives Versagen als niemandes Verantwortung zu behandeln oder einen einzelnen benannten Standardsautor für jede Implementierungs- und Netzwerkentscheidung verantwortlich zu machen.

Die Eindämmung offenbarte die Kosten, den Zwischenzustand am Leben zu erhalten

Die Leitlinien von 2011 waren noch keine Ablehnung. Sie versuchten, Schaden zu reduzieren, während eine große installierte Basis bestehen blieb. Für einen Anbieter ohne IPv6-Dienst musste eine Route zu 192.88.99.1 mehr als eine Standardroute sein: Sie musste zu einem funktionalen, stabilen und bereitwilligen Relay führen. Wenn dies nicht festgestellt werden konnte, schlug die Beratung vor, eine explizite Unreachable-Antwort in Betracht zu ziehen, damit einige Clients schneller zurückfallen könnten, während sie gleichzeitig die begrenzte Betriebserfahrung mit dieser Taktik anerkannte.

Das bloße Verwerfen von Protokoll 41 war keine saubere Lösung, da es 6to4 stillschweigend verschlechterte und auch absichtlich konfigurierte IPv6-Tunnel schädigte.

Für Transit-Anbieter, die sich entschieden, den Dienst zu unterstützen, waren die Verpflichtungen erheblich. Das IPv4-Anycast-Präfix durfte nur gegenüber Client-Netzwerken angekündigt werden, deren Verkehr akzeptiert würde. Die 2002::/16-Route musste so eingegrenzt werden, dass jeder durch sie angezogene Verkehr tatsächlich weitergeleitet werden konnte. Die Rückquelladresse des Relays musste im Hinblick auf Stateful Firewalls und Ingress-Filterung ausgewählt werden. Protokoll 41 und notwendige ICMPv6-Nachrichten mussten passieren. Die Kapazität musste überwacht und erweiterbar sein, während unverwaltete Relays vermieden werden mussten. Diese Anforderungen stammten ausRFC 6343, nicht aus der Behauptung, dass eine Konfiguration für jeden Betreiber passte.

Inhaltsanbieter standen vor einer besonders aufschlussreichen Asymmetrie. Ein 6to4-Client konnte einen Dual-Stack-Server über ein Relay erreichen, während die Antwort des Servers von einer anderen Route zu 2002::/16 abhing. Die Beratung empfahl ein lokal positioniertes Rückrelay und eine sorgfältige Routing-Eingrenzung, damit der Rückweg kurz und funktional war. Das bedeutete, dass ein Anbieter, der natives IPv6 korrekt bereitgestellt hatte, dennoch Infrastruktur für Clients benötigen konnte, die anderswo einen unverwalteten Übergangsmechanismus verwendeten.

Die Kosten der Kompatibilität waren zu der Partei gewandert, die das Ziel bediente, nicht unbedingt zu der Partei, die 6to4 aktivierte.

Hier treffen Software-Lebenszyklus und Netzwerkressourcen-Nachweise aufeinander. Ein Merkmal kann in der Entwurfsabsicht „Legacy" sein, während es in den Betriebskosten aktuell bleibt. Routen, Paketfilter, Relay-Kapazität und Supportfälle sind keine abstrakten Spuren von altem Code; sie sind Ressourcen, die jetzt verbraucht werden. Die Beratung von 2011 machte diese Ressourcen effektiv sichtbar. Sie zeigte, dass die Aufrechterhaltung der Kompatibilität ein aktiver Dienst war, der Überwachung und Richtlinien erforderte, nicht passive Toleranz eines alten Adressformats.

Sie legte auch die Schwäche einer binären Entscheidung zwischen „funktioniert" und „funktioniert nicht" offen. Anycast 6to4 konnte für viele Pfade funktionieren und für eine Teilmenge je nach Routing-Bereich, Relay-Bereitschaft, Firewall-Zustand, MTU und Rücktopologie versagen. Ein Mechanismus mit teilweisem, pfadabhängigem Erfolg ist schwieriger zu entfernen als einer, der sauber versagt, weil erfolgreiche Benutzer ein legitimes Interesse an Kontinuität haben, während erfolglose Benutzer möglicherweise nicht einmal wissen, welches Merkmal verantwortlich ist.

Die angemessene Antwort muss daher neue automatische Aktivierung reduzieren, expliziten Betrieb dort bewahren, wo er gerechtfertigt ist, und gemeinsame Infrastruktur nur im Hinblick auf restlichen Verkehr entfernen. Diese Logik sollte das Rückgrat der Grenze von 2015 werden.

Happy Eyeballs begrenzte Schäden; es reparierte 6to4 nicht

Client-Software lieferte eine weitere Ebene der Eindämmung.RFC 6555, verfasst von Dan Wing und Andrew Yourtchenko im Jahr 2012, befasste sich mit der Verzögerung, die eine Dual-Stack-Anwendung erfährt, wenn ein IPv6-Pfad beeinträchtigt ist, IPv4 jedoch funktioniert. Defektes 6to4 war eine von mehreren aufgeführten Ursachen, neben anderen defekten Tunneln, fehlender IPv6-Konnektivität und Peering-Problemen. Der Algorithmus versuchte schnell die andere Adressfamilie, wenn die bevorzugte Verbindung nicht abgeschlossen wurde, verwendete die erfolgreiche Verbindung und konnte Ergebnisse speichern, um wiederholte Belastung des Netzwerks zu vermeiden.

Happy Eyeballs änderte die benutzersichtbare Konsequenz eines schlechten Pfads. Anstatt auf ein langes IPv6-Timeout zu warten, bevor IPv4 versucht wird, konnte eine Anwendung Versuche überlappen oder eng staffeln und mit der funktionierenden Familie fortfahren. Das war wertvolle Schadensbegrenzung. Es reduzierte die Wahrscheinlichkeit, dass ein Benutzer die volle in RFC 6343 beschriebene Verzögerung erlebte, und schwächte den Anreiz, IPv6 pauschal zu deaktivieren, nur um Anwendungen reaktionsfähig zu machen.

Aber die Unterscheidung zwischen Eindämmung und Reparatur muss genau bleiben. Happy Eyeballs ließ kein fehlendes Relay erscheinen, öffnete keinen Protokoll-41-Filter, korrigierte keine ungültige eingebettete Adresse, stellte die Path-MTU-Erkennung nicht wieder her und sicherte keinen 6to4-Tunnel. Es wählte einen beeinträchtigten Pfad auf Client-Seite aus. Wing und Yourtchenko stellten auch den Kompromiss fest: Zusätzliche Versuche erzeugen eine gewisse Netzwerk- und Serverlast, daher sollte der Algorithmus wahllose gleichzeitige Verbindungen vermeiden und nicht gewinnende aufgeben.

Die Eindämmung konnte auch Infrastrukturfehler weniger sichtbar machen. RFC 6555 stellte fest, dass Anwendungen, die die Technik verwenden, standardmäßig weniger nützlich für die Diagnose einer bestimmten Adressfamilie sind, da eine erfolgreiche Alternative den Fehler maskiert. RFC 7526 sagte später, viele Browser hätten 6to4-Fehlermodi durch Happy Eyeballs vor Benutzern verborgen. „Verborgen" bedeutet hier nicht gelöst. Es bedeutet, dass die Transaktion des Benutzers erfolgreich sein kann, während der fehlgeschlagene 6to4-Versuch weiterhin Teil des Hintergrundzustands des Netzwerks bleibt.

Dies schafft ein Lebenszyklus-Paradoxon. Ein guter Kompatibilitätsmechanismus schützt Benutzer während des Übergangs, aber durch die Abschwächung der Symptome kann er den Druck verringern, die Ursache zu beseitigen. Die richtige Lektion ist nicht, Client-Resilienz abzulehnen. Es ist, die Schichten in der Politik getrennt zu halten: Messen und reparieren oder den beeinträchtigten Netzwerkmechanismus zurückziehen, selbst wenn Anwendungen gelernt haben, ihn zu umgehen. Sonst wird Erfolg auf der Anwendungsebene zu falschem Beweis, dass der zugrunde liegende Übergangsdienst gesund bleibt.

Die Entscheidung von 2015 war bewusst enger als „6to4 in Rente schicken"

Der Titel vonRFC 7526gibt seinen Umfang an: „Deprecating the Anycast Prefix for 6to4 Relay Routers." Ole Troan war der Autor; Brian Carpenter war der Herausgeber. Das Dokument wurde im Mai 2015 als IETF Best Current Practice veröffentlicht, die den Gemeinschaftskonsens repräsentiert. Es erklärte RFC 3068 und den zugehörigen vom Anbieter verwalteten Anycast-Rahmen für historisch, erklärte den Anycast-Mechanismus und die zugehörige Adresse 192.88.99.1 für veraltet und empfahl, dass zukünftige Produkte 6to4-Anycast nicht unterstützen sollten.

Der negative Raum ist genauso wichtig. RFC 7526 sagt ausdrücklich, dass grundlegendes Unicast-6to4, wie von RFC 3056 definiert, und das IPv6-Präfix 2002::/16 nicht veraltet waren. Peer-to-Peer-Nutzung unabhängig vom Anycast-Dienst lag außerhalb des Ziels. Das Dokument empfahl nicht die allgemeine Filterung des gesamten 6to4-Verkehrs oder aller 6to4-Routen. Betreiber konnten weiterhin Rückrelays für verbleibende Clients betreiben, und diejenigen, die den Anycast-Dienst fortsetzten, wurden weiterhin auf die Betriebsanleitung in RFC 6343 verwiesen.

Die Implementierungsstandards wurden strenger. Neue Implementierungen sollten Anycast 6to4 nicht enthalten; wenn doch, musste es standardmäßig deaktiviert sein. Host-Implementierungen mussten auch Unicast-6to4 standardmäßig deaktiviert lassen und die aktualisierte IPv6-Adressauswahlrichtlinie unterstützen. Router-Implementierungen mussten 6to4 standardmäßig deaktivieren, und die Aktivierung der IPv6-Weiterleitung konnte es nicht stillschweigend aktivieren. Diese Bestimmungen widersprachen nicht der Aussage, dass Unicast-6to4 nicht veraltet war.

Status und Standard sind unterschiedliche politische Instrumente: Eines bewahrt einen definierten Mechanismus für explizite, begrenzte Nutzung; das andere verhindert, dass versehentliche Aktivierung das unverwaltete Bereitstellungsproblem reproduziert.

Der betriebliche Rückzug war ebenfalls schrittweise und nicht augenblicklich. Ein Netzwerk sollte keine Route zu 192.88.99.1 ankündigen, es sei denn, es betrieb und überwachte aktiv ein Anycast-Relay. Bestehende Relay-Betreiber wurden angewiesen, zu prüfen, ob der Dienst eingestellt werden könnte, wenn der Verkehr nachließ. Anbieter, die 2002::/16 an ihre Kunden ankündigten, sollten dies nur tun, wenn es zu einem korrekt funktionierenden Rückrelay führte.

Dies erkannte an, dass ein Ablehnungsdokument keine bereitgestellten Clients löscht und dass ein vorzeitiger Rückzug genau die Black Holes erzeugen kann, die die Richtlinie zu reduzieren versucht.

Das Dokument stellte sogar klar, dass „deprecate" im gewöhnlichen Sinne von Missbilligung verwendet wurde, nicht als magische normative Operation, die Code aus dem Internet entfernte. Eine veraltete Funktion könnte jahrelang aus Gründen der Abwärtskompatibilität bestehen bleiben. Das ist eine ungewöhnlich nützliche Aussage des Lebenszyklus-Realismus. Der Standardsstatus kann die Richtung neuer Implementierung und Bereitstellung ändern. Er kann nicht jedes Produkt, jede Route oder jede Betreiberentscheidung synchron aktualisieren.

Carpenters redaktionelle Rolle gehört in diese begrenzte institutionelle Handlung. Es ist vernünftig, Kontinuität zwischen der temporären Grenze, die er 2001 mitverfasste, dem Betriebsbericht, den er 2011 verfasste, und der begrenzten Ablehnung, die er 2015 herausgab, zu sehen; derIETF-Datatracker-Eintraglistet diese Rollen. Es ist nicht vernünftig, diese Kontinuität in eine Behauptung zu verwandeln, dass er persönlich 6to4 in Rente geschickt hat. Troan verfasste RFC 7526, und seine Autorität kam vom IETF Best Current Practice-Prozess und dem Gemeinschaftskonsens.

Diese Unterscheidung schützt die Qualität der Technikgeschichte. Die Personalisierung der Entscheidung würde Carpenters Kontrolle über den Standardsstatus übertreiben, während die von Betreibern, Implementierern, Forschern und Benutzern gelieferten Beweise verschleiert würden. Eine vollständige Entpersonalisierung würde die Rechenschaftspflicht übersehen, die darin besteht, über den gesamten Lebenszyklus hinweg engagiert zu bleiben.

Die genaue Mitte ist stärker: Carpenter beteiligte sich an der Definition des temporären Mechanismus, setzte später seinen Namen unter seine Betriebskosten und redigierte eine Gemeinschaftsentscheidung, deren Umfang eng genug gezogen war, um den Beweisen zu entsprechen.

Wie verantwortungsvolle Technik über einen langen Übergang aussieht

Der 6to4-Bericht bietet drei Tests für technische Rechenschaftspflicht. Der erste ist, ob das ursprüngliche Versprechen seine eigene Grenze enthält. RFC 3056 tat dies. Es beschrieb 6to4 als optional und vorübergehend, bevorzugte natives IPv6, wo verfügbar, und legte eine Sequenz für die eventuelle Entfernung fest. Carpenter und Moore vermarkteten keinen Tunnel über IPv4 als permanente Architektur von IPv6.

Der zweite Test ist, ob spätere Beweise die Betriebsempfehlung ändern dürfen. RFC 6343 verteidigte den Mechanismus nicht, indem es seine beabsichtigte Topologie wiederholte. Es begann mit beobachteten Benutzerergebnissen und verfolgte sie zurück durch Routen, Relays, Filter, Adressannahmen und MTU-Verhalten. Es hielt auch die Beweisgrenzen sichtbar: Einige Helpdesk-Verhaltensweisen waren anekdotisch; bestimmte Fehlerraten gehörten zu zitierten Experimenten; erfolgreiche Nutzung existierte; es wurde keine universelle Kostensumme behauptet.

Diese Disziplin ist wichtig, weil schwache Beweise ebenso leicht ein übermäßiges Mittel erzeugen können wie Leugnung eine schädliche Standardeinstellung bewahren kann.

Der dritte Test ist, ob der Rückzug proportional zu dem ist, was die Beweise feststellen. RFC 7526 zielte auf Anycast 6to4, den Modus, der als ungeeignet für den weit verbreiteten Internet-Einsatz beurteilt wurde. Es verschärfte die Standards allgemeiner, um unsichtbare Aktivierung zu verhindern, aber es gab nicht vor, dass die grundlegende Unicast-Nutzung und 2002::/16 abgeschafft worden waren. Es bewahrte Betriebsanleitungen für restliche Dienste und band den Routenursprung an aktive Überwachung. Das Mittel folgte dem Fehlermechanismus statt dem Wunsch nach einer einfachen Schlagzeile.

Diese Tests erklären auch, warum Carpenters Geschichte nicht als Triumph dargestellt werden sollte. Das Ziel von nativem IPv6 macht nicht jedes Übergangsexperiment zu einem heroischen Meilenstein, und der eingefrorene Bericht liefert keine Grundlage für die Behauptung, dass die Einführung oder Ablehnung von 6to4 ihm gehörte. Es ist auch keine Geschichte des persönlichen Scheiterns. Anbieter wählten Voreinstellungen; Betreiber wählten Routen und Filter; Relay-Instanzen verhielten sich unterschiedlich; Anwendungen wählten Fallback-Strategien; Benutzer erlebten den kombinierten Pfad.

Die kausale Verantwortung war verteilt, weil die Kontrolle verteilt war.

Was Carpenters dokumentierte Rollen zeigen, ist die Bereitschaft, mit den Konsequenzen früherer Arbeit verbunden zu bleiben, ohne Anspruch auf Kontrolle über sie zu erheben. Die Mitautorschaft im Jahr 2001 schuf eine öffentliche technische Verpflichtung mit angegebenen Grenzen. Die Autorschaft im Jahr 2011 akzeptierte, dass die reale Bereitstellung Kosten verursacht hatte, die der ursprüngliche Mechanismus nicht wegdiskutieren konnte. Die Herausgeberschaft im Jahr 2015 half, ein Konsensmittel auszudrücken, das nicht übers Ziel hinausschoß. Dies ist weniger filmreif als Erfindung gefolgt von Reue.

Es ist auch ein nützlicheres Muster für Infrastruktur, wo kein Autor allein entscheiden darf, wie lange bereitgestellter Code, Adressen und Routen bestehen bleiben.

Es gibt hier eine breitere Lektion über institutionelle Legitimität, aber sie gründet im Mechanismus und nicht in einem allgemeinen Aufsatz über Standards. Legitimität entstand aus der Übereinstimmung von Behauptungen mit Rollen und Mitteln mit Beweisen. Huitema bleibt der Autor der Anycast-Erweiterung. Savola und Patel bleiben die Autoren der dedizierten Sicherheitsanalyse. Wing und Yourtchenko bleiben die Autoren der clientseitigen Latenzminderung. Troan bleibt der Autor der Ablehnung, mit Carpenter als Herausgeber.

Klare Zuschreibung verhindert, dass Autorität um einen berühmten Namen herum aufgebaut wird, und macht den Kausalbericht prüfbar.

Der Bericht zeigt auch, warum Netzwerkressourcen-Nachweise für Lebenszyklusentscheidungen wichtig sind. Ein Übergangsmechanismus wird nicht nur ausgemustert, weil eine neuere Architektur vorzuziehen ist. Sein fortgesetzter Wert und seine Kosten erscheinen in erreichbaren Präfixen, funktionierenden Relays, fehlgeschlagenen Handshakes, Pfadverzögerungen, MTU-Verhalten, Filterung und restlichem Client-Verkehr. Diese Signale sind unvollkommen und verteilt, aber sie sind dem Mechanismus näher als eine Absichtserklärung.

Die Entscheidung von 2015 wurde glaubwürdig, weil sie die ursprüngliche temporäre Grenze mit Jahren an Sicherheits- und Betriebserkenntnissen verband und dann einen Umfang zog, den Betreiber tatsächlich umsetzen konnten.

Fazit

6to4 begann mit einer Ablaufbedingung, aber ohne universelle Uhr. Carpenter und Moore erwarteten die Migration zu nativem IPv6; Huitemas Anycast-Erweiterung machte den temporären Weg leichter zu beschreiten; Savola und Patel dokumentierten die Sicherheitslast; Carpenters Beratung von 2011 zeigte, wie verteilte Fehler die Benutzer und Helpdesks erreichten; Wing und Yourtchenko begrenzten einige Verzögerungen auf Client-Seite; und Troans Best Current Practice von 2015, herausgegeben von Carpenter, erklärte den Anycast-Modus für veraltet, ohne alles 6to4 für tot zu erklären.

Carpenters Bedeutung in dieser Sequenz liegt in Kontinuität ohne Aneignung. Er kontrollierte nicht die kollektive Bereitstellung, und er zog sich nicht persönlich zurück. Sein Bericht demonstriert stattdessen eine härtere Form der Verantwortung: den temporären Handel benennen, dokumentieren, wenn seine versteckten Betriebskosten sichtbar werden, und helfen, das Mittel auf den Mechanismus einzugrenzen, den die Beweise rechtfertigen können.

Quellen