Resumo

  • O RFC 9947 restringe seu TLV SRH experimental de Alternate Marking a um domínio SR controlado, mas espera que resultados de testes voluntários em redes vivas cheguem ao Independent Submissions Editor ou ao grupo IETF SPRING. Conter o pacote e autorizar a evidência são controles diferentes.
  • Um resultado público precisa de um recibo de saída que vincule autoridade, versões, código experimental, escopo implementado, comparação com o RFC 9343, grupos de equipamentos, amostra, incerteza, resultados negativos, regras de agregação, hashes e correções, mantendo tráfego bruto, identidades e topologia explorável sob proteção.

A pergunta pública nasce em uma rede privada

Publicado em março de 2026, o RFC 9947 é Experimental e pertence ao Independent Stream. A extensão foi desenvolvida fora da IETF, não tem consenso da IETF e não é candidata a nenhum nível de Internet Standard. Ela tampouco solicita ação da IANA.

O texto descreve uma alternativa para SRv6: transportar dados de Alternate Marking em um TLV do Segment Routing Header. O RFC 9343, de Standards Track, usa opções IPv6 Hop-by-Hop ou Destination. Um método não invalida o outro. A coexistência é possível e a experiência serve justamente para comparar.

As perguntas vão além de verificar se um contador subiu. O TLV SRH sobrevive melhor no caminho? Seu processamento ajuda ou atrapalha o equipamento em relação à Destination Option? Arquiteturas diferentes apresentam efeitos diferentes no plano de encaminhamento? A função continua correta com programação SRv6 e controle de SID? Os campos estendidos oferecem valor frente a outras técnicas de telemetria no caminho?

O RFC espera que os resultados sejam reunidos e compartilhados como Internet-Drafts com o Independent Submissions Editor ou com SPRING. Resultados iniciais são esperados dentro de dois anos. Como o documento é recente, isso não constitui hoje uma cobrança vencida.

O desafio está na frase que antecipa uma implantação em uma única rede de provedor. A escolha respeita o domínio SR e os limites de compartilhamento dos dados de desempenho recolhidos ao longo do caminho dos pacotes. A mesma confidencialidade que torna o teste aceitável pode tornar seu resultado impossível de avaliar se não houver uma saída bem definida.

O perímetro técnico não é uma política de publicação

O experimento deve funcionar apenas em domínio controlado. Um operador decide usar e configurar Alternate Marking, administra os nós localmente e impede que pacotes com o AltMark TLV entrem ou saiam.

O tipo TLV usa um valor experimental entre 124 e 126. As implementações participantes coordenam esse valor; o operador deve conseguir configurá-lo para que testes simultâneos não colidam. É um acordo local, não um número permanente nem autorização para adoção ampla.

Esse controle evita que terceiros interpretem um formato que não aceitaram e protege a medição de tráfego externo malicioso. Mas ele termina no pacote. Um relatório pode combinar horários precisos, poucos dispositivos e uma classe de tráfego rara o bastante para revelar um caminho. Uma tabela por arquitetura pode expor uma limitação comercial. Retirar nomes não elimina essas relações.

Também ocorre o erro oposto. Para evitar qualquer risco, o relatório publica só a média final e remove tamanho da amostra, carga, intervalos ruins e exclusões. A informação parece segura, porém já não separa efeito do protocolo de efeito do equipamento ou da seleção.

Cada campo muda a experiência

No formato básico aparecem FlowMonID de 20 bits e marcadores de perda e atraso. O modo avançado pode trazer FlowMonID estendido, medição segmento a segmento ou ponta a ponta, fragmentação, direção, timestamp, controle para criar observação no sentido reverso e número de sequência. O controle reverso pode considerar máscaras de prefixo, protocolo, portas, DSCP, escopo do túnel e período.

Logo, dizer que uma implementação “suporta o RFC 9947” é pouco. É preciso saber o subconjunto de campos, os comportamentos SID que processam o TLV e os pontos que não o suportam. Um nó SRv6 pode ignorar o TLV desconhecido conforme as regras do SRH; isso não é necessariamente falha.

O braço RFC 9343 precisa receber condições comparáveis. Se muda o tamanho do pacote, a carga, o caminho, a função habilitada ou o grupo de equipamentos, muda também a pergunta. Uma diferença precisa não é automaticamente uma diferença causada pelo local do marcador.

Até o valor de 124–126 faz parte da procedência. Se o emissor usa 124 e o receptor espera 126, um aparente problema de compatibilidade é configuração. Se outro ensaio reutiliza o valor, as amostras podem se misturar. Registrar o código não lhe dá autoridade; preserva a ligação entre configuração e observação.

Metadados não são material neutro

O RFC 9343 reconhece que Alternate Marking não libera dados de usuário, mas seus metadados ainda podem apoiar reconhecimento de rede. FlowMonID pode ajudar a acompanhar fluxos, e vários pontos de observação podem revelar caminhos e desempenho. Os canais que enviam estatísticas ao sistema de gestão precisam ser protegidos.

O RFC 9341 aborda a integridade: marcação e sincronização de tempo podem ser manipuladas, a recolha pode sofrer interferência e existe a possibilidade teórica de um canal oculto de baixa taxa. Portanto, a evidência precisa declarar hipóteses de relógio, contador e proteção, não apenas os valores medidos.

O RFC 8799 explica que a fronteira de um limited domain pode proteger parâmetros operacionais que o operador não deseja revelar. Isso é distinto da privacidade de pessoas, embora os dois controles possam se sobrepor. Uma anonimização baseada apenas em retirar nomes pode preservar combinações que identificam atividade.

A governança da saída precisa tratar confidencialidade como transformação declarada. Quais dimensões foram agrupadas? Quais foram suprimidas? Qual teste deixa de ser reproduzível? Que conclusão ainda é suportada depois dessa perda? Sem essas respostas, “anonimizado” funciona como selo, não como método.

O recibo mínimo

A primeira linha deve nomear a autoridade: operador ou patrocinador, papel que aprovou a divulgação, destino e horário da submissão e relações materiais de financiamento ou fornecimento. Recebimento pela ISE ou discussão em SPRING não equivalem a endosso, consenso da IETF ou promoção ao Standards Track.

A identidade técnica vem depois: revisão do RFC ou Internet-Draft, build da implementação, valor TLV usado, campos básicos e avançados, comportamentos SID e configuração equivalente segundo o RFC 9343. Hashes podem fixar artefatos protegidos sem torná-los públicos.

A população deve ser legível. Arquiteturas, software e firmware podem ser agrupados em nível que explique diferenças sem criar um inventário vulnerável. Forma do caminho não exige localização exata. Intervalo, tráfego elegível, exclusões, amostragem, relógios, contadores e definições de perda, atraso, jitter, sobrevivência e custo de processamento precisam acompanhar o resultado.

Por fim, o registro conserva êxitos, falhas, casos inconclusivos e testes revertidos. Ele informa quais atributos de fluxo, caminho, tempo e fornecedor foram agregados ou retirados, quais limites isso impõe à reprodução externa, se existe revisão restrita de material protegido e como uma correção substitui ou qualifica a versão anterior.

Esse recibo é uma proposta editorial de Daniel Kade, não um requisito do RFC 9947. Não é uma exigência de publicar o conjunto de dados. É a menor unidade capaz de provar como uma observação protegida virou uma afirmação pública.

Implementação não é consenso

O RFC 7942 mostra uma prática vizinha. Sua seção voluntária Implementation Status pode registrar organização, implementação, maturidade e cobertura para que grupos avaliem running code. O texto avisa que listar uma implementação não significa endosso da IETF e que a informação muda com o tempo.

O mesmo RFC exclui o Independent Stream de seu escopo. Portanto, não oferece um contrato obrigatório para o RFC 9947. Oferece apenas a ideia útil de que implementação tem identidade, cobertura e data.

O RFC 7841 mantém a classificação institucional. Mesmo um resultado convincente não transforma retroativamente um RFC Experimental do Independent Stream em consenso IETF. Pode inspirar um novo trabalho, sustentar uma escolha futura ou mudar prioridades. A força da evidência e a origem normativa permanecem separadas.

O que ainda não se sabe

As fontes confirmam o status do RFC 9947, seus campos, o domínio controlado, as perguntas e a expectativa de compartilhamento. Também explicam riscos de privacidade, integridade e o contexto SRv6. Elas não trazem uma lista de operadores, resultados concretos nem conjunto público de dados.

Este artigo não escolhe entre o TLV SRH e o RFC 9343. Não diz que resultados estão atrasados. Não pede pacotes brutos, clientes, topologia exata ou segredo de fornecedor.

Seu pedido é mais limitado: quando a evidência sair, deve ser possível ver quem a autorizou, qual experiência ela representa, o que foi retirado e onde termina sua conclusão. O domínio pode continuar fechado ao tráfego experimental. A discussão pública recebe uma prova menor, versionada e corrigível, sem receber a própria rede.

Fontes

  1. Heng Lu — The Policy Mirror
  2. Heng Lu — Minimum Initial Specification, Localized Future Decision, Voluntary Adoption
  3. Heng Lu — Why BTW Media Exists and Why Reality, Not Advocacy, Is the Product
  4. Registro do RFC 9947 no RFC Editor
  5. RFC 9947 — Alternate-Marking Method no Segment Routing Header
  6. RFC 9341 — Alternate-Marking Method
  7. RFC 9342 — Clustered Alternate-Marking Method
  8. RFC 9343 — Aplicação IPv6 do Alternate-Marking Method
  9. RFC 8799 — Limited Domains and Internet Protocols
  10. RFC 8402 — Segment Routing Architecture
  11. RFC 8754 — IPv6 Segment Routing Header
  12. RFC 8986 — SRv6 Network Programming
  13. RFC 7841 — RFC Streams, Headers, and Boilerplates
  14. RFC 7942 — Improving Awareness of Running Code