Resumo

  • O RFC 9673 atualiza o RFC 8200 para tornar o processamento Hop-by-Hop seletivo, configurável e compatível com a taxa agregada de encaminhamento.
  • Um roteador pode encaminhar o pacote e pular uma opção que não implementa ou não ativou; chegada e wire speed não são recibos de execução.
  • A prova deve vincular plataforma e build, tabela habilitada, ordem e tamanho das opções, rota e tempo, observação por nó, impacto agregado e efeito no serviço.

Durante o teste, o gráfico de throughput não se moveu. A equipe comemorou: a nova opção parecia rodar em wire speed. O contador específico, consultado depois, continuava em zero. O equipamento preservara o encaminhamento justamente porque não executara o trabalho opcional.

Esse é o tipo de ambiguidade que o RFC 9673 torna administrável. Ele atualiza o RFC 8200 para que opções Hop-by-Hop possam ser usadas sem pressupor que todos os roteadores dispõem do mesmo parser, pipeline ou orçamento. A norma não promete execução uniforme; define uma forma segura de adoção parcial.

O pacote pode sobreviver ao trabalho recusado

IPv6 já exigiu que todos os nós examinassem o cabeçalho Hop-by-Hop. Em roteadores rápidos, processamento especial pode sair do fast path, disputar CPU com protocolos de controle ou abrir uma superfície de DoS. O RFC 7045 descreveu a realidade dos extension headers. O RFC 7872 mediu perdas relevantes em determinados experimentos; os RFC 9098 e RFC 9288 tratam de implicações e filtragem. Esses documentos justificam cautela, mas não medem a rede de hoje sem um novo teste.

RFC 9673 determina que um roteador que não processe o cabeçalho normalmente deve continuar com o restante do pacote e não descartá-lo apenas pela presença de Hop-by-Hop. Há uma exceção configurada e limitada para proteger equipamento downstream não compatível.

Assim, três estados deixam de caber no mesmo checkbox. O produto pode ser capaz. A política pode habilitar. O pacote pode acionar. Um quarto estado registra o resultado. O fato de o pacote avançar fecha apenas a camada de transporte observada.

A norma não inventa um orçamento único

Full Forwarding Rate é a taxa na qual o trabalho não prejudica o encaminhamento agregado. O RFC não escolhe um número universal de opções ou bytes. Arquitetura, revisão de hardware, software, posição no cabeçalho, semântica, packet rate e tráfego concorrente mudam o custo.

O texto recomenda não configurar o processamento da primeira opção se ele afetar a taxa agregada. Opções adicionais só devem ser tratadas sob a mesma condição. Uma implementação possível mantém uma lookup table configurável com os Option Types processáveis no full rate.

A tabela precisa ser exportada com modelo, build, interface, geração de política e condições de teste. Sem isso, “suportado” vira uma propriedade sem sujeito. Um upgrade pode deslocar um type para slow path; uma troca de chassi pode manter o nome da política e perder a capacidade; uma rota pode deixar de atravessar o nó medido.

O orçamento real é multidimensional. Chamá-lo apenas de “wire speed” favorece o lock-in, porque só o fornecedor consegue explicar o que o verde omitiu.

A ordem distribui a atenção escassa

A fonte pode limitar o pacote a uma opção ou controlar o tamanho total. Com várias, RFC 9673 recomenda ordem decrescente de importância: alguns roteadores talvez tratem apenas a primeira ou um conjunto limitado.

Colocar telemetria antes de uma ação necessária ao serviço pode consumir o único slot. A tabela da IANA prova a atribuição dos tipos e aponta para suas especificações. Não prova suporte, habilitação, prioridade nem execução.

RFC 9673 também torna configuráveis, nos casos previstos, descarte e ICMP quando a opção não é processada. A codificação dos bits de ação de uma opção desconhecida tem sua própria análise. Aqui, a questão é de autoridade operacional: qual trabalho o roteador aceita fazer sem comprometer o todo?

Ausência de erro não é sucesso da função

O RFC 4443 define ICMPv6. Se a origem recebe Parameter Problem, sabe que ao menos um nó não reconheceu a opção. Se não recebe, não sabe que todos reconheceram. A mensagem pode não ser gerada, pode sofrer rate limit ou desaparecer no retorno; o pacote também pode ter sido encaminhado sem processamento.

Router Alert mostra o limite. O RFC 6398 analisa o risco do slow path. RFC 9673 permite essa exceção de control plane com ACL, confiança, rate limiting ou proteção equivalente. O pedido dentro do pacote não é autorização ilimitada de CPU.

Um comprovante melhor associa contador ou trace ao nó, interface, type, build, política e hora. Depois é necessário verificar o efeito. Parsear, agir e beneficiar o serviço são etapas distintas.

O teste de caminho envelhece

RFC 9673 sugere racing com e sem opção, espera por acknowledgement e fallback quando o caminho não suporta a função. Em um limited domain do RFC 8799, o operador pode coordenar os nós. Fora dele, ECMP e reconvergência mudam os participantes.

O registro deve guardar os bytes, a ordem, o tamanho, identificadores do fluxo, rota disponível, timestamps, critério de confirmação, ICMP, telemetria por salto e impacto agregado. Um sucesso antigo descreve uma rota antiga.

O mérito do RFC 9673 é permitir que novas opções sejam simples, curtas, processáveis em alta taxa e tolerantes a nós que as pulem. O serviço que depende delas precisa adotar a mesma honestidade: medir, renovar e recuar sem chamar encaminhamento de execução.

Essa honestidade também melhora a compra: a organização compara limites observáveis, e não promessas que só o fornecedor consegue interpretar.

Fontes