Resumo

  • Publicado na trilha de padrões do IETF em agosto de 2026, o RFC 10038 define a opção DHCPv6 149 para a associação de identidade do Locator SRv6, a opção 150 para cada Locator e o código de status 23 para indisponibilidade.
  • Um Reply bem-sucedido comprova uma alocação segundo a política do servidor em um domínio SR confiável. Configuração do nó, rota local, anúncio IGP, seleção na RIB, gravação na FIB, comportamento SID, filtragem, resultado dos pacotes, retirada e reúso continuam sendo responsabilidades separadas.

Um operador olha para duas telas. A primeira mostra a concessão ativa, com duração válida de uma hora. A segunda mostra tráfego zero. Parece seguro concluir que o Locator não está em uso. Mas a ausência de tráfego pode resultar de uma rota que nunca foi instalada, de um filtro que bloqueou tudo ou de um SID que não existe. O mesmo número operacional sustenta conclusões opostas: implantação incompleta ou serviço ocioso.

É por isso que RFC 10038 precisa ser lido como contrato de alocação, não como atestado de serviço. O documento, publicado em agosto de 2026, distribui por DHCPv6 um SRv6 Locator para um Segment Endpoint Node dentro de um único domínio SR confiável. Um CPE em instalações do cliente pode participar quando é gerenciado como parte desse domínio. As novas designações aparecem no registro de parâmetros DHCPv6 da IANA.

OPTION_IA_SRV6_LOCATOR, código 149, contém IAID, T1, T2 e opções aninhadas. Pode haver várias instâncias na mensagem; seus IAIDs são únicos em um espaço separado das outras associações de identidade. OPTION_IALOCATOR, código 150, fica dentro dela e transporta preferred lifetime, valid lifetime, Algorithm, LB-Len, LN-Len, Fun-Len, Arg-Len, o Locator codificado no tamanho mínimo e outras opções.

LB-Len mais LN-Len é o comprimento do Locator. A soma dos quatro comprimentos não pode exceder 128 e o comprimento do Locator não pode ser zero. Uma opção que viola essas regras é inválida. Essa validação de formato não decide se uma rota existe.

A política fica com quem administra o pool

O cliente normalmente envia T1, T2 e os tempos preferencial e válido como zero. O servidor ignora valores fornecidos pelo cliente nesses campos e determina os relógios. O cliente pode enviar LB-Len e LN-Len não nulos com :: para sugerir um tamanho. A sugestão não obriga o servidor a entregar aquele layout, aquele prefixo ou aquela duração.

O servidor decide, conforme política e configuração, quantos Locators conceder e de qual pool. Pode recusar com NoSRv6LocatorAvail, status 23. O cliente descarta uma entrada se o preferred lifetime superar o valid lifetime. Também não pode converter a ordem dos Locators em prioridade ou significado de serviço.

As regras gerais de RFC 9915 organizam Solicit, Advertise, Request, Reply, Renew, Rebind e Release. Elas criam prova sobre identidade e transação DHCPv6. Não incluem uma confirmação de instalação de rota por parte do IGP.

O Locator também não é um endereço de host comum nem um SID completo. RFC 8402 define a arquitetura Segment Routing; RFC 8986 descreve comportamentos endpoint e a composição de SIDs. A atribuição local de SIDs, o uso de vários Locators e o anúncio de SIDs individuais ficam fora do RFC 10038. O nó receptor preserva sua própria autoridade operacional.

A rede decide de novo em cada plano

O relay ou servidor DHCPv6 pode instalar uma rota local para o Locator, apontando o próximo salto ao solicitante. Pode também anunciar essa rota por um protocolo tradicional. Uma ação não é prova da outra e nenhuma delas está automaticamente concluída pelo Reply.

Depois do anúncio, vizinhos aplicam autenticação e política de importação. O cálculo escolhe caminhos. Cada RIB aceita ou rejeita. A plataforma programa a FIB. A rota pode existir no processo de origem e faltar em equipamentos remotos; pode estar na RIB e não entrar na FIB; pode chegar à FIB com um próximo salto que falha no plano de dados.

Algorithm zero usa alcançabilidade normal de prefixo IPv6. Um Algorithm não nulo deve usar os Locator TLVs indicados pelo RFC 10038. RFC 9350 descreve como Flexible Algorithms carregam restrições de topologia. Retirar o identificador e anunciar apenas o prefixo preserva bits, mas pode destruir a intenção do caminho.

Na extremidade, RFC 8754 rege o Segment Routing Header do IPv6 e RFC 8986 rege os comportamentos. Um pacote entregue ao nó pode não encontrar o SID previsto, acionar outra função ou ser bloqueado por um filtro. O binding responde quem recebeu o espaço; o roteamento responde como o pacote se aproxima; a política local responde o que ele pode fazer.

Recolher o Locator exige retirar a autoridade antiga

Ao processar um Release válido, o relay ou servidor alocador precisa liberar a vinculação, remover sua rota local e retirar a rota antes anunciada. Esses efeitos atravessam bancos, processos, RIBs, FIBs e filas com tempos diferentes. Marcar o item como livre no pool não limpa instantaneamente a rede.

A IA não possui prazo independente: termina quando todos os Locators nela terminam. T1 leva o cliente primeiro ao servidor original; T2 amplia a renovação a um servidor disponível. Os tempos são segundos restantes e 0xffffffff representa infinito. Eles governam a validade administrativa, não observam o último pacote.

Uma rota agregada pode continuar conduzindo tráfego ao ponto de delegação mesmo após a retirada do Locator mais específico. Nesse caso, a borda deve descartar, na interface voltada ao cliente, pacotes destinados a prefixos que deixaram de ser delegados. Sem esse descarte, a cobertura mantém vivo um caminho que o pool já considera encerrado.

O reúso responsável pede quarentena e evidência: binding fechado; rota local removida; anúncio retirado; RIB e FIB conferidas em pontos diversos; SID antigo eliminado; canários permitidos e proibidos com resultado esperado; último pacote conhecido. Só depois o Locator retorna ao pool.

Confiança administrativa não elimina a superfície de ataque

O domínio SR confiável é uma condição de escopo, não criptografia universal de ponta a ponta para DHCPv6. Sem proteção adicional, ainda há risco de sequestro, adulteração e observação. CPEs de fronteira precisam filtrar interfaces internas e externas. O espaço usado por Locators de infraestrutura deve ser distinguível do endereçamento normal dos usuários.

Dois sistemas alocadores podem entregar o mesmo Locator se os pools não forem particionados. Limites por cliente não necessariamente impedem um agente que simula muitas identidades. RFC 7227 e RFC 8168 exigem cuidado com novas opções e semânticas especiais de endereços IPv6; RFC 8987 acrescenta a dimensão operacional da programação SRv6. O registro IANA organiza o protocolo, mas não certifica a exclusividade do pool nem a eficácia dos filtros.

O livro operacional começa no DUID e termina no último pacote

Para cada Locator, registrar DUID, IAID, porta ou contexto do relay, autorização, versão de política, hint e layout concedido, transações, lifetimes, T1/T2, binding, dono do pool, SIDs locais, rota e próximo salto na RIB/FIB de origem, anúncio IGP com Algorithm e versão, observações remotas, filtros, canários, Release ou expiração, retirada, último pacote, quarentena e nova alocação.

A primazia do código em execução de Heng Lu exige essa trilha concreta. A diferença entre soberania técnica e controle prático dos dados mostra por que possuir o banco de bindings não significa controlar as cópias da rota. A ideia de especificação mínima inicial e decisões futuras localizadas descreve a divisão correta: o padrão harmoniza a troca; operadores locais continuam responsáveis por aceitação, encaminhamento e efeito.

RFC 10038 fornece uma boa resposta para “o que foi atribuído?”. A pergunta “o que a rede aceita?” continua exigindo a própria rede.