Resumo

  • O DHCPv6 Reconfigure não carrega a nova configuração. Ele solicita a um cliente que aderiu ao mecanismo que inicie Renew, Rebind ou Information-request; só a troca seguinte pode produzir o novo estado.
  • Pela RFC 6977, uma Reconfigure-Reply pode trazer Success mesmo quando o servidor não enviará Reconfigure a nenhum cliente solicitado. Processamento, seleção, entrega, autenticação, transação, instalação e serviço exigem provas próprias.

O painel ficou verde antes dos dispositivos mudarem

Um relay de acesso percebe que um dado de provisionamento associado a um link foi alterado. Ele envia ao servidor o endereço do link e uma lista de DUIDs em Reconfigure-Request. A Reconfigure-Reply chega com Success, e o console encerra a atividade.

Ainda assim, nenhum cliente precisa ter mudado. O servidor pode não possuir estado suficiente para alguns DUIDs ou saber que eles nunca anunciaram Reconfigure Accept. Outros estão aguardando o limite de taxa. Uma mensagem enviada pode falhar na autenticação; um Renew pode ter começado sem receber Reply; o cliente DHCP pode até ter instalado um endereço enquanto uma aplicação permanece vinculada ao anterior.

O Success descreve corretamente uma fronteira: o pedido do relay foi processado. Ele se torna enganoso quando é promovido a certificado de execução de uma população que o servidor não observou até o fim.

A RFC 6977 torna essa semântica explícita. A lista de clientes numa resposta bem-sucedida contém aqueles aos quais o servidor não pretende enviar Reconfigure. Todos os clientes solicitados podem aparecer nela e o código ainda ser Success. O protocolo impede que o aceite entre relay e servidor finja ser um recibo do endpoint.

O mecanismo escolhe a próxima conversa

A RFC 9915 é a especificação base atual do DHCPv6, substituindo a RFC 8415. O registro da IANA atribui o valor 10 a RECONFIGURE. Sua função comum é estreita: pedir a um único cliente que volte a conversar com o serviço DHCPv6.

A mensagem é unicast e inclui Server Identifier, o Client Identifier correspondente, autenticação aceitável e Reconfigure Message. Essa opção só pode selecionar Renew, Rebind ou Information-request. Endereços, prefixos e demais opções de configuração não pertencem ao gatilho; entram, se aplicáveis, na Reply posterior.

O servidor tem autoridade para iniciar, não para escrever diretamente o estado do cliente. O cliente valida identidade, autenticação e replay, forma sua requisição e recebe uma decisão nova do servidor. Sua implementação aplica o resultado. A operação observa se o serviço realmente convergiu.

Capturar o Reconfigure prova que um gatilho válido saiu para uma identidade. Não prova que a identidade ainda corresponde ao equipamento no link, que a troca seguinte terminou, que o estado foi instalado ou que a aplicação migrou.

A participação do cliente continua voluntária

Reconfigure Accept é a declaração do cliente de que aceita o mecanismo. Sem ela, o servidor não pode incluí-lo como participante. O cliente continua interoperável por tempos de vida normais, Renew iniciado localmente e Information-request comum.

Essa escolha evita transformar capacidade opcional em obrigação invisível. Também impõe honestidade ao planejamento. Se 70% da frota anuncia a opção, Reconfigure pode acelerar 70%; os demais precisam de tempo, coexistência e observação. Contar apenas participantes não transforma cobertura parcial em cobertura total.

Dispositivos pequenos, como os considerados na RFC 8947, podem limitar recursos de autenticação e persistência. A implementação reduzida altera a velocidade operacional, não a validade do dispositivo como cliente DHCPv6.

Autenticação define o emissor, não o resultado

O Reconfigure Key Authentication Protocol entrega uma chave de 128 bits numa Reply inicial e emprega HMAC-MD5 nas mensagens posteriores. A primeira chave viaja em claro no caminho DHCPv6. Essa exposição é uma fronteira concreta do modelo de ameaça.

O valor de detecção de replay deve crescer monotonicamente e sobreviver ao reinício do servidor. Um nó de failover pode restaurar leases e perder chaves ou contadores, ficando com conhecimento de candidatos sem capacidade de enviar um gatilho que eles aceitem. Replicar segredos aumenta disponibilidade e também o domínio de comprometimento.

A autenticação responde se a mensagem veio da autoridade que detém a chave e se é nova. Ela não responde se o relay escolheu o link certo, se o servidor escolheu o cliente certo, se a Reply seguinte contém estado correto ou se o aplicativo funciona.

Tratar “autenticado” como “correto ponta a ponta” apaga limites que a própria criptografia permite enxergar.

O relay propõe; o servidor mantém a decisão

A RFC 6977 define Reconfigure-Request e Reconfigure-Reply entre relay e servidor. O relay pode indicar o endereço do link e os identificadores que considera afetados. O servidor decide se reconhece o relay, aceita a origem, possui estado bastante, quais clientes são elegíveis e em que ritmo trabalhar.

O padrão é não aceitar esses pedidos. Mensagens de relay desconhecido devem ser descartadas. A RFC 8213 oferece IPsec para proteger o canal relay-servidor, mas um canal íntegro não garante que a população indicada esteja correta. Um relay comprometido pode apresentar os clientes errados por uma sessão perfeitamente protegida.

Durante retransmissões, o relay pode remover clientes, mas não adicionar. A assimetria impede expansão silenciosa do alcance, sem substituir a validação de link, DUID, binding e autoridade.

Em ambientes com mais de um servidor, estados e políticas divergentes podem gerar seleções diferentes. Várias respostas Success não formam consenso sobre o resultado. Cada gatilho precisa ser associado ao servidor emissor, ao cliente e à transação posterior.

Seis registros para uma mudança

Uma trilha operacional confiável separa pelo menos:

  1. a alteração de origem observada e a população proposta pelo relay;
  2. o aceite ou a rejeição do servidor;
  3. a seleção do cliente e a emissão real do Reconfigure;
  4. a autenticação aceita e a requisição subsequente do cliente;
  5. a Reply concluída e processada;
  6. o estado instalado e o caminho de aplicação validado.

Os comprovantes vêm de lugares diferentes: log do relay, Reconfigure-Reply, decisão de seleção, contador de envio, resultado criptográfico, identificador de transação, estado local e teste de serviço. A diferença entre dois estágios localiza o trabalho incompleto.

Success com toda a lista excluída significa processamento correto e cobertura zero. Renew sem Reply significa gatilho efetivo e transação incompleta. Estado DHCP aplicado com aplicação no endereço antigo significa sucesso de configuração e falha de migração. Um único sinal não expressa essas verdades simultâneas.

A fila faz parte da semântica

Um evento pode se abrir em milhares de mensagens individuais e em milhares de novas trocas. A RFC 6977 prevê controle de taxa para preservar atribuição, renovação e recuperação normais. Reconfigure não pode consumir toda a capacidade de DHCPv6.

Aceitar o pedido agora não significa emitir tudo agora. O relógio relevante percorre observação, seleção, fila, envio, requisição do cliente, Reply e instalação. A latência da Reconfigure-Reply cobre somente o início.

Políticas seguras definem máximos por evento de origem, pedido, intervalo do servidor e janela de mudança, além de um limite de repetição. Tentativa infinita converte clientes ausentes em carga permanente e pode ampliar o incidente.

O atraso máximo também precisa caber no período em que a configuração anterior continua segura. Se a fila ultrapassa essa coexistência, um comportamento permitido vira indisponibilidade.

Estado recuperado ainda é uma observação antiga

Leasequery, Bulk Leasequery e Active Leasequery, descritos nas RFCs 5007, 5460 e 7653, ajudam a reconstruir bindings ou mantê-los atualizados. Eles reduzem a incerteza após failover, mas não transformam registro em presença atual.

O cliente restaurado pode ter saído do link. Uma corrente ativa pode atrasar, perder ordem ou precisar de ressincronização. O lease pode sobreviver sem a chave Reconfigure e o contador de replay. Proveniência, idade e completude precisam acompanhar o estado antes de uma ação ampla.

O modelo YANG da RFC 9243 torna a configuração do serviço DHCPv6 mais observável. Ele descreve intenção de controle, não o estado efetivo de cada endpoint. É uma evidência diferente, não um substituto.

Renumeração expõe o custo do atalho

A RFC 6879 descreve redes IPv6 empresariais em renumeração. Reconfigure pode antecipar o retorno de clientes ao servidor, mas não elimina coexistência, equipamentos que não aderiram ou aplicações que conservam endereços anteriores.

Uma transição reversível mantém estados novo e antigo por período declarado, encontra excluídos e atrasados e só retira o antigo depois de observação independente. Encurtar a coexistência porque o diálogo relay-servidor mostrou Success transforma atraso normal, perda ou não participação em interrupção.

Reconfigure é um acelerador opcional dentro do plano, não autorização para corte instantâneo.

O núcleo comum deve permanecer pequeno

A especificação pode definir mensagens, identificadores, opt-in, autenticação, replay e as três trocas permitidas. Ela não conhece o evento comercial, o risco de cada aplicação, a confiança local num relay, a capacidade de um servidor ou a janela segura para retirar estado antigo.

O relay decide o que merece um pedido e propõe candidatos. O servidor decide confiança, reconciliação, seleção e carga. O cliente executa seu código. O operador define proteções, evidências e reversão. A coordenação comum não precisa se transformar num controlador de todas as decisões futuras.

A disciplina de Heng Lu põe running code em primeiro lugar. Registros, recomendações e reconhecimentos descrevem realidade; não a criam. A mudança se torna real quando a implementação executa, os operadores validam e o uso confirma.

Minimum Initial Specification fornece o pequeno gatilho interoperável. Localized Future Decision deixa confiança, seleção, implementação e segurança com os participantes locais. Voluntary Adoption permanece visível na opção que o cliente pode omitir. A norma descreve o convite; sistemas em execução determinam o resultado.

Fontes