Resumo

  • A RFC 3315 permitiu que o cliente DHCPv6 pedisse a troca Solicit–Reply em lugar de Solicit–Advertise–Request–Reply; o servidor ainda podia recusar o atalho conforme sua própria política e configuração.
  • No Rapid Commit, o servidor confirmava a alocação antes de enviar Reply. Mais de um servidor podia reservar endereços embora o cliente usasse os leases de apenas um; uma resposta perdida também separava a reserva registrada do que o cliente recebeu.

Na troca tradicional de quatro mensagens, o intervalo entre descoberta e confirmação tem uma função. O cliente envia Solicit, recebe Advertise dos servidores disponíveis, escolhe um e manda Request. Só então chega Reply com a alocação confirmada. Publicada em julho de 2003, a RFC 3315 definiu DHCP para IPv6 e também abriu uma opção para reduzir esse percurso quando a configuração precisava acontecer mais depressa.

O cliente incluía em Solicit a opção Rapid Commit, de comprimento zero, para indicar que aceitava uma Reply imediata. Essa sinalização não obrigava ninguém a alocar. Cada servidor continuava sujeito à política administrativa e à própria configuração: se não estivesse preparado para confirmar recursos nesse caminho, poderia ignorar a opção e enviar Advertise. O cliente então seguiria pela seleção convencional. Ao aceitar Rapid Commit, o servidor comprometia os endereços antes de transmitir Reply.

O benefício era claro para o cliente que recebesse uma Reply válida com a opção: poderia usar a configuração sem enviar Request. Mas o servidor não receberia uma confirmação posterior de que a resposta chegou ao cliente. A própria RFC 3315 chama atenção para o caso de várias respostas ao mesmo Solicit: cada servidor pode comprometer seus endereços, enquanto o cliente usa os leases de apenas um deles. Os outros ficam comprometidos sem uso. Se Reply se perder no caminho, pode existir uma reserva no servidor sem que o cliente tenha recebido a informação necessária para usá-la.

Por isso, menos mensagens não significam apenas menor demora; a fronteira de compromisso muda de lugar. No fluxo normal, o cliente vê as ofertas e escolhe antes da confirmação definitiva. Com Rapid Commit, a alocação é antecipada e a incerteza passa a pesar mais sobre os pools e a coordenação entre servidores. A especificação sugere organizar o serviço para que normalmente só um servidor responda ou usar leases iniciais mais curtos, reduzindo alocações ociosas. São medidas de projeto, não uma garantia de topologia única nem evidência de que todo lease extra provoque conflito.

Em 2005, a RFC 4039 levou uma opção Rapid Commit ao DHCPv4, destacando ambientes de alta mobilidade em que o ponto de conexão muda com frequência. Ela também explicou o valor do caminho de quatro mensagens: as ofertas de servidores redundantes podem continuar provisórias enquanto o cliente escolhe. Essa genealogia registra uma compensação de projeto, não uma medida de adoção universal ou do tempo real de inicialização.

A RFC 8415 consolidou o DHCPv6 em 2018. Em janeiro de 2026, a RFC 9915 substituiu a RFC 8415 e preservou a mesma decisão: o cliente pode pedir o caminho acelerado, mas o servidor só o completa se estiver configurado para comprometer os recursos. O aviso sobre leases confirmados e não usados também permanece. O legado da Rapid Commit está em uma pergunta operacional: quando a rede considera que um recurso foi alocado e que evidência prova que ele chegou ao cliente? Remover um ciclo também remove uma oportunidade de escolha e confirmação.

Fontes: RFC 3315, RFC 4039, RFC 8415 e RFC 9915.