Zusammenfassung

  • Fujisaki war Mitautor von IETF-Dokumenten zur IPv6-Adressauswahl bei mehreren Präfixen und später einer DHCPv6-Spezifikation zur Verteilung lokaler Richtlinien.
  • Bei APNIC wurde eine Änderung der Aggregationskriterien für Erstzuteilungen umgesetzt; spätere Vorschläge für größere Blöcke fanden keinen Konsens.
  • Die Dokumente belegen Standards und Verfahrensausgänge. Sie messen weder die Verbreitung von RFC 7078 noch die Betriebswirkung der Zuteilungsregeln.

Eine gültige Adresse passt nicht automatisch zum Pfad

Ein Host kann mehrere IPv6-Adressen auf derselben Verbindung haben. Beim Senden wählt er eine Quelladresse. Routing, Filter und Rückweg müssen zu dieser Wahl passen. RFC 5220 beschreibt Fälle, in denen das misslingt: Ein Eingangsfilter verwirft das Paket, der Weg wird asymmetrisch oder für die Antwort fehlt eine brauchbare Route. Der Fehler erscheint in der Kommunikation, kann aber aus dem Zusammenspiel lokaler Hostregeln und der Netzstruktur entstehen.

RFC 5220 erschien im Juli 2008 als Informational-Memorandum von Arifumi Matsumoto, Tomohiro Fujisaki, R. Hiromi und K. Kanayama. Es beschreibt eine Problemklasse, keinen einzelnen Ausfall und keine Häufigkeit. Im Mittelpunkt stehen Endnetze und Hosts, die sich nicht einzeln verwalten lassen. Eine große Geräteflotte kann nicht sinnvoll auf manuelle Pflege komplexer Tabellen durch alle Nutzer setzen.

Die RFC 5221, im selben Monat von denselben Autoren veröffentlicht, übersetzt die Fälle in Anforderungen: Informationen sollen vor der Auswahl eintreffen und sich mit dem Netz ändern; verschiedene Knoten, Anwendungen und Schnittstellen müssen berücksichtigt werden. Zentrale Verwaltung, Kompatibilität mit dem bestehenden Algorithmus und Sicherheit gehören ebenfalls dazu. Die RFC formuliert Anforderungen, keine bereits erzielten Ergebnisse.

Verteilung lässt die Kontrolle des Hosts bestehen

2014 legten Arifumi Matsumoto, Fujisaki und Tim Chown mit RFC 7078 eine DHCPv6-Option für die Adressauswahl fest. Ein Standort kann eine Richtlinientabelle und Parameter verteilen, die Vorgaben der RFC 6724 ändern. Die Dokumente führen vom Problem über die Anforderungen zu einem standardisierten Mechanismus.

Der DHCPv6-Server wird dadurch nicht zur uneingeschränkten Steuerinstanz jedes Endgeräts. RFC 7078 beschreibt die Option als Information, die der Host verarbeitet, und berücksichtigt lokale Einstellungen. Das Netz kann eine Präferenz senden; das tatsächliche Verhalten hängt auch von Implementierung und Konfiguration des Hosts ab.

Die Spezifikation benennt konkrete Risiken: Ein bösartiger Server könnte falsche Richtlinien verteilen und Clients zu gefilterten Adressen, unerwarteten Gebühren oder gefährlichen Zielen führen. Sie behandelt vertrauenswürdige Übertragungswege und nennt DHCP Snooping auf Layer 2 als Schutzmaßnahme. Große Tabellen können Nachrichten erzeugen, die manche Clients, Server oder Relays nicht zuverlässig übertragen. Die Standardisierung beweist nicht, dass vorhandene Geräte die Option unterstützen.

Zuteilungspolitik ist eine andere Entscheidung

Fujisakis APNIC-Vorschläge betreffen den verfügbaren Adressraum, nicht die Auswahl des Hosts. Prop-076 wurde von mehreren Autoren eingebracht und sollte Aggregation bei späteren IPv6-Zuteilungen verlangen. Nach Diskussion zogen die Autoren den Vorschlag zurück. Die gemeinsame prop-082 wollte Aggregationskriterien aus der IPv6-Erstzuteilung entfernen. APNIC hält fest, dass sie bei APNIC 29 Konsens fand, vom Executive Council bestätigt und am 5. Juli 2010 umgesetzt wurde. Das belegt eine Regeländerung, keine gemessene Netzwerkwirkung.

Fujisakis prop-087 sollte in bestimmten, in RFCs beschriebenen Einführungsphasen eine Erstzuteilung größer als /32 erlauben. Der Vorschlag fand keinen Konsens und wurde im August 2011 zurückgezogen. Die prop-111 schlug 2014 eine Erweiterung bis /29 vor, erreichte laut APNIC aber weder bei APNIC 37 noch bei APNIC 38 Konsens. Die prop-112 von 2015 bot älteren IPv6-Blockinhabern einen anderen Erweiterungsweg; auch sie wurde ohne Konsens aufgegeben.

Die Bilanz ist gemischt: Eine Anpassung der Erstzuteilung wurde umgesetzt, mehrere spätere Anträge auf größere Blöcke wurden es nicht. Die Protokolle beweisen weder, dass die nicht angenommenen Vorschläge technisch unmöglich waren, noch dass jeder Betreiber mehr Raum brauchte. Sie weisen auch keinen einheitlichen Grund für die fehlende Zustimmung aus.

APNICs Nominierungsseite für den NRO Number Council beschreibt Fujisaki als leitenden Forschungsingenieur bei NTT, nennt IPv6-Forschung seit 1997 und führt Aufgaben in japanischen Einführungs- und Adresspolitikgruppen auf. Als Nominierungsunterlage belegt sie verzeichnete Laufbahndaten, keine unabhängige Leistungsbewertung. APNIC-Protokolle halten zusätzlich seine einstimmige Ernennung in den NRO Number Council für 2011 fest.

Zwei Ebenen, getrennte Belege

Die Zuteilungsregel beeinflusst, welchen Adressplan ein Betreiber aufbauen kann. Die Auswahlregel beeinflusst, welche konfigurierte Adresse der Host nutzt. Die Quellen zeigen weder, dass ein größerer Block eine falsche Quelladresswahl behebt, noch dass eine DHCPv6-Tabelle einen ungeeigneten Adressplan ausgleicht.

RFC 5220 und RFC 5221 haben je vier Mitautoren, RFC 7078 drei. APNIC führt Fujisaki bei manchen Vorschlägen als Autor, bei anderen als Mitautor. Die genaue Zuordnung verfolgt seine Beteiligung, ohne ihm allein einen Gemeinschaftsstandard, eine institutionelle Entscheidung oder ein Betriebsergebnis zuzuschreiben.

Belegt ist: Ein Problem der Adresswahl wurde beschrieben, in Anforderungen überführt und durch einen standardisierten Mechanismus ergänzt. Bei der Zuteilung wurde eine Änderung umgesetzt, weitere Vorschläge fanden keinen Konsens. Zahlen zur Verbreitung von RFC 7078, zu Leistungsänderungen oder den Folgen von prop-082 fehlen. Dafür wären Messungen in den betroffenen Netzen nötig.