Resumen

  • RFC 3396 estableció que las apariciones repetidas de un código DHCPv4 eran fragmentos sucesivos de un solo valor, ya fuera por el límite de 255 octetos o por el espacio disponible en campos sobrecargados.
  • La reconstrucción seguía el orden lógico options, file, sname, no su orden físico. El corte no expresaba semántica y el envío correcto no garantizaba que un receptor desplegado supiera recomponerlo.

Un paquete puede contener todos los bytes correctos y, sin embargo, ofrecer una respuesta incorrecta a quien los lea en el orden equivocado. Esa era la situación que RFC 3396 resolvía. La unidad lógica de una opción DHCPv4 podía atravesar tres campos cuya ubicación física no coincidía con la secuencia que debía interpretar el decodificador.

El documento se publicó en noviembre de 2002 en la vía de estándares. Cada opción de longitud variable llevaba un código de un octeto, una longitud de un octeto y entre cero y 255 octetos de valor. La propia longitud impedía que una única instancia transportara objetos mayores.

RFC 2131 ya hablaba de concatenar repeticiones, pero no fijaba por completo el orden. Además decía de manera general que una opción solo podía aparecer una vez salvo autorización particular. RFC 3396 eliminó esa frase y volvió general la reconstrucción: repetir código significaba presentar partes de una opción que debían unirse antes de ser procesadas.

No todo corte respondía a un valor superior a 255 octetos. Una opción más corta podía llegar cuando quedaba poco espacio en el área actual y aún había capacidad en otra. El emisor debía dividirla según el algoritmo o dejarla fuera. Una instancia individual no podía atravesar directamente la frontera de dos campos.

Los tres lugares procedían de BOOTP. DHCP tenía su zona ordinaria de parámetros, pero la sobrecarga de opciones permitía reutilizar file y sname. RFC 3396 imaginó un búfer agregado con un orden obligatorio: opciones ordinarias, después file, después sname.

Ese orden no era el orden físico del paquete. El RFC lo advertía de forma expresa. El agregado era una abstracción para componer y leer, no una modificación del formato. Un analizador que concatenara duplicados según las direcciones de memoria podía invertir piezas válidas.

Los fragmentos se codificaban como opciones normales, compartían código y no superaban 255 octetos de valor. Sus longitudes sumaban el total. El primero debía preceder al segundo dentro del agregado, aunque físicamente un campo apareciera antes que otro en la estructura heredada.

El emisor podía cortar entre cualquier par de octetos. Precisamente por eso no podía usar el corte para comunicar significado. El final de un fragmento no era final de nombre, ruta, subopción ni registro. Era solo la costura entre contenedores.

El receptor debía retirar significado hasta el final. Al encontrar dos o más instancias del mismo código, las ordenaba según el agregado, unía los valores y trataba el resultado como una sola opción. Interpretar cada pieza por separado fabricaba objetos que nunca habían existido.

También el alineamiento era responsabilidad local. El emisor no tenía que colocar valores en direcciones convenientes para otra arquitectura. Después de concatenar, el receptor debía copiar o acceder al objeto de forma segura para su máquina.

El ejemplo de Bootfile Name dividía /diskless/foo en dos opciones 67. Aunque el texto completo era corto, servía para mostrar que /diskle y ss/foo no eran dos nombres. El lugar de la división era indiferente al contenido; la identidad aparecía al reunirlos.

La advertencia de despliegue daba al estándar una dimensión histórica. Muchos agentes DHCP existentes no implementaban concatenación. El nuevo emisor podía seguir todos los MUST y enfrentarse a un cliente que leyera una parte, confundiera las repeticiones o descartara la opción. La conformidad del origen no era recibo de reconstrucción.

El RFC separó por ello las opciones que exigían concatenación de las que no. La primera categoría solo existía cuando el documento que definía una opción citaba expresamente RFC 3396 y obligaba a soportarlo. Se desaconsejaba dividir salvo necesidad, evidencia de capacidad del par o una decisión administrativa explícita.

Un par que hubiera pedido o proporcionado alguna opción de la categoría obligatoria podía presumirse capaz. La presunción facilitaba interoperar, pero no demostraba todos los casos de longitud, sobrecarga y consumo. Una implementación podía negarse a dividir opciones ordinarias; si soportaba cualquier opción obligatoria, debía saber concatenar repeticiones recibidas de ambas categorías.

La autenticación demostraba que la reconstrucción precedía incluso a un MAC. La opción de RFC 3118 podía fragmentarse. Al poner en cero el campo de autenticación antes de generar o verificar el MAC, el código debía encontrarlo aunque cruzara varias instancias. Calcular sobre recipientes separados podía producir una representación distinta del objeto firmado.

RFC 3397, RFC 3361, RFC 3442 y RFC 3925 aplicaron después el mecanismo a búsquedas de dominio, descubrimiento SIP, rutas sin clase y datos de proveedor. Sus gramáticas no pertenecían a RFC 3396. Este definía la operación anterior que les entregaba un único flujo de bytes.

Por eso una captura solo prueba una etapa. Puede mostrar los tres fragmentos. No prueba que el cliente activó la sobrecarga, recorrió el agregado correcto, conservó cada aparición, gestionó alineamiento, autenticó, analizó y aplicó la configuración. Una operación exitosa exige recibos sucesivos.

La búsqueda actual del RFC Editor no presenta erratas para RFC 3396. Es un dato sobre el registro editorial, no un certificado de productos. El propio documento corrigió una ambigüedad normativa mientras reconocía que el código desplegado no seguía una práctica común.

La especificación inicial mínima de Lu Heng ayuda a leer su alcance. El estándar fijó código común, orden, continuidad y ausencia de semántica en el corte, dejando libres los búferes internos y las interfaces de error. La primacía del código en ejecución obliga a probar cortes incómodos, los tres campos y el consumo final.

RFC 3396 separó identidad de ubicación. La opción podía ocupar varios lugares y el mapa físico podía engañar al lector. La solución no consistió en interpretar mejor cada fragmento, sino en no interpretarlo todavía: primero uno, después significado.

Fuentes