Resumen

  • RFC 3925 permitió que DHCPv4 transportara datos de más de un fabricante en un mismo mensaje mediante entradas con límites explícitos.
  • Registró los números de opción externos, pero dejó a cada fabricante los códigos y significados internos; un PEN identifica un espacio, no autentica una afirmación.

Durante una década, la vía habitual para intercambiar información de fabricantes en DHCPv4 tuvo una forma estrecha. La opción 60 de RFC 2132 permitía al cliente enviar una cadena de clase de fabricante; la opción 43 transportaba un objeto opaco definido por el fabricante. El servidor interpretaba la opción 43 en el contexto señalado por la 60. Funcionaba cuando bastaba el vocabulario de un solo fabricante. La ambigüedad aparecía cuando un dispositivo o un perfil industrial necesitaba información definida de manera independiente por varios. RFC 3925 presenta esto como un problema de encuadre, no como un fallo de asignación de direcciones DHCP.

La respuesta fue otra pareja de opciones. La 124, Vendor-Identifying Vendor Class, y la 125, Vendor-Identifying Vendor-Specific Information, colocan un Private Enterprise Number de IANA junto a los datos de cada fabricante. La opción 125 puede reunir varias entradas, cada una con número de empresa, longitud y bytes del fabricante correspondiente. La longitud delimita los datos; el número indica qué interpretación aplica. RFC 3925 deja intactas las opciones antiguas 60 y 43, así que una implementación puede encontrar las formas anteriores y las nuevas en el mismo intercambio.

Ahí está la distinción de diseño. IANA asigna el código de la opción DHCP externa; su registro de Enterprise Numbers asigna el número que identifica el espacio de un fabricante. Ninguno de los dos registros define qué significa la carga útil. Dentro de ella, las subopciones usan campos de código, longitud y valor, pero RFC 3925 dice que los códigos los define cada fabricante y que IANA no los administra. La norma creó una forma de mantener separados varios dialectos, no un diccionario común para traducirlos.

El tamaño también importa. Como los datos agregados pueden superar la longitud máxima de una opción, RFC 3925 declara que las opciones 124 y 125 requieren concatenación conforme a RFC 3396. El receptor une las instancias repetidas en una opción lógica antes de interpretar sus entradas; no debe tratar cada fragmento como un registro nuevo. La norma recomienda que un número de empresa aparezca una sola vez entre todas las instancias. Si se repite, el comportamiento queda sin definir. El marco admite multiplicidad, pero no atribuye sentido a toda combinación repetida o mal formada.

RFC 3925 reutilizó el patrón de las opciones de clase e información de fabricante de DHCPv6 definidas antes en RFC 3315. Es una reutilización documentada del diseño, no prueba de que ambos protocolos compartan el significado de sus cargas o sus despliegues. Tampoco autentica al fabricante: RFC 3925 no añade seguridad; RFC 3118 define un mecanismo separado de autenticación DHCP que puede utilizarse cuando se requiere autenticidad. Un número dentro de una opción es un selector, no una firma.

Por eso RFC 3925 merece su lugar en la historia: hizo explícitas las fronteras para permitir la coexistencia, sin quitar a cada fabricante la responsabilidad por su propio significado. El registro exterior ayuda a analizar un contenedor y nombrar su espacio. No indica al cliente qué hará un byte específico, si el dispositivo pertenece realmente a ese fabricante ni si una implementación admite la opción. Para eso hacen falta otras pruebas. Los RFC y los registros de IANA acreditan el diseño y las asignaciones de códigos; no miden adopción, interoperabilidad ni resultados operativos.

Fuentes