Resumo

  • RFC 9915 exige recebimento anterior, novo pedido e omissão numa Reply válida a Renew, Rebind ou Information-Request para que a ausência signifique retirada.
  • A Reply demonstra a resposta do servidor e a obrigação do cliente, não a alteração do estado local, o reload dos consumidores ou o fim do uso do destino antigo.
  • IA usa regras próprias e a mesma informação pode chegar por outra fonte, tornando a proveniência parte do teste.

O trio que dá sentido à ausência

Uma captura isolada não basta. O auditor precisa da Reply que forneceu a opção, da mensagem posterior que voltou a pedi-la e da Reply válida e correlacionada que não a incluiu. Sem o pedido, não há base para interpretar o silêncio; sem validação e transação, não há base para atribuir a resposta ao cliente.

Com o trio completo, o cliente SHOULD parar de usar a informação e retornar ao estado padrão pertinente. Isso define o comportamento esperado, mas não relata a execução. O servidor não enxerga se o arquivo foi atualizado, se o daemon releu a configuração nem se uma sessão antiga permaneceu viva.

Uma exceção estreita, um contraexemplo rígido

A persistência só pode ocorrer quando não existe maneira viável de remover o valor, não há outra fonte e não há impacto externo. O hostname configurado por Client FQDN ilustra esse limite; RFC 4704 descreve a opção e a coordenação de DNS.

O endereço de NTP segue regra oposta. Se sumir da Reply qualificada, o cliente MUST parar de usar aquele endereço configurado. RFC 5908 define a localização do servidor de tempo. Tráfego posterior merece investigação, mas a origem atual ainda precisa ser demonstrada.

RFC 9915 permite outras fontes do mesmo dado. RFC 3646 entrega resolvedores por DHCPv6; RFC 8106 entrega RDNSS por Router Advertisement. Um endereço igual pode sobreviver sob outra autoridade. Igualdade de valor não prova continuidade da concessão retirada.

IA e Reconfigure não são atalhos

IA_NA e IA_PD estão fora dessa regra e seguem a seção 18.2.10.1. Reconfigure é um gatilho para Renew, Rebind ou Information-Request, não a configuração resultante. Logar o evento ajuda, mas não prova que a troca terminou, que processos mudaram ou que o serviço respondeu como esperado.

Fechar a retirada com estado e tráfego

O registro deve unir concessão antiga, novo pedido, omissão, mudança local, reload, proveniência de valores sobreviventes e último uso do destino. A RFC prova a semântica de controle; o host prova execução; tráfego e aplicação provam efeito.

RFC 8415 já trazia a substância da regra. RFC 9915 a tornou uma subseção explícita. A nova clareza não deve ser transformada numa afirmação sem evidência sobre implementações existentes.

Fontes