Resumen

  • La RFC 7710 asignó el código 160 de DHCPv4 a la identificación de portales cautivos. En la red de IETF 106, algunos dispositivos Polycom ya usaban ese número para otros fines y no funcionaron como se deseaba al recibir una URL de la API de portal cautivo.
  • La RFC 8910 cambió la función al código 114. IANA mantiene 160 como no asignado, pero conserva la advertencia sobre sus dos historias; una etiqueta de registro no equivale a una prueba de compatibilidad del parque.

El fallo apareció donde debía aparecer

La experiencia de IETF 106 en Singapur no buscaba inspeccionar teléfonos. Su objetivo era permitir que clientes compatibles con la API de portal cautivo descubrieran una venue-info-url. Para DHCPv4, la RFC 7710 había fijado el código 160 en 2015. La red de reunión lo emitió y, con ello, convirtió una suposición de disponibilidad en una prueba contra dispositivos reales.

La respuesta fue negativa. Según el apéndice B de la RFC 8910, algunos dispositivos Polycom presentes usaban 160 con otros propósitos. Al encontrarse en ese campo una URL de la API, no funcionaron como se deseaba. El RFC no revela modelos, versiones, número de unidades, sintaxis alternativa ni síntoma exacto. Esos datos no pueden reconstruirse a partir de la marca del fabricante.

Lo comprobado es bastante importante sin adornos: una asignación reconocida y una convención incorporada en productos coincidieron en el mismo dominio DHCP. El conflicto tuvo una consecuencia observable y la especificación posterior cambió de número. No queda probado que todo equipo Polycom se viera afectado, que el uso continúe hoy o que el proveedor pretendiera apropiarse del espacio.

Erik Kline y Warren Kumari son los autores de la RFC 8910. La anterior RFC 7710 fue obra de Kumari, Olafur Gudmundsson, Paul Ebersman y Steve Sheng. La corrección pertenece a un proceso colectivo. El papel de Kline en esta historia es el de coautor de un documento que no escondió el incidente tras una frase genérica de compatibilidad.

La autoridad normativa y la conducta ejecutable

El código de una opción DHCPv4 ocupa un octeto. IANA ofrece la tabla compartida que permite a servidores y clientes acordar su significado. Esa tabla es indispensable: sin una autoridad común, el espacio escaso se fragmentaría en dialectos privados.

Pero el cliente no interpreta el paquete leyendo la tabla en tiempo real. Un firmware contiene su propia rama: si aparece 160, ejecuta lo que su desarrollador programó. La asignación establece qué interpretación tiene respaldo normativo; no demuestra que todas las demás hayan desaparecido de productos que ya se vendieron.

La diferencia se vuelve visible cuando el contenido también tiene estructura. Para un cliente CAPPORT, una URL es el dato esperado. Para otro parser, esos bytes pueden ser inválidos o activar una lógica distinta. No hace falta atribuirle una intención al equipo para reconocer la colisión. La misma entrada alimenta dos máquinas de estado incompatibles.

La RFC 3679 muestra que el problema era conocido en el gobierno de DHCP. Al recuperar códigos para reasignarlos, distinguió entre propuestas que nunca alcanzaron uso general y valores que debían reservarse porque dispositivos los utilizaban aunque no hubiera una RFC publicada. La disponibilidad administrativa se apoyaba en investigación sobre despliegue, no en ausencia de papel.

El cambio a 114 conserva la historia de 160

La RFC 8910 se publicó en septiembre de 2020, sustituyó a la RFC 7710 y actualizó la RFC 3679. Para DHCPv4, especificó el código 114. El registro BOOTP y DHCP de IANA identifica hoy 114 como DHCP Captive-Portal y enlaza la nueva norma.

El valor 160 figura como Unassigned, pero la descripción añade que antes fue asignado por la RFC 7710 y que también se conoce su uso por Polycom. La palabra no asignado describe quién puede solicitar el número según el registro. La nota histórica impide confundir esa disponibilidad formal con una garantía de que ningún binario responderá a él.

Otros espacios no cambiaron. DHCPv6 conserva el código 103 y la opción de Router Advertisement de IPv6, el 37. Un operador debe decir “la opción de DHCPv4 cambió de 160 a 114”; los tres números no son alias en una sola tabla.

El nuevo código tampoco actualiza el parque. Servidores, relés, sistemas de control de acceso y clientes deben converger. Durante la transición puede haber terminales que comprendan 114, terminales sensibles a 160 y otros que ignoren ambos. Enviar los dos no es una solución neutral, porque vuelve a exponer al grupo que chocaba con 160.

Una migración se verifica en el servicio final

Antes de activar 114 en una red grande conviene clasificar familias de hardware, firmware y función. Después se reproduce el paquete en laboratorio y se pasa a un segmento canario con diversidad deliberada. La observación debe incluir la adquisición y renovación de dirección, pero no terminar allí.

Un teléfono puede recibir una concesión y fallar después al registrar su servicio. Un terminal puede completar DHCP y quedar bloqueado en el arranque. Por eso hacen falta recibos separados del servidor, del camino, del endpoint y de la aplicación. Un contador de ACK verdes solo demuestra una etapa.

La prueba también necesita un interruptor de retirada en el servidor. Si un canario falla, quitar la opción debe ser una operación conocida y rápida. Los equipos sin ruta de actualización pueden requerir un dominio de difusión separado o una política DHCP específica. Esa excepción visible es más honesta que declarar compatible un parque que nadie midió.

Publicar la colisión fortalece el estándar

Podría concluirse que los usos privados ganan por haber llegado primero. Sería la lección equivocada: premiaría la ocupación silenciosa y volvería imposible cualquier registro común. También sería erróneo afirmar que la asignación oficial cambia por sí sola la conducta instalada.

La salida combina autoridad y observación. IANA indica el significado reconocido. Las pruebas delimitadas revelan qué cohortes procesan realmente el código. Cuando ambas evidencias chocan, el grupo puede preservar el objetivo y mover el mecanismo, como ocurrió con 114.

Registrar el resultado negativo evita una repetición. La RFC 8910 se limita al lugar, a “algunos” dispositivos, al efecto general y a la decisión. Esa contención hace el relato más creíble, no menos útil. La advertencia que acompaña a 160 es un recibo de compatibilidad para el próximo diseñador.

Fuentes