Resumo

  • O rascunho v6ops revisão 02, de 28 de outubro, determina que um erro ICMPv6 com origem externa intraduzível seja devolvido com fonte IPv4 pública se houver uma disponível; nos demais casos, o tradutor deve usar 192.0.0.8. A revisão 01 recomendava o endereço fictício sem explicitar essa preferência.
  • O endereço IPv6 original deve, como recomendação, entrar em um objeto Node Identification. Para Packet Too Big, o objeto só pode ser anexado depois da tradução para ICMPv4 e pode ser omitido; o erro ainda deveria ser entregue. O registro da IANA classifica 192.0.0.8/32 como endereço IPv4 fictício.

O caminho de volta exige um remetente IPv4

Mensagens ICMPv6 de destino inacessível, tempo excedido e pacote grande demais podem nascer numa rede só IPv6 depois que tráfego IPv4 foi traduzido para entrar nela. Quando a origem IPv6 externa do erro não combina com o prefixo de tradução e não possui mapeamento estático ou com estado, o tradutor não consegue preencher a fonte da resposta ICMPv4 com o endereço real. O campo IPv4 não carrega uma origem IPv6 arbitrária. Se não houver um IPv4 público no próprio tradutor, a velha solução de responder em nome de um endereço público também desaparece.

O texto novo estabelece uma ordem de preferência entre duas fontes. Havendo endereço ou conjunto IPv4 público, o tradutor deveria usá-lo segundo a solução já descrita em RFC 6791. Sem esse recurso, deve usar 192.0.0.8. A versão anterior formulava o endereço fictício como recomendação geral para a origem intraduzível. A nova versão impede que a presença de um IPv4 público seja tratada como detalhe decorativo. Ela também reconhece o caso dos dispositivos de tradução que não têm um endereço escasso reservado para gerar seus próprios diagnósticos.

A tabela oficial de endereços especiais chama o /32 de «IPv4 dummy address». Sua coluna de origem permite o uso como remetente; as de destino, encaminhamento e alcance global como destino são negativas. Isso faz de 192.0.0.8 um sinal de substituição, não uma identidade de roteador. A saída de um traceroute que mostra esse número como salto real entrega ao operador uma pista limpa e errada.

Para recuperar a origem, a proposta recomenda inserir um objeto Node Identification contendo um subobjeto IP com o IPv6 original. Quando inserido, esse endereço precisa estar lá e a soma de verificação da extensão deve ser ajustada. Se a origem IPv6 é traduzível normalmente, o projeto proíbe tanto o uso do endereço fictício quanto o acréscimo do objeto. A ramificação fica ligada à condição real do mapeamento, não a uma preferência visual do software de diagnóstico.

Uma mensagem de tamanho pode sobreviver sem nome completo

Packet Too Big é o caso mais incômodo. A mensagem informa que o emissor precisa ajustar o tamanho dos pacotes. A extensão necessária para conservar a identidade não pode ser acrescentada ao ICMPv6 Packet Too Big antes da conversão. O tradutor deve primeiro gerar ICMPv4 e só então anexar Node Identification. A especificação permite não anexá-lo nesse caminho. Recomenda, porém, que o erro continue sendo traduzido com o endereço fictício e que não seja descartado.

O preço é uma resposta útil com atribuição incompleta. O cliente IPv4 recebe a indicação de tamanho, mas sua tela talvez mostre apenas o número reservado. Isso é melhor que silenciar o erro e pior que apresentar a fonte original. A disciplina está em não vender as três situações como equivalentes.

Também há uma decisão de escopo antes da tradução. O equipamento deve reconhecer que o erro veio de tráfego IPv4 traduzido e não de tráfego IPv6 nativo. Um IPv6 dedicado ou um /64 para a função torna a separação mais simples. Se o mesmo endereço atende aos dois usos, podem ser necessários estado ou inspeção do cabeçalho do pacote que provocou o erro. O registro da IANA resolve a disponibilidade de um marcador; não resolve essa classificação de fluxo.

A seção 8, dedicada à operação, diz que ferramentas como traceroute precisam interpretar e mostrar Node Identification. Uma extensão pode estar correta no pacote e invisível ao operador. Aqui, esse objeto responde a um dilema específico do tradutor sem IPv4 público. O Datatracker registra um Internet-Draft de grupo de trabalho em avaliação do IESG, destinado a atualizar RFC 6791 e RFC 7915 se aprovado. Ainda falta uma captura de duas implementações mostrando as duas opções de origem.

Fontes