Zusammenfassung

  • RFC 5211 entwarf Vorbereitung, Übergang und eine Phase ab Januar 2012 mit überwiegend IPv6-basierter Konnektivität. Zugleich bezeichnete sich das Dokument als ein möglicher, rein informativer Plan ohne Verpflichtung für Beteiligte.
  • Datum und MUST können Erwartungen präzisieren. Sie beweisen weder Bestellbarkeit noch Bereitstellung, Rückrouting, Pfadwahl, Verkehr, Anwendungserfolg oder die sichere Ablösung von IPv4.

Eine Zeitmarke ist kein Messpunkt

RFC 5211 erschien im Juli 2008. Das Dokument wollte die Erwartungen vieler unabhängiger Provider, Hersteller und Endorganisationen koordinieren. Die Vorbereitung sollte Ende 2009 enden, der Übergang 2010 und 2011 stattfinden und die Nach-Übergangsphase im Januar 2012 beginnen.

Seine Reichweite war ausdrücklich begrenzt. Es handelte sich um einen möglichen Plan; Alternativen blieben offen. Der Text schuf keine Verpflichtung. Die Schlüsselwörter aus RFC 2119 dienten nur der eindeutigen Beschreibung. Laut IESG-Notiz war RFC 5211 kein Kandidat für einen Internetstandard und nicht Ergebnis der üblichen IETF-Konsensprüfung.

Damit konnte das Dokument Debatten ordnen und Investitionen anstoßen. Es konnte aber kein Produkt freischalten, keinen Router konfigurieren und keinen Dienst prüfen. Als 2012 begann, war nur der Kalenderzustand sicher.

Hinter „anbieten“ liegen viele Systeme

TRANS1 und POST1 verlangen im vorgeschlagenen Plan ein IPv6-Angebot der Provider. Operativ zerfällt dieses Verb: Eintrag im Produktkatalog, Markt und Zugangstyp, Qualifizierung, angenommener Auftrag, Präfix, Kundengerät, Hinroute, Rückroute, DNS, Überwachung und Produktionssupport.

Der Katalog kann grün sein, während die Bestellung scheitert. Ein Präfix kann eingerichtet sein, ohne dass Rückverkehr ankommt. Routing kann vorhanden sein, während die Adressauswahl IPv4 bevorzugt. Eine Sonde kann antworten, obwohl Anmeldung, Bezahlung, Mail oder externe APIs nicht funktionieren.

Auch eine veröffentlichte AAAA-Adresse ist nur ein Publikationsbeleg. Auflösung, Auswahl, Verbindung, Transaktion und dauerhafte Dienstqualität sind eigene Ereignisse. Ein erfolgreicher Test von einem Standort liefert keine Aussage über alle Nutzer, Anwendungen oder Zeiten. „Überwiegend“ braucht immer Metrik, Grundgesamtheit und Messfenster.

Großschreibung erzeugte keine Aufsicht

RFC 5211 nutzte MUST, SHOULD und MAY, um den Plan scharf zu formulieren. Gleichzeitig verneinte es eine daraus entstehende Pflicht. Es definierte weder Prüfer noch Sanktionsweg, Messpopulation oder einheitliche Prüfung.

Der Bedeutungsverlust beginnt beim Weiterreichen. Aus „Provider MUST offer“ wird in der Beschaffung eine Spalte und in der Vorstandsvorlage „Übergang abgeschlossen“. Provider, Produkt, Region, Kunde, Zeitpunkt und Nachweis sind verschwunden; übrig bleibt die typografische Stärke.

Jedes Verb braucht daher einen Gegenstand und einen Beleg. Angebot: Produkt und angenommener Auftrag. Aktivierung: Konfiguration und Route. Produktion: Transaktion und Support. Dominanz: Metrik und Nenner. Abschaltung: Abhängigkeitsinventar, Ausnahmen und geprobter Rückweg.

POST4 ließ IPv4 ausdrücklich bestehen

Die Nach-Übergangsphase bedeutete nicht, IPv4 auszuschalten. POST4 erlaubte Providern weiterhin IPv4 anzubieten und Organisationen, es weiter zu nutzen. Das Ziel war eine asymmetrische Koexistenz, nicht ein globaler Schalter.

Spätere RFCs behandelten deshalb Dual Stack, Übersetzung, Customer-Edge-Geräte, Inhalte, Unternehmen, Sicherheit und IPv4-as-a-Service getrennt. Ein IPv6-only-Kern, IPv4aaS, dual angebundene Inhalte und eine alte IPv4-Anwendung können im selben Betrieb existieren. Sie besitzen nicht denselben Reifegrad.

Zu frühes Entfernen von IPv4 kann verborgene Abhängigkeiten zerstören. Unbegrenztes Beibehalten konserviert Kosten, Angriffsfläche und Trägheit. Der Kalender entscheidet diesen Zielkonflikt nicht.

Papierfortschritt ist kein Betriebsverlauf

RFC 6144 hielt 2011 fest, dass die Erschöpfung von IPv4-Adressen wahrscheinlich vor einer erheblichen IPv6-Einführung eintreten würde. RFC 6180 erwartete einen langen Auslauf. RFC 6540 erhob IPv6-Unterstützung für IP-fähige Knoten später zur Best Current Practice. Weitere Dokumente konkretisierten Inhalte, Kundengeräte und Unternehmensnetze.

Diese Entwicklung zeigt bessere Spezifikation, nicht automatisch Umsetzung. Dokumentstatus, implementierter Code, aktivierte Option, eingesetzter Pfad und beobachtetes Ergebnis sind getrennte Zustände. Ebenso beweist ein verfehltes Datum keinen Protokollfehler. Ursachen liegen möglicherweise in Beschaffung, Anreizen, Altlasten, Produktreife oder lokalem Risiko und brauchen eigene Belege.

Ein belastbarer Übergang hat eine Belegkette

Der Nachweis beginnt bei Plan, Verantwortlichem und Budget. Danach folgen Produktangebot, Auftrag, Bereitstellung, Adressierung, DNS, Hin- und Rückroute, Pfadwahl, Verkehrsbeobachtung, Anwendungsergebnis, Kontinuität, Ausnahmen und Stilllegungsentscheidung. Jeder Eintrag nennt Zeit, Umfang, Akteur und Herkunft.

Dafür ist keine zentrale Allzuständigkeit nötig. Ein kleines gemeinsames Schema für Evidenz genügt; lokale Netze behalten Schwellenwerte und Entscheidungsrecht. Freiwillige Koordination wird prüfbar, ohne die Ausführung zu zentralisieren.

Das Datum bleibt nützlich, wenn es eine Überprüfung auslöst. Weicht der Betrieb vom Plan ab, wird der Plan geändert. Der Betrieb erhält keinen neuen Namen, nur damit das Gantt-Diagramm stimmt.

Quellen

  1. Informationen zu RFC 5211
  2. RFC 5211 als HTML
  3. RFC 5211 als Text
  4. IETF Datatracker: RFC 5211
  5. Historie von RFC 5211
  6. Referenzen zu RFC 5211
  7. Errata zu RFC 5211
  8. RFC 3932 — unabhängige Einreichungen
  9. RFC 2119 — Anforderungswörter
  10. RFC 8174 — Aktualisierung von BCP 14
  11. RFC 6144 — IPv4/IPv6-Übersetzung
  12. RFC 6180 — IPv6-Übergangsleitlinien
  13. RFC 6540 — erforderliche IPv6-Unterstützung
  14. RFC 6589 — Inhaltsmigration
  15. RFC 7084 — Customer-Edge-Anforderungen
  16. RFC 7381 — Unternehmensbereitstellung
  17. RFC 8170 — Bereitstellungsszenarien
  18. RFC 9099 — betriebliche IPv6-Sicherheit
  19. RFC 9313 — IPv4-as-a-Service-Techniken
  20. Heng Lu — Realitätsebenen und symbolische Macht
  21. Heng Lu — minimale Anfangsspezifikation
  22. Heng Lu — Primat des laufenden Codes