Resumen

  • RFC 3679 separó los números de opción propuestos que podían recuperarse de los códigos PXE y Apple ya usados, aunque sin descripción en un RFC publicado.
  • RFC 3942 estableció una transición para códigos de la zona privada. Más tarde, RFC 8910 trasladó la señalización de portales cautivos desde el código 160 tras un ensayo que reveló un uso concurrente de Polycom. El registro refleja coordinación, no un censo de dispositivos desplegados.

Una bibliografía vacía no era una red vacía

DHCP transporta pequeños parámetros durante la configuración de una dirección: la máscara de subred, la dirección del router y otros datos de servicio. Los números de opción pertenecen a un espacio compartido. Si una propuesta abandonada conserva su número para siempre, queda menos espacio para trabajos posteriores; si se reasigna un código realmente desplegado, dos equipos pueden interpretar de forma distinta el mismo campo.

En enero de 2004, RFC 3679 abordó ambos riesgos. Enumeró asignaciones anteriores cuyas propuestas habían vencido, nunca habían llegado a una definición publicada o ya no se usaban en el protocolo de redundancia de la época. Esos códigos podían volver al conjunto disponible de la IANA. Pero otra sección indicó que las opciones PXE 93, 94 y 97 se utilizaban ampliamente pese a no aparecer en un RFC publicado. También señaló usos de Apple para los códigos 95 y 112–114 sin documentación RFC. El documento pidió conservar sus asignaciones mientras el grupo de trabajo DHC decidía qué hacer. La evidencia decisiva no era solo la publicación: era el uso reportado. RFC 3679

La distinción no afirmaba que todo uso sin documentación mereciera un número público permanente. RFC 3679 expuso las razones de recuperación código por código y trató por separado los casos conocidos de PXE y Apple. Indicó que los códigos recuperables volvieran al conjunto disponible después de los nunca asignados o ya devueltos. Era un memorando informativo, no una prueba de que cada implementación mencionada siguiera existiendo ni de que todas las asignaciones estuvieran resueltas en las redes. Estado de RFC 3679

De una lista a una transición

Más tarde, en 2004, RFC 3942 amplió el espacio de opciones DHCPv4 definidas públicamente de 1–127 a 1–223 al reclasificar el tramo superior, reservado hasta entonces para uso privado. El cambio no podía borrar las configuraciones locales existentes. Por eso el estándar estableció una transición: un código privado con uso conocido podía quedar como no disponible mientras los proveedores avisaban al grupo de trabajo y a la IANA; una asignación pública provisional tenía un plazo de notificación de seis meses y otro de dieciocho meses para presentar un Internet-Draft. Se pidió a los sitios migrar al resto del rango privado. RFC 3942

La regla ante una colisión era más estricta. Si varios proveedores demostraban un uso razonablemente extendido del mismo número, ninguno podía conservarlo como código privado propio; cada cual debía solicitar una asignación pública normal. No se declaraba ilegítimo el uso privado. Se reconocía que un número no puede coordinar dos significados incompatibles solo porque cada proveedor lo usara localmente. RFC 3942 también descartó una extensión de 16 bits, costosa para los primeros adoptantes, y un formato o cookie mágica nuevos, que aumentarían los costes de compatibilidad y descubrimiento.

El conflicto posterior que volvió concreta la diferencia

RFC 4578 describió después las opciones PXE 93, 94 y 97 como ampliamente utilizadas, pero señaló también que clientes PXE solicitaban los códigos 128–135, que no estaban asignados oficialmente para PXE y podían entrar en conflicto con otros usos dentro de la misma red. La distinción es importante: que un cliente solicite un código no lo convierte en una asignación oficial.

Un caso aún más explícito surgió con los portales cautivos. RFC 7710 usó inicialmente la opción DHCPv4 160 para anunciar la URI del portal. Durante un ensayo en la red de IETF 106, algunos dispositivos Polycom utilizaban 160 para otros fines; al llevar allí la URI del portal, no funcionaron como se esperaba. RFC 8910 trasladó la señal a la opción 114, actualizó RFC 3679 y devolvió 160 a «no asignado», dejando constancia del uso conocido de Polycom. Los autores describen un conflicto observado en ese ensayo, no su prevalencia en todas las redes. RFC 7710 RFC 8910

El registro actual de la IANA muestra la trayectoria de varios códigos: el 83 pasó a iSNS; el 88 y el 89, a opciones BCMCS; el 114 es de portal cautivo, y el 96 sigue sin asignar. Los códigos 126 y 127 también figuran sin asignación. Estos estados del registro no demuestran que ningún equipo en redes activas emita esos valores. Una asignación posterior tampoco demuestra que hayan desaparecido todas las implementaciones anteriores. Registro IANA BOOTP/DHCP RFC 4174 RFC 4280

La posterior Nota 72 de Lu Heng ofrece un eco conceptual acotado: un registro de coordinación y la realidad operativa son tipos distintos de evidencia. La nota trata la unicidad de los números de Internet, no la asignación de opciones DHCP, y no causó ni respaldó estas decisiones. La enseñanza práctica procede de los propios RFC: recuperar un número requiere averiguar si se usa, y reasignarlo es un proceso de transición, no una corrección administrativa. Nota 72

Fuentes

Contexto normativo complementario