Resumen

  • DHCP puede utilizar file y sname como espacio para opciones cuando la opción 52 lo declara. La función de un campo no se deduce solo de su nombre histórico.
  • Las opciones 66 y 67 permiten representar la información de servidor TFTP y archivo de arranque que abandona sus posiciones fijas. Cambiarla de sitio no equivale a eliminarla.
  • RFC 3396 distingue espacio disponible y longitud de un valor. Sus fragmentos se reúnen en el orden lógico options, file, sname, respetando los límites físicos y las capacidades del receptor.

La ausencia estaba en el lugar equivocado

Un programa que busca un nombre de archivo en una posición fija puede concluir que no se ha proporcionado ninguno. Pero esa conclusión deja de ser válida si el protocolo permite que la información viaje de otra forma. El dato puede seguir ahí; lo que ha quedado obsoleto es la búsqueda.

En marzo de 1997, RFC 2132 describía la opción 67 para identificar un archivo de arranque cuando el campo file se utilizaba para opciones DHCP. La opción 66 cumplía una función equivalente para el nombre del servidor TFTP cuando sname había cambiado de uso.

Esta posibilidad muestra el diseño desde el lado del significado. Un espacio reservado originalmente para un nombre podía prestarse a otras necesidades, mientras el nombre pasaba a ser un parámetro con etiqueta. No hacía falta interpretar la reutilización como pérdida de información.

Sin embargo, el receptor debía saber cuándo se había producido el cambio. No podía decidirlo porque los bytes parecieran extraños, ni porque esperaba encontrar texto y no lo encontraba. La transformación necesitaba una declaración que ambas partes supieran localizar.

La distribución original respondía al arranque

El BOOTP de RFC 951, publicado en septiembre de 1985, ayudaba a una máquina a obtener dirección, servidor y archivo antes de disponer de todo su entorno operativo. Su formato reservaba posiciones estables para esas necesidades.

sname tenía 64 bytes para un nombre de servidor opcional. file tenía 128 para el nombre del archivo de arranque. Ambos eran cadenas terminadas en cero. Una zona vend de 64 bytes admitía información específica del proveedor.

No eran huecos sin propósito. La facilidad de encontrar los nombres en un programa de arranque pequeño justificaba su posición fija. Cuando DHCP amplió las tareas de configuración, conservó esa estructura en vez de desplazar todos los campos.

RFC 2131, de marzo de 1997, mantuvo las dimensiones de sname y file, pero hizo variable la zona options. Un cliente debía poder recibir al menos 312 octetos en esa zona; negociar mensajes mayores era una posibilidad distinta. El límite de 255 bytes de datos de una instancia de opción no era el límite de todo el mensaje DHCP.

El permiso para reutilizar ya existía en 1993

RFC 1533, de octubre de 1993, definía Option Overload antes de esas revisiones. La opción 52 tiene un byte de datos: 1 selecciona file, 2 selecciona sname y 3 indica ambos.

El valor declara qué campos del mensaje actual contienen opciones. No autoriza a interpretar cualquier área desconocida ni cambia de manera permanente todos los mensajes posteriores. Un campo no seleccionado conserva su papel y no debe incorporarse al conjunto por conveniencia del analizador.

RFC 2131 exige que la declaración esté en la zona ordinaria de opciones. El receptor debe leer primero esa zona y, si corresponde, continuar por file y después por sname. La información que cambia una interpretación se encuentra, por tanto, en un lugar cuya interpretación ya estaba acordada.

La alternativa sería circular: para saber si un campo contiene opciones habría que leer una opción escondida en ese mismo campo. La declaración externa evita esa adivinación y convierte una decisión de empaquetado del emisor en una condición verificable por el receptor.

El espacio prestado sigue teniendo bordes

La zona normal de opciones comienza con un magic cookie de cuatro octetos. Después aparecen los elementos etiquetados. En una opción variable habitual hay un código, un byte de longitud y los datos indicados; la longitud no cuenta el código ni su propio byte. Pad y End son excepciones de un solo octeto.

En file o sname reutilizado, la primera opción empieza en el primer byte del campo. No se introduce otro cookie. Cada campo usado termina sus opciones con End y rellena el resto con Pad. Ninguna instancia codificada puede atravesar el límite entre campos.

La regla importa incluso si queda espacio al otro lado. No se puede continuar físicamente un elemento como si las divisiones no existieran. Tampoco debe interpretarse el End de un campo como desaparición de todos los demás campos declarados: es un final local dentro de una secuencia de lectura más amplia.

Las dos zonas aportan 192 bytes brutos de capacidad, pero no 192 bytes útiles garantizados. Códigos, longitudes, terminaciones, relleno, declaración e información desplazada consumen parte de ella. Se aprovecha un espacio acotado; no se crea un mensaje infinito ni una nueva forma de fragmentación IP.

El registro de opciones no es un registro de archivos

El registro BOOTP/DHCP de IANA mantiene los códigos 52, 66 y 67, además del 119 para búsqueda de dominios. Permite reconocer la clase de parámetro que se transmite, no decidir si el contenido es correcto para una máquina concreta.

Un nombre en la opción 67 no garantiza que exista un archivo accesible, que termine una transferencia o que se deba ejecutar su contenido. Y el número de opción 67 no debe confundirse con el puerto UDP del servidor DHCP que utiliza casualmente el mismo número. Código de parámetro y punto de transporte pertenecen a espacios distintos.

Esta separación impide que una herramienta convierta un detalle de representación en una afirmación operativa excesiva. La información puede cambiar de sitio sin desaparecer, pero su presencia tampoco equivale a un arranque satisfactorio.

Un valor pequeño puede necesitar fragmentos

El préstamo de campos no resuelve todas las limitaciones de longitud. Una instancia convencional de opción solo puede declarar hasta 255 bytes de datos. Un valor mayor necesita varias instancias aunque el mensaje tenga capacidad total suficiente.

También puede ocurrir algo menos evidente: el valor completo es corto, pero no cabe en el espacio que queda en el campo actual y otra zona disponible tiene sitio para el resto. La necesidad nace de la distribución del espacio, no del tamaño absoluto del parámetro.

RFC 3396, de Ted Lemon y Stuart Cheshire, aclaró ambos casos en noviembre de 2002. Eliminó explícitamente la frase de RFC 2131 que restringía por defecto la repetición de opciones y definió cómo dividirlas y concatenarlas.

Cada porción conserva el mismo código de opción y lleva su propia longitud. La suma de las longitudes de datos corresponde al valor lógico completo. El receptor une los datos, no las cabeceras, y no debe elegir solo la primera o la última aparición ni tratar cada parte como un objeto independiente.

El ejemplo del RFC usa /diskless/foo, trece bytes divididos en siete y seis. El corte cae dentro de diskless. No representa dos nombres ni sigue una frontera de significado: el emisor puede cortar en cualquier límite de octeto, y el receptor tiene que recomponer antes de interpretar.

La secuencia correcta no coincide con la disposición

En el paquete heredado, sname precede a file y ambos aparecen antes de options. Pero el conjunto lógico definido para la concatenación recorre options, file y sname, en ese orden y solo con los campos efectivamente habilitados.

No se han movido los campos. Se ha definido una secuencia común para su interpretación. Un analizador que recorra los bytes físicos y concatene inmediatamente lo que encuentre puede invertir porciones de una opción repartida entre zonas.

Primero hay que descubrir la declaración, después reunir las zonas seleccionadas en el orden lógico y finalmente ensamblar las partes del mismo código. La distinción permite reutilizar un formato maduro sin dejar que el orden de un bucle local decida el contenido de un parámetro.

También conviene separar los mecanismos. Un campo reutilizado puede guardar opciones completas sin división. Un valor dividido puede ocupar varias instancias dentro de la zona normal sin usar file ni sname. Una técnica ofrece más lugares; la otra establece cómo varias representaciones forman un solo valor.

La compatibilidad dependía de los programas instalados

RFC 3396 advertía que muchos agentes DHCP desplegados entonces no implementaban la concatenación. Recomendaba no dividir opciones salvo necesidad o conocimiento de que el receptor sabría reunirlas. La advertencia pertenece a 2002, no es un censo de dispositivos actuales.

La capacidad podía inferirse si el interlocutor había proporcionado o solicitado una opción cuya especificación exigía ese mecanismo, o si el administrador configuraba expresamente la suposición. No se inventó con ello un bit universal de capacidad ni una garantía automática para toda red.

Un emisor podía limitar la división a las opciones que la requerían. Sin embargo, una implementación que admitiera alguna de ellas debía poder concatenar también las partes recibidas de otras opciones. Preferir una salida sencilla no eliminaba la responsabilidad de interpretar correctamente una entrada válida más compleja.

La diferencia tiene consecuencias de operación. El emisor elige cómo aprovechar el espacio; no puede dar por actualizadas todas las rutinas antiguas de arranque. El receptor debe aplicar una regla determinista y no suponer que la repetición significa sustitución.

La lista de búsqueda necesita su bloque completo

Otro documento de noviembre de 2002, RFC 3397, define la opción 119 para listas de búsqueda DNS. Puede usar varias instancias para transportar datos extensos y comprimir nombres con sufijos repetidos.

Los desplazamientos de compresión se calculan respecto al bloque completo de datos concatenados. No incluyen códigos ni longitudes de las instancias, no parten del principio del paquete DHCP y no vuelven a cero en cada fragmento.

Por eso, interpretar una parte aislada puede asignar al puntero un origen equivocado. Primero se reconstruye el objeto lógico; después se decodifican sus nombres. El ejemplo muestra la dependencia entre capas de interpretación sin necesidad de volver a contar toda la historia de la compresión DNS.

La corrección del ensamblaje tampoco acredita la autoridad de la configuración. RFC 3397 señala que una lista de búsqueda puede dirigir un nombre corto hacia otro dominio completo incluso si ese otro dominio tiene registros firmados válidamente. Saber leer el parámetro no demuestra que un servidor esté autorizado a influir en ese destino.

La lección del formato es concreta: aprovechar un campo antiguo exige conservar una forma inequívoca de declarar su nuevo uso. Un archivo puede dejar su casilla sin desaparecer, siempre que el receptor sepa dónde buscar y cómo reconstruir lo que encuentra.