Resumen

  • La documentación de Azure sobre IPv6 indica, en su sección de limitaciones, que las máquinas virtuales y los conjuntos de escalado solo IPv6 no son compatibles y que cada interfaz de red debe incluir al menos una configuración IP IPv4.
  • Esa misma documentación señala que las direcciones y los prefijos IPv6 públicos no tienen coste, mientras que las direcciones IPv4 públicas sí lo tienen.
  • La exigencia recae sobre la interfaz de red, no sobre la carga de trabajo, así que acompaña a cada máquina virtual y a cada conjunto de escalado del recorrido documentado y crece con el número de interfaces, no con la cantidad de IPv6 que hable la aplicación.
  • No se localizó ninguna declaración de Microsoft que explique la razón, el calendario o el objetivo final de la regla. Este artículo se niega a inventarla.

La frase que lo decide todo

En la sección de limitaciones de la guía de IPv6 para Azure Virtual Network hay una sola frase que pesa más que todo el resto de la página: «IPv6-only Virtual Machines or Virtual Machines Scale Sets aren't supported. Each NIC must include at least one IPv4 IP configuration» —es decir, las máquinas virtuales y los conjuntos de escalado solo IPv6 no son compatibles, y cada interfaz de red debe incluir al menos una configuración IP IPv4 (Guía de IPv6 para Azure Virtual Network).

El argumento cabe en esa línea. No es un aviso de retirada, ni un retraso de hoja de ruta, ni una nota interna que se filtró. Es una limitación, archivada donde van las limitaciones, en la misma página que explica cómo añadir IPv6 a una red virtual.

Esa página dice también que no hay coste por usar direcciones ni prefijos IPv6 públicos, y que los recursos asociados y el ancho de banda se facturan a las mismas tarifas que IPv4. La página de direcciones IP públicas repite las dos mitades del arreglo: las direcciones IPv4 públicas tienen un coste nominal, las IPv6 públicas no tienen coste, y las máquinas virtuales y los conjuntos de escalado solo IPv6 no son compatibles porque cada interfaz de red debe incluir al menos una configuración IP IPv4 en una configuración de doble pila (Direcciones IP públicas de Azure).

Ponga las dos afirmaciones una al lado de la otra y la jerarquía se vuelve legible. La familia de direcciones que Microsoft regala es la que no permite usar en solitario. La familia que cobra es la que no permite abandonar. Nadie ocultó nada. Simplemente está archivado como un límite y no como una decisión.

Lo que dice realmente la documentación

El alcance importa, porque la versión honesta de esta historia es más estrecha que la versión incendiaria.

Azure no rechaza IPv6. Ofrece redes virtuales de doble pila y las presenta como una forma de que las aplicaciones alojadas en Azure alcancen tanto la internet IPv4 existente como los nuevos dispositivos y redes IPv6: una manera de convivir con el agotamiento de IPv4, no de sustituirlo. Las directrices de Microsoft para Windows Server sobre la transición mantienen la misma postura: mecanismos de coexistencia y transición entre las dos familias, no el abandono de ninguna de ellas (Tecnologías de transición IPv6).

La prohibición se refiere específicamente al recorrido documentado de máquinas virtuales y conjuntos de escalado. No es una afirmación sobre todos los servicios de Azure, ni sobre la red de Microsoft en su conjunto. Quien lea ahí la prueba de que Azure es una plataforma exclusivamente IPv4 se ha pasado de largo. También quien vea en ello la prueba de que Microsoft no tiene rangos de direcciones IPv6.

La afirmación defendible es más estrecha y más útil: en el recorrido de cómputo documentado, IPv6 se ofrece como un añadido. Nunca se ofrece como sustituto. Azure admite IPv6; no admite IPv6 en lugar de IPv4.

Por qué la interfaz de red es el detalle que sostiene todo

La regla está escrita en el nivel de la interfaz de red. No en el de la suscripción. No en el de la carga de trabajo. No en el de la aplicación. Esa elección de nivel es lo que da alcance a la restricción.

Una restricción redactada en la capa de aplicación hablaría de lo que el software sabe hacer. Una restricción redactada en la interfaz habla de aquello con lo que hay que construir el despliegue. Toda máquina virtual tiene al menos una interfaz de red, así que toda máquina virtual hereda la exigencia, sea cual sea la pila de software que tenga encima. Un despliegue que aprovisiona cien interfaces arrastra la exigencia cien veces, sin que cambie una sola línea de código de aplicación.

La interfaz es además exactamente el punto en el que el cliente pide direcciones a la plataforma. Ese es el lugar del recorrido de la petición donde una familia de direcciones deja de ser cuestión de gusto y pasa a ser cuestión de qué asignará la plataforma. Coloque allí la exigencia y acompañará al despliegue mientras este exista: en cada redimensionamiento, en cada redespliegue y otra vez en el siguiente.

Hay un efecto de segundo orden que conviene enunciar con precisión, porque las versiones vagas circulan mucho. La documentación no establece si la configuración IPv4 exigida debe ser pública, privada, compartida o traducida, y este artículo no lo afirma. La regla, por tanto, no dice nada sobre cuántas direcciones IPv4 públicas —ya escasas— consume una carga de trabajo concreta. Lo que dice es que el despliegue no puede describirse honestamente como solo IPv6, y que el recorrido de aprovisionamiento de Azure no dejará de todos modos que un operador construya uno.

Es una relación de poder expresada como detalle de esquema, y tiene bastantes más consecuencias que una página de precios.

IPv6 gratis, IPv4 de pago, y una señal de precio que no va a ninguna parte

Azure pone precio a las dos familias en direcciones opuestas. Direcciones y prefijos IPv6 públicos: sin coste. Direcciones IPv4 públicas: un coste nominal (Direcciones IP públicas de Azure).

Leída sola, esa es una señal de precio orientada a IPv6. Se supone que las señales de precio mueven conductas; en eso consiste la teoría. Esta choca con una regla de configuración que hace obligatoria la otra familia, y el choque produce algo más raro que una contradicción. La señal comercial y la exigencia técnica no se anulan. Tampoco se refuerzan. Van por vías paralelas y no se cruzan nunca.

A un cliente que busca recortar costes se le dice, con razón, que IPv6 es gratis. Un cliente que intenta actuar en consecuencia descubre que la familia gratuita no puede ser la única presente en la interfaz. El ahorro es real pero acotado: afecta al lado IPv6 de la configuración, y el lado IPv4 sigue exactamente donde estaba.

No es hipocresía, ni la prueba de una agenda oculta. Es un orden de prelación. La señal de precio es una preferencia comercial. La regla de interfaz es un requisito técnico que se aplica en el momento del aprovisionamiento. Cuando discrepan, gana el requisito, porque el requisito es lo que comprueba la puerta de entrada. Una familia de direcciones gratuita junto a otra obligatoria no es una contradicción en la contabilidad de Microsoft; es la descripción de qué decisión aplica realmente la plataforma.

El registro publicado no es la red

Microsoft publica un archivo descargable de rangos IP y etiquetas de servicio de Azure, destinado a los clientes que necesitan datos legibles por máquina sobre el espacio de direcciones que usan los servicios de Azure (Rangos IP y etiquetas de servicio de Azure).

La existencia y el propósito declarado de ese archivo son hechos establecidos. Su versión de esquema actual, su cobertura de familias de prefijos y su cadencia de publicación no se leyeron como texto en esta investigación, así que este artículo no afirma que el archivo omita prefijos IPv6, ni con qué frecuencia se actualiza.

Esa cautela es el asunto, no una evasiva. El gesto tentador —y está por todas partes en los comentarios sobre redes en la nube— consiste en tratar un archivo de rangos legible por máquina como un espejo puesto delante de la red. No lo es. Es un artefacto de publicación, con un alcance que alguien eligió y un calendario que alguien cumple. Lo mismo vale para las etiquetas de servicio, que son una capa de nombres aplicada a conjuntos de direcciones, no una tabla de rutas en vivo.

De ahí la regla general que gobierna todo este asunto. Los registros del registro regional, los archivos de rangos publicados y los requisitos de plataforma efectivamente aplicados son tres artefactos distintos, producidos por tres procesos distintos, en tres relojes distintos. Cuando discrepan, la primera pregunta no es cuál miente. Es cuál cubre qué y cuándo se escribió cada uno por última vez.

Qué puede y qué no puede decirte el registro

El registro de organización RDAP de ARIN bajo el identificador MSFT es el punto de entrada registral de la inscripción de Microsoft Corporation y de los recursos de numeración de internet que tiene vinculados (Entidad RDAP de ARIN MSFT).

Eso establece una identidad. No establece un total. El cuerpo del registro y el conjunto completo de recursos vinculados no se leyeron como texto durante esta investigación, así que aquí no se deriva ninguna cifra de tenencia, ni lista de prefijos, ni inventario. Y los lectores deberían tratar cualquier total espectacular de direcciones IPv4 atribuido a Microsoft, presentado sin el registro subyacente, como una afirmación en busca de prueba y no como un hecho en mano.

Lo que el registro sí establece con claridad es la maquinaria. ARIN mantiene un marco público de transferencia de IPv4 y una trazabilidad registral por la que el espacio de direcciones registrado pasa de una organización a otra, incluidas las transferencias anotadas después de que se agotara el pool central de IPv4 (Política de transferencias IPv4 de ARIN). El espacio de direcciones es transferible, registrable y rastreable. Esa es la estructura del mercado. Cuánto tiene una empresa concreta dentro de esa estructura es una pregunta distinta, que exige una lectura distinta.

La compra de Nortel en 2011, y por qué no es la explicación

En abril de 2011, reportajes publicados por BBC News y Ars Technica informaron de que Microsoft había adquirido 666.624 direcciones IPv4 a Nortel en una operación valorada en unos 7,5 millones de dólares, dentro de la enajenación de activos vinculada a la quiebra de Nortel (BBC News; Ars Technica).

La aritmética que se sigue —unos 11,25 dólares por dirección— es un cálculo sobre cifras reportadas. No es un precio fijado por ARIN y nunca debería citarse como tal. Esos textos son, además, reportajes: ninguno de sus cuerpos se leyó como texto en esta investigación, y tanto el número de direcciones como el precio provienen del relato publicado y del titular de Ars Technica, no de un registro o de un documento judicial.

Ahí es donde encaja la operación: como contexto histórico del valor de mercado del espacio de direcciones en 2011, cuando una empresa que preparaba su crecimiento en la nube aceptó pagar por un bloque grande. No es prueba sobre la regla actual de interfaces de Azure y, desde luego, no es un motivo. Presentar una compra de 2011 como razón de un requisito de configuración de los años veinte es una historia con una forma muy satisfactoria y nada dentro. La compra explica cuánto valía el espacio de direcciones. No explica qué aplica hoy la puerta de aprovisionamiento de Azure.

Dónde está realmente la migración

Dicho con la claridad que permite la documentación: Azure admite IPv6, admite doble pila, no admite máquinas virtuales ni conjuntos de escalado solo IPv6, y exige al menos una configuración IPv4 en cada interfaz de red de ese recorrido. Las direcciones y los prefijos IPv6 públicos son gratuitos. Las direcciones IPv4 públicas se cobran. Las directrices de transición de Microsoft describen coexistencia, no reemplazo.

Lo más útil de esa lista es que está incompleta, y que Microsoft publicó la incompletitud. La sección de limitaciones es donde una plataforma pone lo que aún no sabe hacer; que esta quepa en una frase tan seca sugiere una organización de ingeniería que sabe exactamente dónde está su frontera y no tiene interés en adornarla.

Incompleto no significa temporal, y la diferencia importa para quien planifica a cinco años. No se localizó ninguna fecha, ningún hito ni ningún estado final que permitiera a una persona razonable decir cuándo podría levantarse la exigencia de IPv4 en cada interfaz. Llamarla transitoria sería una invención, y una invención cara para quien dimensione una red contando con ello.

Lo que el expediente tampoco contiene es una razón. En esta investigación no apareció ninguna declaración de Microsoft que explicara la lógica, el calendario o el estado final pretendido de la regla. El motivo es desconocido. La regla resulta conveniente para una empresa que tiene muchísimo IPv4, y la conveniencia no es prueba de que la conveniencia sea la razón de que exista.

Una garantía de compatibilidad para servicios que aún suponen IPv4, un coste de soporte que todavía no se ha retirado, una decisión deliberada sobre cómo deben secuenciarse las migraciones: todo eso encaja igual de bien con la frase publicada, y nada de ello puede confirmarse a partir de ella.

Quien quiera el contexto de fondo sobre la posición de Microsoft en recursos de red, más que la polémica al respecto, puede empezar por la ficha de Microsoft Corporation en el directorio de BTW.

Qué cambiaría esta lectura

Tres cosas.

Una declaración de Microsoft sobre la lógica. Si la exigencia de interfaz existe para garantizar compatibilidad con servicios que aún suponen IPv4, es otro artículo, y uno más comprensivo. Si refleja un juicio comercial sobre el valor del espacio de direcciones, también es otro artículo. Cualquiera de los dos merecería publicarse en cuanto exista.

Un calendario con fechas. Si las máquinas virtuales y los conjuntos de escalado solo IPv6 aparecieran en una hoja de ruta publicada con un hito asociado, la restricción dejaría de ser una frontera y pasaría a ser un horario. Nada en la documentación actual lo aporta.

Una medición. Si alguien demostrara que los datos de rangos publicados por Azure y el estado observado de la red divergen más de lo que pueden explicar las ventanas de publicación anunciadas, sería una pregunta de prueba con respuesta de prueba. Para este artículo no se realizó ninguna medición BGP, ningún sondeo de extremos ni ninguna medición de cliente, así que aquí no se reclama ningún hallazgo de ese tipo.

Hasta que llegue uno de esos tres elementos, la lectura honesta es la que sostiene la propia documentación. La jerarquía es pública: IPv6 gratis, IPv4 de pago y una configuración IPv4 obligatoria en cada interfaz del recorrido de cómputo documentado. El razonamiento que la sostiene no lo es, y en esa brecha vive hoy la migración a IPv6 de toda una industria: anunciada en la parte alta de la página, restringida en la letra pequeña y tarifada en una página completamente distinta.