Resumo

  • A documentação de IPv6 da Azure afirma que máquinas virtuais somente IPv6 e conjuntos de dimensionamento somente IPv6 não são suportados, e que cada interface de rede precisa incluir ao menos uma configuração de IP IPv4.
  • A mesma documentação trata endereços e prefixos IPv6 públicos como gratuitos e os endereços IPv4 públicos como item tarifado. Como a exigência incide na interface de rede, o IPv4 permanece em toda máquina virtual, independentemente de quanto IPv6 a aplicação fala.

A frase que decide tudo

Uma equipe que quer operar só com IPv6 na Azure não tropeça em desempenho nem em preço. Tropeça numa linha de documentação. A página de visão geral de IPv6 da Azure Virtual Network diz, na seção de limitações, que máquinas virtuais somente IPv6 e conjuntos de dimensionamento de máquinas virtuais somente IPv6 não são suportados, e que cada interface de rede deve incluir pelo menos uma configuração de IP IPv4 (Visão geral do IPv6 para Azure Virtual Network).

Essa frase não anuncia uma ausência de recurso. Anuncia uma ordem. A Azure oferece IPv6 e, sobre essa oferta, fixa por desenho o estado em que IPv6 sozinho não basta. Quando um provedor de nuvem escreve na própria documentação de produto que determinada configuração não é suportada e, logo em seguida, acrescenta a condição que a tornaria viável, o que se deve ler é a condição. A condição é a declaração do que o provedor considera obrigatório.

O que a documentação realmente diz

Vale fixar o alcance exato do texto. A página de visão geral de IPv6 afirma que máquinas virtuais somente IPv6 e conjuntos de dimensionamento somente IPv6 não são suportados e que cada interface de rede precisa de pelo menos uma configuração de IP IPv4 (fonte). A página de endereços IP públicos repete a restrição e explica a razão: em uma configuração de pilha dupla, cada interface de rede precisa de pelo menos uma configuração IPv4 (Endereços IP públicos da Azure).

Vale traduzir "pilha dupla" para palavras comuns. Significa que uma mesma máquina carrega um endereço de cada família e conversa com os dois mundos ao mesmo tempo. Ou seja, o padrão que a Azure assume não é a migração para IPv6, mas a convivência entre IPv4 e IPv6.

A mesma página de visão geral posiciona o IPv6 como conectividade de pilha dupla que permite às aplicações hospedadas alcançar tanto a internet IPv4 existente quanto os novos dispositivos e redes IPv6 (fonte). Ela própria escreve que o assunto não é substituir o IPv4, e sim conviver com o esgotamento dele. A documentação de tecnologias de transição do Windows Server segue a mesma lógica: descreve mecanismos de coexistência e transição entre IPv4 e IPv6, não o abandono do IPv4 (Tecnologias de transição IPv6).

Por isso o que este artigo pode afirmar tem limite claro. A Azure não é IPv4-only. Não lhe falta suporte a IPv6. Não lhe faltam faixas de endereços IPv6. O que se pode afirmar é um único ponto: a configuração somente IPv6 não é permitida, e isso está escrito como requisito de configuração, não como dedução.

Por que a interface de rede é o ponto que sustenta tudo

Onde a restrição foi colocada revela o caráter do desenho. A obrigatoriedade do IPv4 não está na camada de aplicação nem na camada de assinatura. Está na interface de rede. E a interface de rede é exatamente o ponto em que a máquina virtual pede endereços à plataforma.

Colocada na interface, a restrição cresce com o número de interfaces. Não cresce com o quanto a aplicação fala IPv6. Uma carga de trabalho plenamente compatível com IPv6, com dez interfaces, precisa de dez configurações IPv4. É aí que a regra morde. Se a restrição estivesse no alto, na forma de "assinaturas somente IPv6 não são aceitas", o cliente resolveria redesenhando no nível da assinatura. Como está na interface, o redesenho alcança cada canto do deployment.

Essa estrutura, sozinha, não acelera nem freia a migração. Ela obriga o IPv4 a permanecer e não impede o uso de IPv6. É um desenho que sustenta as duas coisas ao mesmo tempo e, nesse sentido, é coerente. O que não é coerente é o lado do preço.

IPv6 grátis, IPv4 cobrado, e um sinal de preço sem destino

A página de visão geral de IPv6 da Azure afirma que não há cobrança pelo uso de endereços IPv6 públicos nem de prefixos IPv6 públicos, e que os recursos associados e a largura de banda são cobrados nas mesmas tarifas do IPv4 (fonte). A página de endereços IP públicos também registra que o endereço IPv4 público tem uma cobrança nominal e o IPv6 público não (fonte).

Aí está um sinal de preço. Uma família de endereços é gratuita, a outra é tarifada. Olhando só a racionalidade econômica, o cliente deveria migrar para IPv6. Só que a regra da interface torna o IPv4 obrigatório. O sinal empurra para o IPv6; a regra segura o IPv4. Os dois não se anulam: estão ordenados. A regra vem primeiro, e o preço opera dentro dela.

Por isso a explicação de que "IPv6 é grátis, então a migração avança" não se sustenta nessa configuração. A família gratuita não substitui a família obrigatória. O cliente paga pela configuração IPv4 que não pode remover. O valor em si não é o ponto aqui. Quanto custa a cobrança nominal não é a tese deste artigo. A tese é o fato de que a força econômica que puxa para o lado gratuito e a regra técnica que fixa o lado obrigatório estão publicadas no mesmo documento.

O registro publicado não é a rede

Quem investiga o espaço de endereços da Azure chega ao arquivo de faixas de IP e tags de serviço que a Microsoft publica para download, com dados legíveis por máquina sobre o espaço que os serviços da Azure usam (Faixas de IP e tags de serviço da Azure).

A existência e a finalidade declarada do arquivo são verificáveis. Mas o esquema atual (as regras que definem quais campos o arquivo traz), a cobertura por família de endereços e a cadência de atualização não foram lidos como texto nesta apuração. Portanto não se afirma que o arquivo não inclui prefixos IPv6, nem que seja exclusivamente IPv4. O que não foi lido não vira conclusão.

O ponto estrutural é outro: três registros correm em três relógios diferentes. O registro do RIR, o arquivo de faixas publicado pelo provedor e o requisito de configuração que a plataforma efetivamente impõe. Cada um serve a um propósito e é atualizado em ritmo próprio. Quando os três divergem, a primeira suspeita deve recair sobre escopo e cadência, não sobre veracidade. O arquivo de faixas diz qual bloco pertence a qual serviço; não diz qual configuração é permitida. Quem diz isso é a documentação, e documentação não é livro-razão de endereços.

O que o registro do RIR pode e não pode dizer

O registro RDAP (a interface pública de consulta a dados de registro) da ARIN tem uma entrada de organização sob o handle MSFT. É o ponto de registro da Microsoft Corporation e dos recursos de numeração de internet a ela vinculados (ARIN RDAP: MSFT).

Este artigo não extrai desse registro um total de IPv4 da Microsoft. Não publica lista de prefixos. Não conclui propriedade. O corpo do registro e o conjunto completo de recursos vinculados não foram lidos como texto. Tirar números de um livro-razão não lido é chute, não reportagem.

O que se pode afirmar é a existência do arranjo: a ARIN mantém um marco público de transferência de IPv4 e um histórico de registro pelo qual espaço endereçado registrado passa entre organizações, inclusive após o esgotamento do pool central (ARIN: transferência de IPv4). Que transferências aconteçam e quem detém quanto são perguntas distintas. A primeira é institucional; a segunda exige ler o livro-razão.

A compra da Nortel em 2011, e por que ela não é a explicação

Como contexto histórico, há o noticiário de abril de 2011. BBC News e Ars Technica reportaram que a Microsoft adquiriu 666.624 endereços IPv4 da Nortel por cerca de 7,5 milhões de dólares, dentro da alienação de ativos ligada à falência da Nortel (BBC News, Ars Technica).

A aritmética direta dá cerca de 11,25 dólares por endereço. É conta sobre números reportados, não preço fixado pela ARIN, muito menos preço de mercado atual. Os corpos das matérias não foram lidos como texto nesta apuração, então o dado é tratado como fato atribuído à imprensa.

E aqui está o ponto importante. Essa transação de 2011 não explica a regra de configuração da Azure de hoje. A causalidade segundo a qual um provedor que comprou IPv4 no passado teria escrito o requisito de interface atual não está registrada em lugar nenhum. Este artigo não a afirma. A história mostra que espaço de endereçamento pode ser ativo negociado em dinheiro. Não mostra mais que isso.

Onde a migração realmente está

A migração para IPv6 não avançou? Este artigo não mediu isso. Não fez observação de BGP (o mecanismo pelo qual redes trocam rotas), não mediu endpoints, não entrevistou clientes. A comparação entre metadados publicados e o estado real da rede não foi executada aqui.

O que se pode afirmar é a forma da resposta que a plataforma preparou. IPv6 é oferecido, o endereço IPv6 público é gratuito, a conectividade é enquadrada como pilha dupla. Ao mesmo tempo, configuração somente IPv6 não é suportada e todo IPv4 é exigido em cada interface. Essa combinação não interrompe a migração. Ela desloca o ponto final: não é o lugar onde o IPv4 desaparece, é o lugar onde o IPv4 convive sempre.

O efeito prático para o cliente é direto. Adotar IPv6 não é remover configuração IPv4. É somar IPv6 mantendo a configuração IPv4. O projetista passa a planejar endereços com as duas famílias simultaneamente em mente.

O que mudaria esta leitura

Esta leitura muda com observações concretas. Primeiro, se a Microsoft publicar um documento explicando a razão, a data de introdução e a condição de encerramento prevista para o requisito de interface. Segundo, se a configuração somente IPv6 passar a ser suportada. Terceiro, se a estrutura tarifária dos endereços IP públicos mudar e a diferença de preço entre IPv4 e IPv6 desaparecer. Quarto, se o esquema e a cobertura do arquivo de faixas de IP publicados puderem ser lidos e o tratamento por família de endereços ficar claro.

Nada disso aconteceu. O que existe é o requisito de configuração escrito na documentação pública e a estrutura de preços escrita na documentação pública, lado a lado. A Azure não recusa IPv6. Recusa que IPv6 baste. E publicou essa decisão sem publicar as razões.

O registro da Microsoft Corporation pode ser consultado no diretório do BTW (entity:microsoft-corporation-us).