Resumo

  • Publicado em 7 de setembro de 2026, draft-ietf-spring-sid-as-source-address-00 passou a ser documento do grupo SPRING. A adoção cria uma frente de trabalho; não cria uma RFC nem valida a implementação declarada.
  • O mecanismo troca o loopback do PE de ingresso pelo SID do serviço no campo de origem IPv6 externo. Assim, a relação de endereços se inverte de modo que um firewall stateful consiga associar as duas direções.
  • O acerto da tabela prova uma associação sob a política vigente, não a identidade do emissor. O draft alerta para perda de rastreabilidade, spoofing interno de SID e pressão sobre o estado do firewall.

No encapsulamento usual, o PE de ingresso usa o próprio loopback como origem externa. O serviço VPN no PE oposto aparece como destino final, diretamente no endereço IPv6 em best effort ou na última entrada do SRH quando existe uma política de segmentos. Um firewall que entende SRv6 recupera esse destino e monta uma chave de três ou cinco campos.

Na resposta, o outro PE usa outro loopback, e o SID de serviço do primeiro lado vira destino. Os dois pares externos não são inversos. Se o firewall exige que a origem do retorno corresponda ao destino da ida, ele pode tratar a resposta como conexão estranha. Rota, encapsulamento e aplicação podem estar corretos; ainda assim o retorno ou o ICMP é descartado.

A proposta muda a semântica da origem. O PE identifica o L3 VPN e escolhe o SID que o egress espera para aquele fluxo. Esse SID vai para a origem externa, e o par faz o mesmo no sentido contrário. Em posição de origem, o SID é tratado como IPv6 comum e não executa o comportamento de endpoint. Para a tabela, surge a simetria que faltava.

O que desaparece é a equivalência simples entre origem externa e PE. O novo valor é um classificador de serviço escolhido pelo roteador. O firewall pode afirmar que o pacote correspondeu a uma sessão existente segundo seu parser e suas regras. Não pode deduzir, sem outras provas, qual caixa emitiu, qual cliente provocou, quem autorizou o uso do SID ou se um nó interno imitou o valor.

A granularidade distribui custo e visibilidade. Um SID por VRF não pede lookup adicional, mas todos os CEs daquela VRF podem parecer uma única origem. Um SID por circuito de acesso mantém distinção por AC sem nova consulta. Um SID por prefixo separa mais, porém exige lookup da origem do pacote do cliente dentro da VRF e pode afetar encaminhamento. A preferência por prefixo, depois AC e por fim VPN/VRF é tanto regra de seleção quanto escala de atribuição.

O capítulo de segurança impede que a simetria vire confiança automática. Prefixos de locator costumam ser roteáveis dentro do domínio; um nó interno pode tentar forjar uma origem sob o SID de outro serviço e atravessar políticas ingênuas. SIDs programáveis e voláteis também podem acelerar criação e envelhecimento, consumir a tabela e causar overflow. O draft exige controle estrito sobre quais fluxos podem usar SID como origem. Origem autorizada, antisspoofing, ciclo de vida e orçamento de sessões continuam fora do simples rewrite.

ICMP produz evidência de outra espécie. Um ping SRv6 pode usar End SID como origem externa para testar o retorno. Um nó de trânsito pode responder com o SID cujo processamento falhou, apontando um segmento e um local. Em um erro provocado por VPN, o ingresso ainda precisa examinar o cabeçalho superior embutido, conforme RFC 8986, para entregar o ICMP interno ao CE. Apontar o local não autentica o mensageiro nem fecha a causa raiz.

A compressão também pode quebrar a leitura. RFC 9800 admite casos em que o último item do cabeçalho não é o endereço recebido pelo destino final e listas comprimidas sem SRH. O novo draft recomenda manter o destino final sem compressão como último elemento do SRH. Se o firewall não reconstruir a mesma semântica nos dois sentidos, a seleção correta de origem nos PEs não basta.

Há ainda uma declaração de código existente. New H3C informa que CR16000 e CR19000, na versão 7.1.119 ou superior, implementam todas as seções e classifica a maturidade como produção. A ficha ainda menciona o Draft-13 anterior e não relata experiência específica. Pelo enquadramento de RFC 7942, o próprio texto ressalva que a IETF não verificou a informação do colaborador nem endossa o produto. É um dado útil sobre implementação declarada, não teste independente, interoperabilidade ou adoção.

O método de Heng Lu serve justamente para não somar autoridades. A adoção pelo grupo é coordenação; a regra do PE é configuração; pacote e linha da tabela são observação; entrega e atribuição são resultado. Cada realidade precisa do próprio recibo.

A notícia é que SPRING assumiu como trabalho comum uma troca explícita: reduzir falsos bloqueios usando o campo de origem para representar serviço. O registro operacional completo deve juntar geração do SID, PEs autorizados, granularidade efetiva, parser, sessão, pacote e entrega ao cliente. “O retorno casou” é uma conclusão defensável. “Sabemos quem enviou” ainda precisa ser demonstrado.

Fontes

  1. IETF Datatracker — SID as source address in SRv6
  2. Draft de grupo 00
  3. Datatracker — draft anterior
  4. Revisão 13 do draft anterior
  5. SRv6 Security Considerations, revisão 16
  6. RFC 8402 — Arquitetura de Segment Routing
  7. RFC 8754 — Cabeçalho SRH de IPv6
  8. RFC 8986 — Programação de rede SRv6
  9. RFC 9252 — Serviços BGP overlay sobre SRv6
  10. RFC 9259 — OAM em SRv6
  11. RFC 9800 — Listas comprimidas de segmentos SRv6
  12. RFC 7942 — Seções de estado de implementação
  13. Heng Lu — Running-Code Primacy
  14. Heng Lu — Minimum Initial Specification
  15. Heng Lu — Reality Layers