IPv6 allein reicht nicht: die Zeile, die Azure selbst gezogen hat

Zusammenfassung

• Die IPv6-Dokumentation von Azure stellt fest, dass virtuelle Maschinen und Skalierungsgruppen, die ausschließlich IPv6 nutzen, nicht unterstützt werden, und dass jede Netzwerkschnittstelle mindestens eine IPv4-IP-Konfiguration enthalten muss.
• Dieselbe Dokumentation behandelt öffentliche IPv6-Adressen und -Präfixe als kostenlos und öffentliche IPv4-Adressen als kostenpflichtig. Weil die Vorgabe an der Netzwerkschnittstelle greift, bleibt IPv4 in jeder virtuellen Maschine, unabhängig davon, wie viel IPv6 die Anwendung tatsächlich spricht.

Der Satz, der alles entscheidet

Ein Team, das in Azure ausschließlich mit IPv6 arbeiten will, stolpert nicht über Leistung und nicht über den Preis. Es stolpert über eine Zeile Dokumentation. Die Übersichtsseite zu IPv6 in Azure Virtual Network sagt im Abschnitt zu den Einschränkungen, dass virtuelle Maschinen, die nur IPv6 nutzen, und Skalierungsgruppen für virtuelle Maschinen, die nur IPv6 nutzen, nicht unterstützt werden, und dass jede Netzwerkschnittstelle mindestens eine IPv4-IP-Konfiguration enthalten muss (Übersicht zu IPv6 für Azure Virtual Network).

Dieser Satz meldet keine fehlende Funktion. Er meldet eine Reihenfolge. Azure bietet IPv6 an und legt darüber fest, dass IPv6 allein nicht genügt. Wenn ein Cloud-Anbieter in seiner eigenen Produktdokumentation schreibt, eine Konfiguration werde nicht unterstützt, und unmittelbar danach die Bedingung nachliefert, unter der sie doch läuft, dann ist die Bedingung die eigentliche Aussage. Sie sagt, was der Anbieter für zwingend hält.

Was in der Dokumentation tatsächlich steht

Der genaue Umfang des Textes gehört festgehalten. Die IPv6-Übersichtsseite erklärt virtuelle Maschinen und Skalierungsgruppen, die ausschließlich IPv6 nutzen, für nicht unterstützt und verlangt auf jeder Netzwerkschnittstelle mindestens eine IPv4-IP-Konfiguration (Quelle). Die Seite zu öffentlichen IP-Adressen wiederholt die Einschränkung und nennt den Grund: In einer Dual-Stack-Konfiguration braucht jede Netzwerkschnittstelle mindestens eine IPv4-Konfiguration (Öffentliche IP-Adressen in Azure).

Dual-Stack heißt in einfachen Worten: Eine Maschine trägt eine Adresse aus beiden Familien und spricht mit beiden Welten gleichzeitig. Der Regelfall, den Azure annimmt, ist also nicht die Migration zu IPv6, sondern das Nebeneinander von IPv4 und IPv6.

Dieselbe Übersichtsseite ordnet IPv6 als Dual-Stack-Konnektivität ein, die es gehosteten Anwendungen erlaubt, sowohl das bestehende IPv4-Internet als auch neue IPv6-Geräte und -Netze zu erreichen (Quelle). Sie schreibt selbst, dass es nicht um das Ersetzen von IPv4 geht, sondern um den Umgang mit dessen Erschöpfung. Die Dokumentation zu den Übergangstechnologien unter Windows Server folgt derselben Linie: Sie beschreibt Koexistenz- und Übergangsmechanismen zwischen IPv4 und IPv6, nicht die Aufgabe von IPv4 (IPv6-Übergangstechnologien).

Damit ist der Anspruch dieses Artikels begrenzt. Azure ist nicht IPv4-only. Es fehlt nicht an IPv6-Unterstützung. Es fehlt nicht an IPv6-Adressbereichen. Belegbar ist ein einziger Punkt: Die Konfiguration ausschließlich mit IPv6 ist nicht zulässig, und das steht als Konfigurationsanforderung da, nicht als Schlussfolgerung.

Warum die Netzwerkschnittstelle der tragende Punkt ist

Wo die Einschränkung sitzt, verrät den Charakter des Entwurfs. Die IPv4-Pflicht liegt weder in der Anwendungsschicht noch in der Abonnement-Schicht. Sie liegt an der Netzwerkschnittstelle. Und die Netzwerkschnittstelle ist genau die Stelle, an der eine virtuelle Maschine Adressen bei der Plattform anfordert.

An der Schnittstelle angesetzt, wächst die Einschränkung mit der Zahl der Schnittstellen. Sie wächst nicht damit, wie viel IPv6 die Anwendung spricht. Eine vollständig IPv6-fähige Arbeitslast mit zehn Schnittstellen braucht zehn IPv4-Konfigurationen. Hier beißt die Regel. Stünde die Einschränkung oben, in der Form „Abonnements nur mit IPv6 werden nicht angenommen“, könnte der Kunde durch Umbau auf Abonnement-Ebene reagieren. Weil sie an der Schnittstelle steht, reicht der Umbau bis in jede Ecke des Deployments.

Für sich genommen beschleunigt diese Struktur die Migration nicht und bremst sie nicht. Sie erzwingt, dass IPv4 bleibt, und sie verhindert IPv6 nicht. Sie hält beides gleichzeitig aufrecht und ist insofern stimmig. Nicht stimmig ist die Preisseite.

IPv6 kostenlos, IPv4 kostenpflichtig, und ein Preissignal ohne Ziel

Die IPv6-Übersichtsseite von Azure stellt fest, dass für die Nutzung öffentlicher IPv6-Adressen und öffentlicher IPv6-Präfixe keine Gebühr anfällt und dass zugehörige Ressourcen und Bandbreite zu denselben Sätzen wie bei IPv4 abgerechnet werden (Quelle). Die Seite zu öffentlichen IP-Adressen hält ebenfalls fest, dass die öffentliche IPv4-Adresse eine nominelle Gebühr trägt und die öffentliche IPv6-Adresse nicht (Quelle).

Darin liegt ein Preissignal. Eine Adressfamilie ist kostenlos, die andere kostet. Rein wirtschaftlich betrachtet müsste der Kunde zu IPv6 wandern. Doch die Regel an der Schnittstelle macht IPv4 zwingend. Das Signal drückt Richtung IPv6, die Regel hält IPv4 fest. Die beiden heben sich nicht auf, sie sind geordnet. Die Regel steht vorn, der Preis wirkt in ihrem Inneren.

Deshalb trägt die Erklärung „IPv6 ist kostenlos, also kommt die Migration voran“ in dieser Konfiguration nicht. Die kostenlose Familie ersetzt die zwingende nicht. Der Kunde zahlt für die IPv4-Konfiguration, die er nicht entfernen darf. Der Betrag ist hier nicht der Punkt. Wie hoch die nominelle Gebühr ausfällt, ist nicht die These dieses Artikels. Die These ist die Tatsache, dass die wirtschaftliche Kraft hin zur kostenlosen Seite und die technische Regel, die die zwingende Seite fixiert, im selben Dokument nebeneinander stehen.

Der veröffentlichte Datensatz ist nicht das Netz

Wer den Adressraum von Azure untersuchen will, landet bei der Datei mit Azure-IP-Bereichen und Diensttags, die Microsoft zum Herunterladen bereitstellt, mit maschinenlesbaren Daten über den Adressraum, den Azure-Dienste nutzen (Azure-IP-Bereiche und Diensttags).

Existenz und erklärter Zweck der Datei sind belegbar. Das aktuelle Schema (die Regeln, welche Felder die Datei führt), die Abdeckung nach Adressfamilie und der Aktualisierungstakt wurden in dieser Recherche jedoch nicht als Text gelesen. Deshalb wird nicht behauptet, die Datei enthalte keine IPv6-Präfixe oder sei ausschließlich IPv4. Was nicht gelesen wurde, wird nicht zur Schlussfolgerung.

Der strukturelle Punkt ist ein anderer: Drei Register laufen auf drei verschiedenen Uhren. Der Eintrag beim Regional Internet Registry, die vom Anbieter veröffentlichte Bereichsdatei und die Konfigurationsanforderung, die die Plattform tatsächlich durchsetzt. Jedes dient einem anderen Zweck und wird in eigenem Rhythmus aktualisiert. Wenn die drei auseinanderlaufen, richtet sich der erste Verdacht auf Umfang und Takt, nicht auf Wahrhaftigkeit. Die Bereichsdatei sagt, welcher Block zu welchem Dienst gehört; sie sagt nicht, welche Konfiguration erlaubt ist. Das sagt die Dokumentation, und eine Dokumentation ist kein Adressbuch.

Was der Registry-Eintrag sagen kann und was nicht

Das RDAP-Register (die öffentliche Schnittstelle für Registerauskünfte) der ARIN führt einen Organisationseintrag unter dem Handle MSFT. Er ist der registerliche Anlaufpunkt für die Organisation Microsoft Corporation und die ihr zugeordneten Internet-Nummernressourcen (ARIN RDAP: MSFT).

Dieser Artikel zieht aus diesem Eintrag keine IPv4-Gesamtsumme der Microsoft. Er veröffentlicht keine Präfixliste. Er zieht keine Eigentumsfeststellung daraus. Der Rumpf des Eintrags und die vollständige Menge der verknüpften Ressourcen wurden nicht als Text gelesen. Zahlen aus einem ungelesenen Register zu ziehen ist Raten, nicht Berichterstattung.

Belegbar ist der institutionelle Rahmen: Die ARIN unterhält ein öffentliches Verfahren für IPv4-Transfers und eine Registerspur, über die registrierter Adressraum zwischen Organisationen wandert, auch nach der Erschöpfung des zentralen IPv4-Pools (ARIN: IPv4-Transfers). Dass Transfers stattfinden und wer wie viel hält, sind zwei verschiedene Fragen. Die erste ist institutionell, die zweite verlangt das Lesen des Registers.

Der Nortel-Kauf von 2011 und warum er nichts erklärt

Als historischer Kontext dient die Berichterstattung vom April 2011. BBC News und Ars Technica meldeten, Microsoft habe 666.624 IPv4-Adressen von Nortel für rund 7,5 Millionen Dollar erworben, im Rahmen der Verwertung von Vermögenswerten im Nortel-Insolvenzverfahren (BBC News, Ars Technica).

Die direkte Rechnung ergibt rund 11,25 Dollar je Adresse. Das ist Arithmetik auf gemeldeten Zahlen, kein von der ARIN festgesetzter Preis und erst recht kein heutiger Marktpreis. Die Artikeltexte selbst wurden in dieser Recherche nicht als Text gelesen, deshalb wird der Befund als der Presse zugeschriebene Tatsache behandelt.

Und hier liegt der wichtige Punkt. Dieser Vorgang von 2011 erklärt die heutige Konfigurationsregel von Azure nicht. Die Kausalität, wonach ein Anbieter, der früher IPv4 gekauft hat, die heutige Schnittstellenanforderung geschrieben habe, ist nirgends registriert. Dieser Artikel behauptet sie nicht. Die Geschichte zeigt, dass Adressraum ein handelbares Gut mit Geldwert sein kann. Mehr zeigt sie nicht.

Wo die Migration tatsächlich steht

Ist die Migration zu IPv6 nicht vorangekommen? Dieser Artikel hat das nicht gemessen. Es gab keine BGP-Beobachtung (das Verfahren, mit dem Netze Routen austauschen), keine Endpunktmessung, keine Kundenbefragung. Der Abgleich zwischen veröffentlichten Metadaten und dem tatsächlichen Netzzustand wurde hier nicht durchgeführt.

Belegbar ist die Form der Antwort, die die Plattform vorbereitet hat. IPv6 wird angeboten, die öffentliche IPv6-Adresse ist kostenlos, die Konnektivität ist als Dual-Stack eingeordnet. Gleichzeitig ist die Konfiguration ausschließlich mit IPv6 nicht unterstützt, und IPv4 wird auf jeder Schnittstelle verlangt. Diese Kombination stoppt die Migration nicht. Sie verschiebt den Endpunkt: nicht dorthin, wo IPv4 verschwindet, sondern dorthin, wo IPv4 immer mitläuft.

Für den Kunden ist die praktische Folge eindeutig. IPv6 einzuführen heißt nicht, die IPv4-Konfiguration zu entfernen. Es heißt, IPv6 zu ergänzen und die IPv4-Konfiguration zu behalten. Wer Adresspläne entwirft, plant von Anfang an mit beiden Familien gleichzeitig.

Was diese Lesart ändern würde

Diese Lesart ändert sich durch konkrete Beobachtungen. Erstens, wenn Microsoft ein Dokument veröffentlicht, das Grund, Einführungszeitpunkt und vorgesehene Endbedingung der Schnittstellenanforderung erklärt. Zweitens, wenn die Konfiguration ausschließlich mit IPv6 unterstützt wird. Drittens, wenn sich die Preisstruktur öffentlicher IP-Adressen ändert und der Preisunterschied zwischen IPv4 und IPv6 verschwindet. Viertens, wenn Schema und Abdeckung der veröffentlichten IP-Bereichsdatei lesbar werden und der Umgang mit den Adressfamilien klar wird.

Nichts davon ist eingetreten. Was vorliegt, ist die Konfigurationsanforderung in der öffentlichen Dokumentation und die Preisstruktur in der öffentlichen Dokumentation, nebeneinander. Azure verweigert IPv6 nicht. Azure verweigert, dass IPv6 genügt. Und diese Entscheidung wurde veröffentlicht, ohne die Gründe zu veröffentlichen.

Der Registereintrag der Microsoft Corporation ist im Verzeichnis von BTW einsehbar (entity:microsoft-corporation-us).