Resumen

  • RFC 1048 hizo que 99.130.83.99 seleccionara una gramática común dentro del campo vend de BOOTP. Después del cookie, las opciones con etiqueta y longitud podían leerse o saltarse sin destruir los límites de las siguientes.
  • La forma ocupaba como máximo 64 octetos y distinguía códigos genéricos de usos locales. Ninguna de esas reglas autenticaba al servidor ni demostraba que una dirección, un router o un servicio fueran correctos.

RFC 951 imaginó un cliente que todavía no podía comportarse como un host plenamente configurado. Conocía su interfaz física y podía emitir una petición, pero necesitaba descubrir su dirección, un servidor y el archivo de inicio. Primero obtendría esos datos mediante BOOTP; después, otro protocolo trasladaría el archivo.

En el paquete había un campo de proveedor de 64 octetos. El nombre vend permitía adaptaciones, aunque también abría una incompatibilidad: un fabricante podía convertir los mismos bits en direcciones y otro en parámetros completamente distintos. RFC 951 recomendaba un número mágico inicial para señalar el tipo de información, pero no había asignado todavía una estructura general al resto.

En febrero de 1988, RFC 1048 eligió una respuesta conservadora. Mantuvo el tamaño y convirtió el interior en una secuencia identificable. La innovación no fue una base de datos más grande; fue una frontera de interpretación que permitía que clientes heterogéneos compartieran extensiones sin atribuir confianza automática al paquete.

Reconocer el idioma no identifica al interlocutor

Los cuatro primeros octetos pasan a ser 99.130.83.99, equivalentes a 63.82.53.63 en hexadecimal y transmitidos en orden de red. Según RFC 1048, ese magic cookie identifica el modo en que deben interpretarse los datos posteriores.

La frase acota la prueba. Al encontrarlo, el cliente puede escoger el parser de RFC 1048 en vez de una disposición privada. No obtiene una identidad de fabricante o de servidor. El valor no es secreto, no lleva firma y no demuestra que un relay haya conservado el contenido. Mucho menos certifica el control legítimo de las direcciones anunciadas.

El Transaction ID y los campos de dirección de BOOTP cumplen funciones distintas: ayudan a emparejar la respuesta con una consulta y a hacerla llegar. Una correlación plausible reduce confusión entre intentos; no constituye autenticación criptográfica. El protocolo puede saber a qué conversación parece pertenecer un paquete y seguir sin saber quién lo creó.

La advertencia aparece con claridad en RFC 1542. BOOTP carece de un mecanismo razonable de autenticación, y un servidor no autorizado puede entregar una dirección IP, un router o un DNS falsos. Un atacante no necesita romper la gramática. Le basta con hablarla correctamente antes que la fuente legítima.

Cada longitud protege la opción que viene después

Una opción ordinaria comienza con un octeto de etiqueta y otro de longitud. A continuación llegan tantos octetos de valor como indica esa longitud, que no incluye los dos octetos de cabecera. Los números de varios octetos usan el orden de red.

El efecto principal no es solo ahorrar bytes. La longitud delimita el coste de no saber. Un cliente antiguo puede encontrar una etiqueta nueva, ignorar exactamente su valor y continuar en la siguiente opción. El mensaje conserva su estructura aunque emisor y receptor no compartan el mismo catálogo completo.

Eso habilita evolución parcial. El servidor no tiene que encerrar todo el paquete en una versión nueva para añadir un parámetro. El cliente tampoco tiene que adivinar dónde termina una extensión desconocida. La compatibilidad se obtiene permitiendo ignorancia explícita, no fingiendo comprensión.

Pero el largo no valida el significado. Una dirección con cuatro octetos puede ser falsa. Un código de uso local puede tener dos definiciones en dos campus. Un parser puede leer la longitud correcta y aun cometer un error de límites. El formato hace la pregunta procesable; no responde si el contenido merece acción.

RFC 1084 y RFC 1497 modificaron el repertorio y conservaron el cookie, las etiquetas y el salto de elementos desconocidos. La continuidad demuestra utilidad del mecanismo de extensión, no uniformidad de implementación.

Pad y End gobiernan el recorrido

Dos etiquetas no llevan longitud. Pad, código 0, ocupa un solo octeto y sirve para alinear o rellenar. End, código 255, también ocupa uno y termina la secuencia; lo que queda se completa con ceros.

Son instrucciones para el lector. Si se busca un largo después de Pad, todas las posiciones posteriores se desplazan. Si se interpretan los ceros que siguen a End, el relleno empieza a parecer configuración. Un protocolo ampliable necesita declarar cómo parar y cómo no avanzar, no solamente cómo añadir datos.

Hay además dependencias de orden. RFC 1048 exige que la máscara preceda al router cuando aparecen ambos. El cliente necesita la máscara para decidir qué direcciones son locales y cómo debe interpretar la puerta de enlace. La presencia de etiquetas independientes no vuelve intercambiable toda la lista.

El parser, por tanto, ejecuta una pequeña gramática: cookie, opciones ordinarias, dos excepciones de control, dependencias y final. Reducirla a “TLV” oculta las reglas que impiden convertir un byte de relleno en una orden de red.

El espacio escaso crea una política de asignación

Cuatro de los 64 octetos desaparecen en el cookie. Cada opción corriente paga otros dos antes de su valor. Una sola dirección IPv4 suma cuatro; una lista consume varios bloques. RFC 1048 prohíbe desbordar vend y aconseja buscar por otro servicio la información que no sea esencial en esta primera fase.

El límite obliga a priorizar. ¿Debe el primer paquete llevar servidores de nombres, de tiempo, de registro o una ruta? La norma define representaciones; el operador y el cliente deciden qué es necesario para arrancar. El sobre pequeño impide que el catálogo se convierta en una lista infinita de deseos.

También hace escasos los números comunes. RFC 1048 pide registrar las extensiones genéricas para evitar que dos significados públicos ocupen el mismo código. Reserva 128–254 a interpretaciones específicas del sitio. La separación protege el espacio compartido y deja margen local, pero la opción privada solo es portable dentro de su acuerdo.

Este mecanismo combina adaptación y dependencia. Es barato sumar una opción a una gramática que ya está en firmware, clientes y servidores. Resulta mucho más caro reemplazar la envoltura. La compatibilidad que facilita pequeños cambios puede fijar durante años el borde de 64 octetos y sus reglas históricas.

Administrar el dato no autentica el destino

RFC 1048 observa que BOOTP puede ser muy eficiente cuando una tabla central permite devolver todo lo necesario de una vez. Frente a descubrimientos distribuidos, un único intercambio reduce mensajes y deja que el cliente consulte su copia local. Sin embargo, esa tabla puede quedar incompleta o anticuada.

Además, la autoridad para editarla tiene alcance limitado. Quien controla la base BOOTP controla la información de arranque que publica el servidor. No demuestra por ello la identidad del servidor de archivos que figura en el registro ni la integridad de la imagen que este ofrece. El propio RFC separa la administración de BOOTP de la autenticación fuerte que debe realizar el servicio final.

Un arranque exitoso acumula varias evidencias: sintaxis reconocida, correlación de transacción, procedencia de una respuesta, alcance de la base y resultado del protocolo posterior. Confundirlas en una sola palabra—“válido”—dificulta investigar si falló el encuadre, el contenido, la autoridad o la descarga.

RFC 1542 recomienda enviar el cookie incluso cuando el cliente no adjunta opciones: cookie, End y ceros. Así el servidor conoce el formato esperado de su respuesta. La recomendación negocia una lengua casi sin decir nada en ella. No puede ser una credencial.

DHCP conservó la gramática y heredó su frontera

RFC 1533 emplea el formato de extensiones BOOTP para opciones DHCP. Conserva etiqueta, longitud y valor, las excepciones 0 y 255, el cookie, el orden de red y el rango específico del sitio. RFC 2132 registra después un catálogo DHCP más amplio en la misma tradición.

La secuencia documental permite afirmar una genealogía del formato. No permite trasladar todo el funcionamiento posterior de DHCP a una red BOOTP de 1988 ni declarar que toda opción mantuvo la misma semántica. RFC 1533 señala que no discute seguridad. El recipiente viajó; la autoridad no apareció dentro de él.

La contribución duradera de RFC 1048 fue asignar al acuerdo común una función posible de cumplir. Cuatro bytes seleccionaban la gramática. Las longitudes hacían saltable lo desconocido. Pad y End gobernaban el movimiento. El techo contenía la ambición. La confianza seguía siendo trabajo de otras capas y otros responsables.

Fuentes y límites de evidencia

RFC 951 define BOOTP, vend y el primer número mágico. RFC 1048 fija el cookie, la estructura, los códigos, el orden y el límite. RFC 1084 y RFC 1497 documentan revisiones de las extensiones. RFC 1533, RFC 1542 y RFC 2132 muestran la continuidad hacia DHCP y la inseguridad de BOOTP.

Son fuentes de diseño y normalización. No cuentan cuántas redes desplegaron cada versión, no certifican una implementación concreta y no convierten la presencia actual de un código en evidencia de uso histórico o de autoridad operacional.