Resumo

  • A RFC 10038 permite que um endpoint SRv6 obtenha pelo DHCPv6 um locator estruturado, com tempos de vida, algoritmo e campos do layout.
  • Como a alocação pode criar e anunciar uma rota do localizador, renovação, liberação e expiração tornam-se eventos de estado de roteamento, não simples manutenção de endereços.

O lease por trás do SID

No SRv6, o locator tem função estrutural. Ele identifica o espaço de endereços do qual o nó aloca Segment Identifiers e, portanto, determina mais do que a forma de chegar a uma interface. A RFC 10038 transporta essa estrutura em duas novas opções DHCPv6. O IA Locator contém os tempos de vida preferencial e válido, um valor de IGP Algorithm, os comprimentos das partes de bloco e nó, os comprimentos de Function e Argument e os próprios bytes do locator.

Esses campos colocam uma decisão na fronteira de alocação. O cliente pode indicar uma preferência, mas é o servidor que procura em seu pool configurado e cria o vínculo conforme sua política. A soma dos comprimentos estruturais não pode superar 128 bits, e a soma do bloco com a parte de nó não pode ser zero. O cliente precisa descartar um localizador cujo tempo preferencial supere o válido. São fatos do protocolo, não evidência de que um produto específico faça todas as validações corretamente.

A IANA atribuiu os códigos de opção 149 e 150 e o código de status 23, NoSRv6LocatorAvail. Uma resposta negativa é, portanto, um resultado definido, não uma autorização para inventar um localizador localmente. A especificação não prescreve o desenho do pool nem decide qual organização pode aprovar uma alocação.

Uma transição de lease pode virar uma transição de rota

O ciclo acompanha o DHCPv6: Solicit, Advertise, Request e Reply estabelecem o vínculo; Renew e Rebind tentam preservá-lo; Release o devolve. Se a renovação atravessar o temporizador relevante sem resposta, o cliente considera o lease expirado e recomeça. Em uma liberação válida ou na expiração, o servidor recupera o locator.

A RFC 10038 então entra no roteamento. Um servidor ou relay pode instalar uma rota local para o localizador atribuído, usando o cliente solicitante como próximo salto, e anunciá-la por um IGP. A liberação exige remover essa rota e retirar o anúncio anterior. Localizadores de Algorithm zero podem usar alcançabilidade IP comum; valores diferentes de zero exigem os TLVs de localizador definidos para IS-IS ou OSPFv3.

A inferência operacional é que o registro da concessão, a entrada na RIB e o anúncio IGP representam uma mesma decisão de autoridade. Ainda assim, podem divergir na implementação. Uma resposta DHCP bem-sucedida não prova que a rota foi instalada, propagada, programada no encaminhamento ou funciona de ponta a ponta. Da mesma forma, uma rota remanescente após o fim do vínculo preservaria aparência de alcançabilidade depois de encerrada a autoridade de alocação. Não se afirma que qualquer dessas falhas ocorreu em uma rede identificada.

A agregação muda o formato da falha

A RFC 10038 registra uma troca ligada à estabilidade. Anunciar agregados pode reduzir alterações na RIB quando concessões individuais mudam. Porém, um localizador específico retirado pode continuar coberto pelo agregado; o tráfego para um prefixo que já não foi delegado à interface do cliente pode ser descartado ali. O agregado conserva alcançabilidade grosseira enquanto a autoridade específica desapareceu.

Isso importa para o monitoramento. Tratar o agregado como prova de que todo localizador sob ele continua válido confundiria um resumo de roteamento com o estado das concessões. O operador precisa das duas visões: a política de agregação que protege a RIB e o vínculo individual que explica se um localizador ainda deve terminar em determinado endpoint.

Segurança começa por quem pode alocar

A RFC 10038 herda as considerações de segurança do DHCP e destaca a ausência de criptografia ponta a ponta entre clientes e servidores DHCP. Sem outras proteções, há possibilidade de sequestro, adulteração e escuta. Também alerta que mecanismos mistos podem atribuir o mesmo localizador a mais de um dispositivo. Separar os pools por mecanismo é uma mitigação.

O padrão não transforma uma troca DHCP em prova de autorização organizacional. Essa prova continua local: quais servidor e relay eram confiáveis, qual identidade de cliente foi admitida, quais pool e algoritmo foram aprovados e qual registro de mudança explica o vínculo. Validade do protocolo e autoridade de negócio são evidências distintas.

Fontes