Resumo

  • O RFC 9812 substitui IESG Approval por IETF Review para o uso futuro não rotineiro do espaço IPv6 reservado pelo IETF, elevando o registro público necessário à próxima decisão.
  • A ação direta é atualizar o procedimento do registro; o RFC não escolhe prefixo, finalidade, delegação a RIR, anúncio de rota ou implantação.
  • Um recibo da reserva ao uso deve separar política, pedido, decisão IETF, mutação do registro, delegação e observação operacional. É uma proposta editorial de Daniel Kade, não um campo do RFC.

Uma linha registral pode parecer um evento de recursos. O registro IPv6 Address Space da IANA cita o RFC 9812 e exibe faixas extensas como Reserved by IETF. Juntar “sete oitavos” e “revisão mais rigorosa” sem indicar os estados intermediários pode sugerir que o IETF acabou de liberar uma nova faixa.

Não liberou. O RFC muda a regra de uma decisão futura. IESG Approval permitia aprovação caso a caso sem RFC obrigatório. IETF Review exige RFC no fluxo IETF, IETF Last Call e aprovação do IESG como consenso IETF. A prova de autoridade fica mais ampla; o pedido concreto que um dia atravessará essa porta ainda não existe no documento.

Reserva não é disponibilidade

2000::/3 é a faixa atual de unicast global, com alocações da IANA exibidas em um registro próprio. A maior parte do restante fica reservada pelo IETF caso o espaço unicast atual se torne insuficiente ou inadequado.

“Reservado” é uma disposição. Não significa aberto a pedidos, propriedade de um operador, delegado a um RIR, roteável ou prometido para liberação. O quadro da IANA informa usos parciais, especiais e históricos dentro de algumas faixas superiores. O rótulo aponta quem pode mudar a situação, não o que uma rede já pode usar.

O tamanho justifica cautela, mas não mede nova alocação. Trocar a regra da porta não desloca os bits atrás dela.

As políticas exigem provas diferentes

O RFC 8126 trata IESG Approval como mecanismo excepcional. Um RFC não é requisito inerente; o IESG pode pedir documentos ou consultar a comunidade. A política serve como contingência e não como atalho em torno de uma revisão pública possível.

IETF Review só permite a atribuição por RFC do fluxo IETF, conduzido como documento de grupo de trabalho ou patrocinado por Area Director, submetido a Last Call e aprovado como consenso IETF. Não precisa ser Standards Track. Abrir uma faixa pode exigir análise coletiva sem definir um novo padrão de protocolo.

O RFC 9812 eleva, portanto, a prova mínima da autoridade. Não concede autorização antecipada para qualquer uso. Um caso futuro ainda terá de nomear recurso, finalidade e ações da IANA.

5f00::/16 é precedente, não resultado

O RFC 9602 alocou 5f00::/16 para Segment Identifiers de SRv6 e levou o bloco ao registro de propósitos especiais. Como documento de grupo, seguiu a via que o RFC 9812 depois tornou regra.

A cronologia elimina a confusão. O RFC 9602 saiu em outubro de 2024; o RFC 9812, em outubro de 2025. O segundo não fez aquela alocação, nem transformou propósito, tamanho ou destino em modelo universal. Usou um caso concluído para demonstrar a viabilidade da revisão mais forte.

Política não é log de execução

Registros da IANA combinam disposição atual, referências, datas e política de mudanças futuras. Esses campos não são um único evento.

A instrução direta do RFC 9812 é trocar para IETF Review o procedimento do IPv6 Address Space. A linha atualizada prova a regra do próximo pedido, não a existência de um pedido.

Se um RFC futuro aprovar um prefixo, ele provará a instrução. A alteração registral provará a execução pela IANA. Delegação a RIR, anúncio BGP, aceitação por filtros, suporte de produtos e uso precisarão de fontes próprias. Dizer apenas “o IETF alocou” apaga a revisão pública e promete operação que o registro não certifica.

A correção do RFC 1881 reforça o limite

O RFC 9812 também corrige a classificação do RFC 1881. O texto conjunto IAB/IESG de 1995 passou por IETF Last Call, mas aparecia como Legacy. Pelo modelo posterior da série, pertence ao fluxo IETF.

Corrigir o rótulo não repete a decisão de 1995 e não modifica alocações posteriores. Repara a proveniência. A lição vale para a nova política: identificar registro, campo, referência e data, sem deduzir movimento de recurso de um rótulo procedimental.

Um recibo da reserva ao uso

O reservation-to-use receipt é um controle editorial e operacional, não requisito do RFC 9812 nem nova instrução à IANA.

A primeira camada registra estado permanente: registro exato, faixa reservada, política, referência e momento da observação. A segunda registra um pedido futuro: prefixo, finalidade, documento, fluxo, patrocinador, estado do grupo e registros de origem e destino.

A decisão separa Last Call, revisões materiais, conclusão de consenso, aprovação IESG e RFC final. A execução registra cada mutação da IANA: linha anterior, linha nova, referência, data e tipo de ação. Publicar o RFC não fecha automaticamente essa camada.

A operação liga separadamente delegação RIR, origem de rota, filtros e implantação. approved but not registered, registered but not delegated e announced but not broadly reachable são estados úteis.

Assim, cada verbo público recebe sua prova: a política mudou; o pedido foi revisado; o documento foi aprovado; a IANA alterou a linha; o operador iniciou o uso.

A responsabilidade fica entre as etapas

O RFC 9812 diz que a mudança não tem impacto direto de segurança, mas que mecanismos cuidadosamente revisados são necessários à responsabilidade operacional dos endereços. A revisão não garante acerto; torna autoridade e finalidade reconstruíveis.

Os incentivos à compressão permanecem. A instituição pode vender reforma como adoção; o proponente, consenso como implantação; o registro, estado atual sem história; o operador, alocação como disponibilidade global.

A resposta é uma cadeia atribuível de mudanças. O RFC 9812 concluiu a primeira: a regra da próxima grande escolha. Cada consequência posterior ainda precisa ser demonstrada.

Fontes