Resumo
- A RFC 3736 permite que um nó que já tenha endereço IPv6 peça outros parâmetros por uma troca DHCPv6
Information-request/Reply, sem solicitar que o servidor atribua um endereço. - “Sem estado” significa que o servidor não precisa manter estado dinâmico por cliente para esse serviço; identificação opcional, política local e relay continuam relevantes.
Endereço e resolvedor são trabalhos diferentes
A autoconfiguração IPv6 sem estado pode formar um endereço para o host a partir de anúncios de roteador. Isso não responde a todas as suas necessidades de configuração. Ele ainda pode precisar de endereços de servidores DNS recursivos, de informações sobre servidores SIP ou de outras opções. É tentador imaginar DHCP como um pacote único: pedir um endereço ao servidor e receber junto o restante da configuração de rede.
A RFC 3736 separou essas funções. O cliente já obteve seu endereço por outro mecanismo — normalmente autoconfiguração sem estado ou configuração manual — e tem pelo menos um endereço link-local para se comunicar. Ele envia Information-request com uma opção de solicitação que indica os tipos de opções desejados. O servidor responde com Reply e os parâmetros que selecionou. Nesse modo, o cliente não pede uma associação de identidade de endereço e o servidor não atribui um endereço.
A troca foi reduzida deliberadamente a duas mensagens: Information-request e depois Reply. O host pode pedir configuração de DNS sem transformar essa interação em uma concessão de endereço. O mesmo sistema de servidores pode atender clientes que pedem endereços e outros que precisam somente de parâmetros adicionais; os agentes relay operam como no DHCP com estado.
Mas “sem estado” não significa que o servidor não tenha configuração ou política. A RFC 3736 diz que ele não precisa manter estado dinâmico sobre cada cliente. Ela também permite incluir um Client Identifier quando o administrador quer personalizar a resposta para um nó. O servidor ainda escolhe opções segundo sua política de configuração, e um relay ainda pode encaminhar mensagens. O limite é mais estreito: esse serviço de informação não precisa criar nem acompanhar uma associação de endereço por cliente.
Essa diferença ajuda a interpretar as flags dos anúncios de roteador IPv6. Na RFC 4861, a flag Managed sinaliza que endereços estão disponíveis pelo DHCPv6; Other indica que há outras informações, como DNS, disponíveis pelo DHCPv6. Quando Managed está ativa, Other é redundante. São sinais de disponibilidade, não provas de que o host concluiu a troca DHCP, instalou um resolvedor ou consegue alcançá-lo.
Ao retirar a concessão de endereço, retirou-se também seu relógio
Endereços atribuídos têm tempos de vida que indicam quando são preferenciais, válidos ou deixam de poder ser usados. Outros parâmetros podem não ter prazo semelhante. A RFC 3736 deixou explicitamente em aberto quando o host deveria enviar outro Information-request para atualizar esses valores; também não definiu uma regra para a atualização após a mudança de enlace.
A RFC 4242 acrescentou depois a opção Information Refresh Time, que estabelece um limite superior para o tempo até o cliente solicitar informações DHCPv6 atualizadas. A justificativa é importante. Se a troca não inclui uma concessão de endereço ou prefixo, talvez não haja um tempo de vida que avise ao cliente quando voltar. Mais tarde, a RFC 8415 consolidou o DHCPv6, tornou obsoletas as RFCs 3736 e 4242 e preservou a operação de informação em duas mensagens.
A história, portanto, não é “o DHCP desapareceu quando a SLAAC produziu um endereço”. Formação de endereço e demais parâmetros do host podiam ser separados. Isso reduziu o estado por cliente necessário ao servidor de informação, mas a configuração ainda precisava tratar precedência das fontes, renovação, escopo por interface e instalação do resolvedor no host. Um Reply mostra que o protocolo devolveu opções; sozinho, não demonstra que o host as instalou ou que uma consulta DNS funcionou.
Essas RFCs não mostram com que frequência clientes atuais usam esse modo nem como uma rede específica o configura. Elas especificam o mecanismo e seus limites, não sua prevalência ou o resultado do serviço.
Fontes
- RFC 3736 — Stateless DHCP Service for IPv6 e registro do RFC Editor
- RFC 4242 — Information Refresh Time Option for DHCPv6 e registro do RFC Editor
- RFC 4861 — Neighbor Discovery for IPv6; RFC 4862 — IPv6 Stateless Address Autoconfiguration
- RFC 8415 — Dynamic Host Configuration Protocol for IPv6 e registro do RFC Editor
Briefing para membros
Contexto aprofundado do perfil
Faça login com o nível de assinatura correto para desbloquear o briefing completo e as notas das fontes.
Apenas para Strategic Circle
Strategic Circle
Aberto a todos os leitores. Desbloqueie Briefings de perfil após se inscrever e fazer login.
Junte-se ao Strategic CircleSomente para Leadership Alliance
Leadership Alliance
Para proprietários e gestores qualificados de ativos de PI; faça login para desbloquear os briefings da Leadership Alliance.
Junte-se ao Leadership Alliance
