Resumo

  • A RFC 7710 reservou a opção DHCPv4 160 para identificação de portal cativo. Na rede da IETF 106, alguns dispositivos Polycom já usavam o mesmo código para outros fins e não funcionaram como desejado diante da URL padronizada.
  • A RFC 8910 passou a função para 114. O registro da IANA marca 160 como não alocado, mas mantém o aviso sobre a atribuição anterior e o uso Polycom; a situação formal não apaga o comportamento instalado.

O teste encontrou uma segunda gramática

Na IETF 106, em Singapura, uma experiência de rede permitia que clientes compatíveis com a API de portal cativo descobrissem uma venue-info-url. A opção usada no DHCPv4 tinha respaldo: a RFC 7710, de 2015, designava o código 160 para a finalidade de portal cativo.

O pacote, porém, entrou em uma rede com dispositivos que não partilhavam essa gramática. O apêndice B da RFC 8910 relata que alguns equipamentos Polycom empregavam 160 para outros propósitos. Ao receber uma URL da API nesse campo, eles não funcionaram como desejado.

Não há no texto modelo, versão de firmware, quantidade, formato alternativo ou descrição do defeito. O nome do fabricante não autoriza completar essas lacunas. A evidência sustenta uma afirmação menor e sólida: existia uso conflitante no ambiente observado, a incompatibilidade foi material e o padrão mudou por causa dela.

Erik Kline assina a RFC 8910 com Warren Kumari. A RFC 7710 anterior tem Kumari, Olafur Gudmundsson, Paul Ebersman e Steve Sheng como autores. Assim, a correção não deve ser narrada como gesto individual. O valor do trabalho de Kline está na coautoria de uma revisão que registrou o dado negativo com limites claros.

O número chega antes da tabela

Uma opção DHCPv4 carrega um código de um octeto. A tabela da IANA organiza esse espaço e dá aos implementadores um significado comum. Ela decide qual uso tem reconhecimento normativo. Sem essa autoridade, servidores e clientes não teriam base compartilhada.

Só que um endpoint não consulta a tabela ao receber cada OFFER ou ACK. Ele executa código compilado. Se um produto foi programado para tratar 160 de outra maneira, a nova atribuição não reescreve o binário. O padrão pode estar correto e o parque, ainda assim, conter uma colisão.

É uma diferença entre duas perguntas. “Quem tem o significado oficial?” é respondida pelo registro. “Que rotinas serão acionadas neste segmento?” exige inventário e teste. Misturar as respostas faz uma convenção normativa parecer uma garantia empírica.

A RFC 3679 já aplicava esse raciocínio à recuperação de opções DHCP. Alguns códigos podiam voltar à fila porque seus projetos nunca viraram padrão ou uso geral. Outros deveriam ficar reservados por aparecerem em equipamentos, mesmo sem RFC publicada. Ausência de documentação não era equivalente a ausência de implantação.

114 é o destino; 160 continua com passado

Publicada em setembro de 2020, a RFC 8910 substituiu a RFC 7710 e atualizou a RFC 3679. Para DHCPv4, ela escolheu 114. O cadastro BOOTP e DHCP atual da IANA associa 114 a DHCP Captive-Portal e referencia a RFC 8910.

O código 160 aparece como Unassigned. Logo abaixo do rótulo, a descrição preserva que ele foi antes atribuído pela RFC 7710 e que também é conhecido pelo uso da Polycom. Não alocado significa que o registro não mantém hoje uma função padronizada naquele valor. Não significa que todos os firmwares deixaram de reagir a ele.

O evento não renumerou os outros espaços. A opção de portal cativo do DHCPv6 continua 103; a opção de Router Advertisement IPv6 continua 37. A migração 160→114 é específica de DHCPv4. Confundir esses códigos esconderia a separação que permite administrá-los.

Também não basta trocar a documentação. Servidores precisam emitir 114, clientes precisam entendê-lo e os intermediários precisam preservá-lo. Por um período, a rede terá grupos que reconhecem 114, grupos sensíveis a 160 e grupos indiferentes aos dois. Enviar ambos pode reabrir o dano; enviar só 114 pode deixar clientes antigos sem a melhoria de descoberta.

Compatibilidade termina na função do equipamento

O ensaio adequado começa com famílias de hardware e firmware, não com um total bruto de leases. Em laboratório, o operador reproduz código, comprimento e carga útil. Em seguida, usa um segmento canário com variedade conhecida e compara a linha de base.

Aquisição de endereço e renovação são apenas os primeiros marcos. Também importam inicialização, registro de serviço, conectividade e a tarefa para a qual o aparelho existe. Um equipamento pode concluir DHCP e falhar depois. Um painel que mostra apenas ACKs positivos não enxergará esse custo.

O rollback deve estar do lado do servidor e ser exercitado antes da expansão. Remover a opção precisa ser simples e auditável. Se uma família legada não tem atualização, separar seu segmento ou aplicar uma política específica pode ser a escolha mais barata. A exceção declarada é preferível a uma compatibilidade presumida.

Uma colisão publicada vale mais que um silêncio elegante

O uso privado não ganha legitimidade apenas por estar embarcado. Aceitar essa tese destruiria a coordenação do registro. Por outro lado, uma resolução normativa não obriga silício e firmware a esquecerem uma interpretação anterior.

O caso mostra uma saída adulta. O registro mantém a autoridade; o teste de campo verifica o pressuposto de disponibilidade; o padrão troca o mecanismo quando a evidência demonstra um custo real. A comunidade não abandona a função de portal cativo, apenas lhe dá um código menos conflituoso.

A RFC 8910 relata o suficiente para orientar sem exagerar. Diz onde ocorreu, limita-se a alguns dispositivos, descreve o resultado geral e documenta a decisão. Essa disciplina protege o fornecedor de uma acusação não provada e protege o próximo implementador do mesmo choque.

Fontes