Resumen

  • En RFC 2132, la opción 60 orienta una interpretación de clase, la 61 indexa vinculaciones de direcciones, la 55 pide valores y la 43 transporta información opaca dentro del ámbito del proveedor.
  • Encontrar esos campos en el cable no autentica al fabricante, no fija la identidad física del cliente y no demuestra que la configuración ofrecida se haya instalado o haya dado servicio.

La confusión comienza cuando se lee toda la solicitud como una biografía del dispositivo. En un único mensaje aparecen una cadena que suena a marca, una clave que el servidor puede recordar y una secuencia de opciones deseadas. Son hechos observables, pero pertenecen a momentos de decisión distintos. El documento publicado en marzo de 1997 por Steve Alexander y Ralph Droms les dio una sintaxis común sin convertirlos en una declaración confiable de la máquina.

El RFC 2132 define opciones DHCP y extensiones de proveedor de BOOTP. En el nivel exterior, un código identifica la opción y casi siempre sigue un octeto de longitud y el contenido indicado; Pad y End son excepciones. En BOOTP, cuatro octetos de «magic cookie» seleccionan la interpretación del campo posterior. Ese límite de análisis heredado del RFC 1048 ayuda a que clientes heterogéneos lean el mensaje. Reconocer la estructura no autentica el origen de cada valor.

La opción 60 es una cadena opcional que el cliente aporta para indicar su clase de proveedor o ciertos rasgos de configuración. La interpreta el servidor. Si este no sabe interpretar la información de clase, debe ignorarla, aunque puede informar de ella. Si responde con información específica del proveedor, debería hacerlo mediante la opción 43. La cadena puede seleccionar una política; no certifica una pieza de hardware ni obliga al servidor a creer una declaración del cliente.

La respuesta de la opción 43 pertenece a otro ámbito. Son octetos opacos cuyo significado define un proveedor. Si contiene varios elementos, el RFC recomienda encapsular subopciones de código, longitud y valor. Un código interior puede redefinirse dentro de ese espacio sin cambiar el significado del código DHCP exterior. Incluso End tiene un límite local: termina las extensiones encapsuladas y no todo el campo de opciones. Si no aparece, manda la longitud de la opción envolvente. Conservar ambos límites evita atribuir a la red global una semántica privada. Ver la respuesta tampoco demuestra que el cliente la haya entendido.

La opción 61 no es otra forma de decir «clase». Su identificador es la clave con la que el servidor consulta su base de datos de vinculaciones de direcciones. Debe tratarse como objeto opaco. Puede parecerse a un tipo y dirección de hardware, pero también puede emplear otra clase de valor. El RFC exige que sea único entre los identificadores usados en la subred conectada; elegirlo correctamente corresponde al proveedor o al administrador. Esa unicidad sirve al registro de vinculaciones, no es un protocolo de autenticación. La misma secuencia capturada no acredita, por sí misma, una persona o un equipo físico permanente.

La opción 55 contiene códigos de parámetros que el cliente solicita, quizá ordenados según preferencia. El servidor no tiene que devolverlos en ese orden, aunque debe intentar insertar los solicitados en el orden pedido. Tampoco hay promesa de que aparezcan todos. La opción 57 fija el tamaño máximo de mensaje DHCP que el cliente acepta, con mínimo legal de 576 octetos. La lista y el límite describen lo que puede negociarse, no el estado que una aplicación acabó utilizando.

Una oferta del servidor no cierra el expediente. El RFC 2131 distingue descubrimiento, oferta, petición, confirmación y comprobaciones finales del cliente. Para demostrar una instalación harían falta el intercambio pertinente, la política y el registro de vinculaciones del servidor, el estado aceptado por el anfitrión y una comprobación del servicio. Las fuentes no miden el despliegue de una red nombrada. El apartado de seguridad de RFC 2132 dice expresamente que no trata cuestiones de seguridad; sería erróneo extraer de ese silencio una garantía.

La contribución histórica fue hacer extensible la configuración sin borrar la diferencia entre clasificación, memoria de la vinculación, preferencias y datos de proveedor. La primacía del código en funcionamiento de Heng Lu es una lente editorial útil: un registro de protocolo y el funcionamiento de un sistema requieren pruebas separadas. No es una norma adicional de DHCP.

Fuentes: RFC 2132, RFC 2131, RFC 1048 y Running-Code Primacy.