Résumé

  • La documentation Azure consacrée à IPv6 indique, dans sa section sur les limitations, que les machines virtuelles et les groupes de machines virtuelles en IPv6 seul ne sont pas pris en charge et que chaque interface réseau doit comporter au moins une configuration IP IPv4.
  • La même documentation précise que les adresses et préfixes IPv6 publics ne sont pas facturés, tandis que les adresses IPv4 publiques le sont.
  • L'exigence porte sur l'interface réseau, non sur la charge de travail : elle suit chaque machine virtuelle et chaque groupe de machines du parcours documenté, et grandit avec le nombre d'interfaces, indépendamment de la quantité d'IPv6 que l'application parle réellement.
  • Aucune déclaration de Microsoft expliquant la raison d'être, le calendrier ou l'objectif final de cette règle n'a été trouvée. Cet article refuse d'en inventer une.

La phrase qui décide de tout

Dans la section consacrée aux limitations de la présentation d'IPv6 pour Azure Virtual Network, une seule phrase pèse plus lourd que tout le reste de la page : « IPv6-only Virtual Machines or Virtual Machines Scale Sets aren't supported. Each NIC must include at least one IPv4 IP configuration » — autrement dit, les machines virtuelles et les groupes de machines virtuelles en IPv6 seul ne sont pas pris en charge, et chaque interface réseau doit inclure au moins une configuration IP IPv4 (Présentation d'IPv6 pour Azure Virtual Network).

L'argument tient dans cette ligne. Pas un avis de dépréciation, pas un retard de feuille de route, pas une note politique sortie on ne sait d'où. Une limitation, rangée là où vont les limitations, sur la page même qui explique comment ajouter IPv6 à un réseau virtuel.

La même page indique que l'usage des adresses et préfixes IPv6 publics est gratuit, et que les ressources associées ainsi que la bande passante sont facturées aux mêmes tarifs qu'IPv4. La page consacrée aux adresses IP publiques reprend les deux moitiés du dispositif : les adresses IPv4 publiques ont un coût nominal, les adresses IPv6 publiques sont gratuites, et les machines virtuelles comme les groupes de machines en IPv6 seul ne sont pas pris en charge, chaque interface réseau devant inclure au moins une configuration IP IPv4 dans un montage double pile (Adresses IP publiques Azure).

Placez les deux énoncés côte à côte et la hiérarchie devient lisible. La famille d'adresses que Microsoft offre est celle dont il ne laisse pas le client se contenter. La famille qu'il facture est celle dont il ne le laisse pas se passer. Personne n'a rien caché. C'est simplement classé comme une limite, non comme une décision.

Ce que la documentation dit réellement

Le périmètre compte, car la version honnête de cette histoire est plus étroite que la version incendiaire.

Azure ne refuse pas IPv6. La plateforme propose des réseaux virtuels en double pile et les présente comme un moyen, pour les applications hébergées sur Azure, d'atteindre à la fois l'internet IPv4 existant et les nouveaux appareils et réseaux IPv6 — une manière de composer avec l'épuisement d'IPv4 plutôt que de remplacer IPv4. Les recommandations de Microsoft pour Windows Server sur la transition adoptent la même posture : des mécanismes de coexistence et de transition entre les deux familles, non l'abandon de l'une d'elles (Technologies de transition IPv6).

L'interdiction concerne spécifiquement le parcours documenté des machines virtuelles et des groupes de machines virtuelles. Ce n'est pas un énoncé sur l'ensemble des services Azure, ni sur le réseau de Microsoft dans son entier. Quiconque y lit la preuve qu'Azure serait une plateforme exclusivement IPv4 va trop loin. Tout comme celui qui y verrait la preuve que Microsoft ne dispose d'aucune plage d'adresses IPv6.

L'affirmation défendable est plus étroite et plus utile : dans le parcours de calcul documenté, IPv6 est proposé comme un ajout. Il n'est jamais proposé comme un substitut. Azure prend en charge IPv6 ; il ne prend pas en charge IPv6 à la place d'IPv4.

Pourquoi l'interface réseau est le détail porteur

La règle est écrite au niveau de l'interface réseau. Pas de l'abonnement. Pas de la charge de travail. Pas de l'application. C'est ce choix de niveau qui donne à la contrainte sa portée.

Une contrainte formulée au niveau applicatif parlerait de ce que le logiciel sait faire. Une contrainte formulée au niveau de l'interface parle de ce avec quoi un déploiement doit être construit. Chaque machine virtuelle possède au moins une interface réseau ; chaque machine virtuelle hérite donc de l'exigence, quel que soit l'empilement logiciel au-dessus. Un déploiement qui provisionne cent interfaces porte l'exigence cent fois, sans qu'une seule ligne de code applicatif change.

L'interface est aussi exactement l'endroit où le client demande des adresses à la plateforme. C'est le point du parcours de requête où une famille d'adresses cesse d'être une question de goût pour devenir une question de ce que la plateforme allouera. Placez l'exigence à cet endroit, et elle accompagne le déploiement aussi longtemps qu'il existe : à chaque redimensionnement, à chaque redéploiement, et encore au suivant.

Un effet de second ordre mérite d'être énoncé précisément, car les versions approximatives circulent largement. La documentation n'établit pas si la configuration IPv4 exigée doit être publique, privée, partagée ou traduite, et cet article ne l'affirme pas. La règle ne dit donc rien du nombre d'adresses IPv4 publiques, devenues rares, que consomme une charge de travail donnée. Ce qu'elle dit, c'est que le déploiement ne peut pas être décrit honnêtement comme IPv6 seul, et que le parcours de provisionnement d'Azure ne laissera de toute façon pas un opérateur en construire un.

C'est un rapport de force exprimé comme un détail de schéma, et c'est bien plus lourd de conséquences qu'une page de tarifs.

IPv6 gratuit, IPv4 facturé, et un signal-prix qui ne mène nulle part

Azure tarifie les deux familles en sens opposé. Adresses et préfixes IPv6 publics : gratuits. Adresses IPv4 publiques : un coût nominal (Adresses IP publiques Azure).

Pris isolément, c'est un signal-prix orienté vers IPv6. Les signaux-prix sont censés modifier les comportements ; c'est toute la théorie derrière eux. Celui-ci entre en collision avec une règle de configuration qui rend l'autre famille obligatoire, et la collision produit quelque chose de plus étrange qu'une contradiction. Le signal commercial et l'exigence technique ne s'annulent pas. Ils ne se renforcent pas non plus. Ils suivent des voies parallèles et ne se rencontrent jamais.

Un client qui cherche à réduire ses coûts s'entend dire, à juste titre, qu'IPv6 est gratuit. Un client qui tente d'agir en conséquence découvre que la famille gratuite ne peut pas être la seule présente sur l'interface. L'économie est réelle mais bornée : elle porte sur la partie IPv6 de la configuration, et la partie IPv4 reste exactement là où elle était.

Ce n'est ni de l'hypocrisie, ni la preuve d'un dessein caché. C'est un ordre de priorité. Le signal-prix est une préférence commerciale. La règle d'interface est une exigence technique appliquée au moment du provisionnement. Quand les deux divergent, l'exigence l'emporte, parce que c'est elle que le portail vérifie. Une famille d'adresses gratuite à côté d'une famille obligatoire ne constitue pas une contradiction dans la comptabilité de Microsoft ; c'est la description de la décision que la plateforme applique réellement.

Le registre publié n'est pas le réseau

Microsoft publie un fichier téléchargeable des plages IP et des balises de service Azure, destiné aux clients qui ont besoin de données lisibles par machine sur l'espace d'adressage utilisé par les services Azure (Plages IP Azure et balises de service).

L'existence et l'objet déclaré de ce fichier sont établis. Sa version de schéma actuelle, sa couverture des familles de préfixes et sa cadence de publication n'ont pas été lues comme texte dans cette recherche ; cet article n'affirme donc pas que le fichier omettrait les préfixes IPv6, ni à quelle vitesse il est actualisé.

Cette prudence est le sujet, pas une esquive. Le geste tentant — et il est partout dans les commentaires sur les réseaux cloud — consiste à traiter un fichier de plages lisible par machine comme un miroir tendu devant le réseau. Ce n'en est pas un. C'est un artefact de publication, avec un périmètre que quelqu'un a choisi et une cadence que quelqu'un tient. Il en va de même des balises de service, qui sont une couche de nommage appliquée à des ensembles d'adresses, non une table de routage en direct.

D'où la règle générale qui gouverne tout ce dossier. Les enregistrements de registre, les fichiers de plages publiés et les exigences de plateforme appliquées sont trois artefacts différents, produits par trois processus différents, sur trois horloges différentes. Quand ils divergent, la première question n'est pas de savoir lequel ment. C'est de savoir lequel couvre quoi, et quand chacun a été écrit pour la dernière fois.

Ce que l'enregistrement de registre dit et ne dit pas

L'enregistrement d'organisation RDAP d'ARIN sous le handle MSFT est le point d'entrée de registre pour l'immatriculation de Microsoft Corporation et pour les ressources de numérotation internet qui lui sont rattachées (Entité RDAP ARIN MSFT).

Cela établit une identité. Cela n'établit pas un total. Le corps de l'enregistrement et l'ensemble complet de ses ressources liées n'ont pas été lus comme texte au cours de cette recherche ; aucun chiffre de détention, aucune liste de préfixes, aucun inventaire n'en est donc tiré ici. Et les lecteurs devraient traiter tout total spectaculaire d'adresses IPv4 attribué à Microsoft, présenté sans l'enregistrement sous-jacent, comme une affirmation en quête de preuve plutôt que comme un fait établi.

Ce que le registre établit clairement, en revanche, c'est la mécanique. ARIN maintient un cadre public de transfert d'IPv4 et une traçabilité de registre par lesquels de l'espace d'adressage enregistré passe d'une organisation à une autre, y compris pour des transferts consignés après l'épuisement du pool central d'IPv4 (Politique de transfert IPv4 d'ARIN). L'espace d'adressage est transférable, enregistrable et traçable. C'est la structure du marché. Ce que détient une entreprise donnée à l'intérieur de cette structure est une question distincte, qui exige une lecture distincte.

L'achat de Nortel en 2011, et pourquoi ce n'est pas l'explication

En avril 2011, des articles publiés par BBC News et Ars Technica rapportaient que Microsoft avait acquis 666 624 adresses IPv4 auprès de Nortel, dans une transaction valorisée à environ 7,5 millions de dollars, dans le cadre de la cession d'actifs liée à la faillite de Nortel (BBC News ; Ars Technica).

L'arithmétique qui suit — environ 11,25 dollars par adresse — est un calcul effectué sur des chiffres rapportés. Ce n'est pas un prix fixé par ARIN, et cela ne devrait jamais être cité comme tel. Ces articles sont par ailleurs des articles : aucun de leurs corps n'a été lu comme texte dans cette recherche, et le nombre d'adresses comme le prix proviennent du récit rapporté et du titre d'Ars Technica, non d'un enregistrement de registre ou d'une pièce judiciaire.

C'est ici que la transaction a sa place : comme contexte historique de la valeur de marché de l'espace d'adressage en 2011, à une époque où une entreprise préparant sa croissance dans le cloud acceptait de payer pour un bloc important. Ce n'est pas une preuve concernant la règle d'interface actuelle d'Azure, et ce n'est surtout pas un mobile. Une acquisition de 2011 présentée comme la raison d'une exigence de configuration des années 2020, c'est une histoire à la forme satisfaisante et au contenu vide. L'achat explique ce que valait l'espace d'adressage.

Il n'explique pas ce que le portail de provisionnement d'Azure applique aujourd'hui.

Où en est réellement la migration

Dit aussi simplement que la documentation le permet : Azure prend en charge IPv6, prend en charge la double pile, ne prend pas en charge les machines virtuelles ni les groupes de machines en IPv6 seul, et exige au moins une configuration IPv4 sur chaque interface réseau de ce parcours. Les adresses et préfixes IPv6 publics sont gratuits. Les adresses IPv4 publiques sont facturées. Les recommandations de transition de Microsoft décrivent une coexistence, non un remplacement.

Ce que cette liste a de plus utile, c'est qu'elle est incomplète, et que Microsoft a publié cette incomplétude. La section des limitations est l'endroit où une plateforme range ce qu'elle ne sait pas encore faire ; que celle-ci tienne en une phrase aussi sèche suggère une organisation d'ingénierie qui sait exactement où se situe sa frontière et n'a aucun intérêt à l'habiller.

Incomplet ne veut pas dire temporaire, et la différence compte pour quiconque établit un plan à cinq ans. Aucune date, aucun jalon, aucun état final n'ont été trouvés qui permettraient à une personne raisonnable de dire quand l'exigence d'IPv4 sur chaque interface pourrait être levée. La qualifier de transitoire serait une invention, et une invention coûteuse pour qui dimensionne un réseau en conséquence.

Ce que le dossier ne contient pas non plus, c'est une raison. Aucune déclaration de Microsoft expliquant la logique, le calendrier ou l'état final visé par la règle n'est apparue au cours de cette recherche. Le mobile est inconnu. La règle arrange une entreprise qui détient beaucoup d'IPv4, et la commodité n'est pas la preuve que la commodité soit la raison de son existence.

Une garantie de compatibilité pour des services qui supposent encore IPv4, un coût de support qui n'a pas encore été retiré, un choix délibéré sur la séquence des migrations — tout cela s'accorde aussi bien avec la phrase publiée, et rien de tout cela ne peut en être confirmé.

Quiconque veut le contexte de fond sur la position de Microsoft en matière de ressources réseau, plutôt que la controverse à son sujet, peut commencer par la fiche du répertoire BTW consacrée à Microsoft Corporation.

Ce qui changerait cette lecture

Trois choses.

Une déclaration de Microsoft sur la logique retenue. Si l'exigence d'interface existe pour garantir la compatibilité de services qui supposent encore IPv4, c'est un autre article, et un article plus indulgent. Si elle traduit un jugement commercial sur la valeur de l'espace d'adressage, c'est aussi un autre article. L'un comme l'autre mériterait d'être publié dès qu'il existera.

Un calendrier daté. Si les machines virtuelles et les groupes de machines en IPv6 seul apparaissaient sur une feuille de route publiée avec un jalon associé, la contrainte cesserait d'être une frontière pour devenir un échéancier. Rien dans la documentation actuelle ne le fournit.

Une mesure. Si quelqu'un démontrait que les données de plages publiées par Azure et l'état observé du réseau divergent au-delà de ce que les fenêtres de publication annoncées peuvent expliquer, ce serait une question de test avec une réponse de test. Aucune mesure BGP, aucun relevé de point de terminaison, aucune mesure client n'ont été effectués pour cet article ; aucune conclusion de ce type n'est donc revendiquée ici.

Jusqu'à ce que l'un de ces trois éléments arrive, la lecture honnête est celle que la documentation elle-même soutient. La hiérarchie est publique : IPv6 gratuit, IPv4 facturé, et une configuration IPv4 obligatoire sur chaque interface du parcours de calcul documenté. Le raisonnement qui la sous-tend ne l'est pas, et c'est dans cet écart que vit aujourd'hui la migration IPv6 de toute une industrie — annoncée en haut de la page, contrainte en note de bas de page, et tarifée sur une page entièrement différente.