Resumo

  • A revisão 01 de draft-dong-sidrops-rpki-rtr-moa-pdu, publicada em 9 de setembro de 2026, acrescenta retiradas totais e parciais de conjuntos divididos entre PDUs, além de regras de Refresh, Retry, Expire e Serial Number. Ela continua sendo um Internet-Draft individual ativo, não um documento de trabalho adotado pelo SIDROPS nem um padrão do IETF.
  • A interação entre MOA e ROA IPv6 — inclusive a ordem da validação e o comportamento de fallback — fica para uma especificação de verificação que o texto diz esperar. Uma matriz pública com os resultados dos dois planos é o mínimo para preservar escolha local sem esconder decisões incompatíveis em defaults de software.

Uma autorização assinada pode reunir vários prefixos IPv4 sob um prefixo de mapeamento IPv6. O cache não precisa transportar o conjunto inteiro em uma só mensagem: se ele for grande, pode dividi-lo. Essa flexibilidade cria uma pergunta para o dia da retirada. O roteador precisa lembrar como o conjunto foi empacotado meses antes para conseguir remover apenas dois prefixos?

A revisão 01 responde que não. Em uma retirada completa, o cache pode mandar todos os prefixos juntos ou reproduzir os subconjuntos anteriores. Em uma retirada parcial, um ou mais Withdrawal PDUs precisam somar exatamente os prefixos retirados. O roteador remove a união recebida e não compara a quantidade de mensagens de saída com a quantidade usada no anúncio.

O efeito de governança é discreto, mas importante: a forma transitória do transporte não vira parte da autoridade durável. O titular autorizou uma relação entre prefixos, não uma determinada fragmentação de bytes.

A revisão 00 não tinha essa regra. O diff oficial também mostra a chegada de uma ordenação canônica, de uma seção de ciclo de vida e de um limite explícito para a lógica de validação.

O estado processual não vem do nome do arquivo

O registro no Datatracker e a API do documento classificam a proposta como submissão individual ativa. Não há stream do IETF, Area Director responsável, shepherd nem nível normativo pretendido. O histórico registra a nova versão de Guozhen Dong em 9 de setembro; a API da submissão preserva autoria e datas.

sidrops no identificador aponta para o tema ou fórum pretendido. Não equivale a adoção pelo Working Group. O perfil MOA citado pela proposta é, esse sim, um documento do SIDROPS. Um status não passa para o outro por referência. Da mesma forma, pedir um código de PDU à IANA não significa que a alocação já ocorreu.

O desenho completo contém pelo menos cinco objetos que não podem ser tratados como uma só autorização.

O primeiro é o MOA assinado pelo detentor de endereços. O perfil MOA, revisão 04, permite que um prefixo de mapeamento IPv6 seja autorizado a originar mapeamentos para um ou mais prefixos IPv4. Vários prefixos IPv6 para o mesmo conjunto exigem vários MOAs. O objeto delimita um direito; não é uma rota instalada.

O segundo é o resultado do relying party. Além dos testes de objeto assinado do RFC 6488, ele verifica se cada prefixo IPv4 está contido na extensão de delegação IP do certificado de entidade final. O próprio perfil distingue autorização, autenticação pessoal e não repúdio.

O terceiro é a projeção que o cache produz para o roteador. Ela vem de um MOA validado e passa a seguir ordem canônica. Mesmo protegida por uma sessão autenticada, continua sendo dado derivado, não o objeto original assinado.

O quarto é a entrada na base MOV local. O RFC 8210 define o Serial Number como versão lógica de um cache. Um serial não é comparável entre caches nem entre versões do protocolo e talvez não sobreviva a um reset. Protocol Version, Session ID e Serial Number formam o contexto de sincronização; não provam, isoladamente, a intenção do titular.

O quinto é o anúncio BGP 4map6. A revisão 06 do 4map6 verifica a alcançabilidade do prefixo de mapeamento, atualiza uma Mapping rule Database e recomenda controles de distribuição. Só depois vem o comportamento efetivo do encaminhamento, que precisa de sua própria evidência.

ROA e MOA também não são abreviações intercambiáveis. O RFC 9582 trata da autorização dada a um sistema autônomo para originar rotas de prefixos. O MOA proposto autoriza um prefixo IPv6 a originar um mapeamento para prefixos IPv4. A infraestrutura criptográfica pode ser comum; o ato autorizado não é.

Retirada transmitida e expiração local

Outra novidade é a adoção dos temporizadores do RFC 8210. Quando Refresh vence, o roteador envia um Reset Query e deve continuar usando temporariamente os dados MOA já instalados. Depois de uma consulta malsucedida, Retry orienta nova tentativa. Se não houver atualização bem-sucedida até Expire, o roteador precisa remover todos os dados MOA e suspender decisões MOV baseadas neles até a conexão voltar.

Mudanças no conjunto MOA também devem elevar o Serial Number, permitindo detectar visão antiga ou fora de sincronia dentro da mesma relação comparável.

Uma retirada não é uma expiração. A primeira é uma alteração recebida para autorizações identificadas. A segunda é uma decisão local de não conservar indefinidamente a visão integral de um cache que deixou de atualizar. A retirada parcial pode deixar outras autorizações de pé; a expiração retira todo o conjunto MOA do processo.

Nem retirada nem expiração comprovam, sozinhas, que a rota 4map6 saiu da RIB ou da FIB, que pacotes mudaram de caminho ou que um serviço se recuperou. A prova precisa manter separados o objeto assinado, o PDU, a entrada MOV, o anúncio BGP e a observação do tráfego.

A especificação termina onde as provas se encontram

O perfil MOA explica por que a assinatura não encerra o problema. Um detentor IPv4 pode autorizar corretamente um prefixo de mapeamento, enquanto um terceiro origina maliciosamente o prefixo IPv6 subjacente. Por isso o texto recomenda validação de ROA IPv6.

O PDU novo repete a dependência, mas declara fora de escopo a interação detalhada, incluindo ordem e fallback. Segundo ele, uma especificação de verificação MOA esperada junto ao perfil cuidará dessa matéria.

No corte desta pesquisa, buscas públicas no Datatracker por nomes com MOA e títulos de Mapping Origin encontraram o perfil, a proposta de PDU e material de reunião, mas nenhum documento atual com a função de verificação anunciada. Isso descreve o arquivo público, não permite concluir que implementadores não tenham política interna nem que um texto futuro não apareça.

É justamente nesse ponto que a decisão se torna operacional. MOA Valid combinado com ROA IPv6 Invalid bloqueia a entrada? Um resultado IPv6 NotFound é tolerado, reduz preferência ou deixa a avaliação pendente? Se o cache MOA ainda está dentro de Expire, mas a rota IPv6 mudou, qual observação controla? Na reconexão, quais testes precisam ser repetidos antes de restaurar o mapeamento?

O número de série não escolhe nenhuma dessas saídas. Ele ordena versões dentro de um cache e uma sessão comparáveis. Retirar com exatidão responde “qual estado deve sair”; não responde “qual prova governa quando o estado entra”.

O escopo controlado do 4map6 reduz o universo inicial, não resolve a regra. A proposta fala em uma rede de um operador ou poucos operadores cooperantes e prevê autenticação específica em outro documento caso o uso cresça. Uma convenção privada pode ser suficiente para esse domínio, desde que não seja relatada como significado universal do protocolo.

Uma matriz de dois planos, não um novo comando central

O complemento mínimo é uma matriz de resultados de dois planos. Ela pode ficar na futura verificação ou em um perfil operacional público, sem inflar o PDU.

Cada linha deve relacionar resultado e motivo do MOA; endpoint do cache; Protocol Version, Session ID, Serial Number e momento observado; resultado do ROA IPv6 para o mapping prefix; ordem dos testes; se um resultado bloqueia, degrada ou evita o outro; estado local mantido ou apagado; versão da política; ação e condição de restauração.

O conjunto mínimo inclui MOA válido com IPv6 Valid, Invalid e NotFound; MOA inválido ou expirado; cache antigo ainda dentro de Expire e cache já vencido; retirada parcial e total; reset e resincronização. NotFound precisa continuar sendo NotFound. Um teste não executado não pode aparecer como sucesso.

A ideia segue a Minimum Initial Specification de Heng Lu: padronizar apenas o limite que permite coordenação e preservar decisão local. Running Code Primary acrescenta que a execução real precisa deixar evidência. Essa matriz é uma proposta editorial minha, não requisito do IETF, do SIDROPS ou dos autores.

A revisão 01 fez a parte correta ao permitir que uma autorização saia sem depender do pacote em que entrou. O próximo texto deve mostrar com a mesma clareza qual combinação de provas permite que ela volte a produzir efeito.

Fontes