Resumo

  • A saída padrão não nasceu na revisão 28: a versão 27 já a descrevia. A nova revisão explicita mais o gerenciamento, a retirada de regras e a prevenção de ciclos.
  • Para novas conversões, uma regra específica retirada deve desaparecer imediatamente. Se houver 0.0.0.0/0: Pref6(PE), o tráfego sem correspondência específica pode usá-la; sem ela, o resultado previsto é descarte e erro ICMP ou ICMPv6.
  • Uma saída padrão não deve ser anunciada além de uma fronteira administrativa sem acordo bilateral explícito, nem devolver o pacote IPv4 restaurado ao mesmo arcabouço.

Uma alteração em duas redes

O documento do grupo v6ops propõe um arcabouço operacional para carregar tráfego IPv4 residual sobre um underlay exclusivamente IPv6. A conversão ocorre na borda; a travessia não depende de gateway com estado por fluxo no caminho. O domínio é limitado a um operador ou a operadores cooperantes, não à Internet aberta. Antes da implantação, eles precisam de acordos bilaterais, coordenação dos prefixos de mapeamento, filtragem ICMP comum e confiança nos PEs de ingresso. O draft não substitui esses acordos nem estabelece automaticamente o que um parceiro aceitou transportar.

É por isso que o controle de mudanças não termina na remoção de uma linha. Suponha que uma regra específica para um bloco IPv4 seja retirada. A revisão 28 recomenda que ela deixe de valer imediatamente para novas conversões; pacotes em trânsito podem ter um período de tolerância configurável de alguns segundos. Depois disso, uma regra padrão configurada pode atrair o tráfego que perdeu a correspondência. Sem uma regra padrão, o pacote deve ser descartado, com aviso ICMP ou ICMPv6. A retirada e a escolha do substituto são decisões distintas, com consequências em lados diferentes da interconexão.

A regra 0.0.0.0/0: Pref6(PE) funciona como uma rede de segurança para destinos sem mapeamento mais específico. Pode reduzir interrupções, mas também concentrar carga em uma saída distante ou insuficiente, criar trajeto pior e oferecer um alvo para desvio de tráfego. A versão 27 já explicava essa lógica e seus perigos. Chamar a versão 28 de invenção da saída padrão apagaria a diferença real: o texto agora descreve melhor como retirar, observar e limitar o mecanismo quando vários domínios estão envolvidos.

O acordo tem um alcance, não uma sombra infinita

A seção 9.4 impede a propagação da regra padrão além da fronteira administrativa sem acordo bilateral explícito. Não basta que duas redes tenham colaborado em algum momento. É necessário saber quais blocos e prefixos, qual saída, em que direção, por quanto tempo e sob quais condições uma mudança é aceita. Um pacote que chega ao PE de outro operador demonstra uma trajetória, não o consentimento daquele operador para receber todo o IPv4 residual.

O draft exige que a distribuição preserve os campos das regras, permita escopo e filtragem, autentique sua origem e rejeite vínculos não autorizados entre bloco IPv4 e prefixo de mapeamento. Mas deixa extensões concretas de protocolo fora do arcabouço. Portanto, não há aqui um protocolo universal pronto ou um registro público de autorização bilateral. A auditoria precisa juntar o estado recebido por cada rede com os termos que cada uma de fato aceitou. Nenhuma delas ganha poder para aprovar unilateralmente a rede da outra.

A saída pode ser uma volta

Após a conversão no PE de saída, o pacote IPv4 recuperado não traz uma marca indicando que já percorreu esse underlay. Se a melhor rota IPv4 daquele PE levar a outro participante, o pacote poderá ser convertido de novo e reentrar. Uma volta desse tipo consome capacidade mesmo que o primeiro salto tenha parecido bem-sucedido. TTL e limite de saltos fazem o ciclo terminar em algum momento; não provam que o encaminhamento tenha sido correto.

Por isso, a saída padrão precisa de uma visão completa de encaminhamento IPv4 para o conjunto de destinos que atrai e não pode resolver esses destinos para uma rota que reentre no mecanismo. Monitoramento, limite de taxa e ACLs para a regra de captura geral também são relevantes. Um teste antes da mudança deveria conferir as melhores rotas reais da saída para destinos afetados; depois, verificar contadores por regra, erros e o destino efetivo. As fontes públicas não mostram uma implantação específica que tenha feito esse teste, nem um incidente concreto que ele teria evitado.

O que o registro de mudança precisa unir

A seção 8 recomenda versão ou carimbo de tempo nas regras, resumos para checar consistência da MR-DB, notificações, contadores por regra e acesso de gestão. São recomendações de visibilidade, não comprovação de prática universal. A proposta editorial de Daniel Kade é um registro bilateral curto, ligado a uma retirada concreta: bloco e versão retirados, momento da remoção para novas conversões, tolerância aos pacotes em trânsito, fotografias das regras restantes dos dois lados, escopo acordado, PE padrão escolhido, resultado do teste de rota IPv4 e de não reentrada, contadores, erros, responsáveis e gatilho para reverter.

Não é um artefato obrigatório do IETF, um campo no pacote ou uma alegação sobre uma implantação real.

Esse registro permite reconstituir a sequência: a regra antiga perdeu validade; outra regra ou uma política de descarte assumiu; uma saída de outra administração aceitou ou não uma carga delimitada. O fato de o serviço continuar não responde à primeira nem à terceira pergunta. Uma contagem nula também pode significar ausência de tráfego, não ausência de risco. A evidência convincente é a junção entre a versão aceita, o limite do acordo e a rota que de fato sai do domínio cooperante.

Na consulta ao Datatracker, a versão 28 continuava sendo Internet-Draft ativo do grupo v6ops, com intenção Informational e acompanhamento do diretor de área na IESG; posições DISCUSS permaneciam. Não era RFC aprovado, extensão de distribuição finalizada nem demonstração de implantação. O texto pode mudar. Mesmo assim, seu ponto operacional já é legível: uma saída padrão útil não pode transformar uma lacuna de mapeamento em autorização ilimitada entre redes.

Fontes