Resumo

  • O RFC 7872 mediu DO8, HBH8 e FH512 em conjuntos históricos de servidores web, correio e nomes em 2014–15. Os percentuais descrevem esse desenho experimental, não a Internet de 2026.
  • As faixas entre parênteses estimam, somente entre pacotes já perdidos, a parcela fora do AS de destino. Caminho e propriedade organizacional continuaram ambíguos, e o experimento não revelou intenção nem causa de fornecedor.

A função pode ser escolhida no destino e vetada no caminho

Quando um domínio de destino decide aceitar uma extensão IPv6, ele ainda depende de cada rede anterior. Se uma delas descarta o pacote, passa a controlar na prática a possibilidade de uso por terceiros. Essa fronteira — mais do que qualquer número isolado — é o problema duradouro do RFC 7872.

Os números, porém, pertencem ao passado. O documento foi publicado como Informational em junho de 2016 e registra medições de agosto de 2014, repetidas em junho de 2015 com resultados semelhantes. Uma atualização do portal não transforma as sondas antigas em telemetria atual.

As listas World IPv6 Launch e Alexa Top 1 Million serviram de base. Delas vieram servidores web por AAAA, servidores de correio por MX seguido de AAAA e servidores de nomes por NS seguido de AAAA. Endereços duplicados, não globais e classificados como inalcançáveis foram retirados.

Três construções foram enviadas: DO8, Destination Options de oito bytes com PadN; HBH8, Hop-by-Hop Options de oito bytes com PadN; e FH512, cerca de dois fragmentos IPv6 de 512 bytes. O protocolo superior era TCP e a porta correspondia ao serviço.

Esse recorte não representa todas as opções, ordens, cadeias, tamanhos, transportes, regiões ou políticas. Dizer simplesmente que “cabeçalhos de extensão falharam” perde os limites do que foi testado.

Duas porcentagens, dois denominadores

O primeiro valor de cada célula é a taxa total de perda observada. A faixa entre parênteses estima, entre os pacotes perdidos, a fração descartada em AS diferente do AS de destino.

No conjunto web derivado de World IPv6 Launch, DO8 perdeu 11,88%; a atribuição fora do destino foi 17,60% / 20,80% dessas perdas. HBH8 perdeu 40,70%, com 31,43% / 40,00% fora do destino. FH512 perdeu 30,51%, com 5,08% / 6,78%.

Considerando web, correio e nomes, os conjuntos World IPv6 Launch ficaram em 11,88–17,07% para DO8, 40,70–48,86% para HBH8 e 30,51–39,17% para FH512. Nos conjuntos Alexa, as faixas foram 10,91–21,33%, 39,03–54,12% e 28,26–55,23%.

A atribuição variou ainda mais. Entre as perdas no conjunto web Alexa, DO8 teve 46,52% / 53,23% estimados fora do destino e FH512, 53,64% / 61,43%. Para HBH8 em servidores de nomes Alexa, a faixa foi 50,64% / 81,00%. Para FH512 no correio World IPv6 Launch, apenas 2,91% / 12,73%.

Logo, 81% não é uma taxa de perda de todas as sondas. É o limite superior de uma estimativa organizacional dentro do subconjunto que já falhou. A distinção impede que um resultado importante seja convertido em estatística universal.

O último salto visível não resolve a identidade

O método compara traceroute com e sem extensão. O último nó que responde no primeiro é M; o seguinte, M+1. Se o filtro atua antes da decisão de encaminhamento, o descarte é inferido em M+1; se atua depois, pode ser M. O estudo escolhe a primeira hipótese.

Ele também supõe que os dois traceroute seguem a mesma rota, embora reconheça que isso pode não ocorrer. Balanceamento e mudança de rota podem deslocar o ponto aparente.

Depois há a identidade institucional. Um endereço de peering pode usar espaço de qualquer par. Num IXP, pode pertencer ao exchange. O equipamento associado a M+1 pode ser operado pela organização mapeada ali ou no AS seguinte. Uma organização pode manter vários ASN, enquanto a análise trata ASN diferentes como organizações diferentes.

No melhor caso, ambiguidades são atribuídas ao destino; no pior, a outro AS. A faixa mede a fronteira do conhecimento, não a culpa.

Orientação posterior não reescreve a causa histórica

O RFC 7872 não separa política deliberada, padrão inadequado, bug, limite de análise ou outra condição. Um descarte no destino pode ser mais fácil de corrigir localmente, mas ainda prejudica. Um descarte em trânsito impede que o destino exerça sua escolha.

O RFC 9098 descreve dificuldades de análise variável, caminho lento, consumo de recursos e evasão. O RFC 9288 recomenda filtros conforme a capacidade do equipamento. O RFC 9673 atualiza procedimentos de Hop-by-Hop com trabalho limitado e configurável. Esses textos permitem formar hipóteses, não atribuir as perdas de 2014.

O RFC 7045 fornece uma referência normativa e o RFC 8200 define IPv6. Nenhum prova conformidade de uma plataforma específica. “A sonda não recebeu resposta” é observação; “a perda parece começar aqui” é inferência; “o operador quis bloquear” exige evidência que o estudo não contém.

Uma decisão atual exige uma campanha atual

Defina a cadeia exata, opções, comprimentos, transporte, portas, tamanho e fragmentação. Crie um controle sem extensão para os mesmos extremos e horários. Envie de múltiplos pontos autorizados.

Preserve bytes, horários, respostas, rotas e estado de roteamento. Em extremos controlados, use capturas e contadores. Traceroute ajuda a localizar, mas o relatório precisa conservar as incertezas sobre equivalência de caminho e momento do filtro.

Separe DO, HBH e fragmentação e, quando possível, caminhos de cliente, peer, trânsito, IXP e destino. Mudança de BGP, política, sistema ou aplicação exige repetição. Antes de nomear uma responsabilidade externa, ofereça a evidência ao operador para reprodução.

A conclusão deve caber no que foi observado: esta construção funcionou ou falhou para este serviço, destas origens, por estes caminhos e nesta janela. É base suficiente para implantar, limitar, recuar ou escalar — não para certificar a Internet.