Resumo

  • A RIPE NCC afirmou que 86% dos clientes eram compatíveis com a rede IPv6-only da reunião, com NAT64 para alcançar tráfego IPv4.
  • Na sala principal, a equipe desligou o rádio de três pontos de acesso, ativou outros seis e ainda registrou pequenos problemas.

O número de compatibilidade cabia no slide: 86% dos clientes suportavam IPv6-only. Na sala principal, a equipe desligou os rádios de três APs e ativou outros seis. O relatório de encerramento da RIPE 93 registra os dois fatos e diz que alguns problemas pequenos continuaram.

Em Sófia, a infraestrutura cobria cinco andares. A equipe técnica da RIPE NCC disse que o cabeamento interno funcionou como esperado. Os clientes da configuração IPv6-only recebiam endereço IPv6; o NAT64 traduzia o tráfego IPv4. A afirmação de que 86% dos clientes eram compatíveis descreve a capacidade dos aparelhos.

O defeito relatado ficava antes do tradutor. Alguns AP continuavam descartando multicast solicited-node usado pelo Neighbor Discovery do IPv6 para descobrir o endereço de enlace de um vizinho. O RFC 4861 descreve a troca: o equipamento envia uma Neighbor Solicitation ao endereço multicast solicited-node da máquina de destino e aguarda uma resposta. Quando a troca se completa, o tráfego segue até o NAT64 para a tradução. Para quem precisava chegar a um serviço IPv4, a solicitação ao vizinho era o primeiro passo da conexão: se o AP a descartasse, a sessão podia parar antes do gateway.

A equipe já havia observado o mesmo problema, ou algo parecido, em reuniões recentes. O fabricante dizia que a falha estava corrigida, mas a RIPE ainda via sintomas em Amsterdã com pontos de acesso da mesma geração. A equipe executou um NDP fixer no firewall; Menno Schepers disse que isso ajudou com o multicast descartado. Na sala principal, os rádios de três AP foram desligados e seis outros pontos foram ativados. A sala lateral e a área do café não mostraram o mesmo padrão. Mesmo assim, o relatório diz que alguns problemas menores continuaram.

É um relato de engenharia bastante concreto; a qualidade do serviço exige outra série de dados. A compatibilidade de 86% descreve a capacidade dos aparelhos. Schepers disse que o Wi-Fi da sala principal funcionou corretamente “pelo menos na maior parte do tempo”. A transcrição não informa o total de clientes, os resultados por sala nem a série NAT64 exportável; esses dados mostrariam se a compatibilidade declarada virou serviço confiável e se as direções do gráfico se reconciliam.

O gráfico de NAT64 trouxe outra questão. Na sessão de perguntas, uma pessoa apontou que as duas linhas pareciam simétricas demais caso representassem entrada e saída. Schepers respondeu que eram um pouco diferentes e que verificaria; o moderador disse que a equipe investigaria. A transcrição preserva o questionamento e o compromisso de checar o gráfico.

O RFC 6146 define o NAT64 como uma forma de permitir que clientes IPv6 alcancem servidores IPv4. Essa conversão ocorre em outro ponto do caminho em relação ao multicast da rede sem fio. Uma curva no gateway registra pacotes traduzidos; os resultados por sala mostram se cada cliente resolveu o vizinho no primeiro salto. Rótulos de direção ajudam o leitor a interpretar as duas séries.

A equipe trocou rádios, acrescentou cobertura, instalou uma solução temporária e pediu aos participantes que avisassem sobre falhas. O relatório registra um teste IPv6-only compatível com muitos clientes e deixa espaço para mostrar o resultado de cada sala.

Fontes primárias: transcrição do plenário de encerramento da RIPE 93 · sessão do relatório técnico da RIPE 93 · RFC 4861 · RFC 6146.