Resumen

  • RFC 3634 definió la subopción 10 como una o más direcciones IPv4 KDC, en bloques de cuatro octetos y orden decreciente de prioridad. La lista no llevaba reino, transporte, puerto, salud ni identidad.
  • La recepción DHCP, la instalación local, la elección de candidato, el contacto, la autenticación del KDC, la emisión de un ticket y el resultado SNMPv3 pertenecen a capas probatorias distintas.
  • Una lista nueva debe desplegarse con canarios, límites de reintento, presupuesto de carga para el respaldo y registro exacto de por qué cada cliente eligió y abandonó un destino.

El mismo dato produjo dos rutas

El objetivo histórico era concreto. Una pasarela residencial CableHome necesitaba conocer la dirección de un KDC para comenzar Kerberos antes de establecer una relación SNMPv3 segura. RFC 3634 asignó el código 10 dentro de la opción CCC: longitud mínima de cuatro octetos, siempre múltiplo de cuatro, y direcciones IPv4 ordenadas de mayor a menor prioridad.

El formato resuelve distribución, no observación. No indica cuándo se midió el servidor, qué reino atiende, qué transporte o puerto usa, qué identidad debe presentar ni si respondió. Tampoco describe por completo cuánto espera el cliente, qué error habilita el siguiente candidato o cuándo vuelve al primero.

Por eso dos clientes con el mismo valor pueden generar rutas distintas sin contradecir el campo. El hecho decisivo está en la implementación y la política local, no en los octetos compartidos.

Los campos vecinos no son propiedades implícitas

RFC 3495 pone el nombre del reino, los reintentos de AS y los de AP en subopciones separadas. Esta estructura evita un error frecuente de inventario: adjuntar mentalmente todos los atributos de “Kerberos” a una dirección KDC.

La comparación con RFC 4120 y DNS SRV muestra cuánto contexto puede existir fuera de una IP. SRV incorpora servicio, transporte, reino, TTL, prioridad, peso, puerto y destino. RFC 2782 especifica cómo ordenar destinos alcanzables y distribuir opciones del mismo nivel. También limita su significado: el peso es selección estática, no telemetría dinámica de carga.

RFC 6784 hizo explícitos prioridad, peso, transporte, puerto, dirección IPv6 y reino en DHCPv6. Es una evolución útil para distinguir dimensiones, no una licencia para leerlas dentro de la subopción de 2003.

Rechazar al impostor no recupera el tiempo

RFC 3634 depende de la seguridad DHCP. Advierte que información incorrecta puede desviar tráfico, causar denegación de servicio o habilitar intermediación. Presenta filtros CMTS, certificados, autenticación mutua, segmentación y cortafuegos como mitigaciones o supuestos.

La autenticación posterior puede impedir que un destino malicioso emita credenciales válidas. Sin embargo, el intento consume espera, ancho de banda y cálculo. En una flota, el primer destino incorrecto convierte una protección correcta en una cola colectiva. Un control puede preservar la confianza y aun así degradar la disponibilidad.

También importa quién autorizó la configuración. Una dirección proveniente de un servidor permitido no demuestra por sí sola que el reino, el KDC y el proveedor institucional sean los pretendidos. Autorización de distribución e identidad del servicio son relaciones diferentes.

El expediente que falta

La primera evidencia es el mensaje DHCP validado, con transacción, época, servidor y bytes. La segunda es la instalación local. La tercera explica la elección: versión, posición, temporizador, fallo anterior y regla aplicada. Después vienen la ruta, el transporte, el puerto y el contacto.

Sólo entonces aparece la prueba Kerberos: reino, identidad, reloj, solicitud y respuesta AS o TGS correlacionadas. La autenticación de aplicación y la relación SNMPv3 son posteriores. Finalmente debe observarse la operación de gestión concreta.

Esta secuencia evita tres atajos. DHCPACK no significa ticket. Ticket no significa sesión de aplicación. Sesión segura no significa que la acción de gestión produjo el efecto esperado.

Límite de evidencia

Este Artículo no atribuye conducta a ningún operador, proveedor, equipo, KDC, reino, usuario o incidente. El estado Standards Track y la asignación IANA del código 10 no prueban implantación.

RFC 3634 define el objeto; RFC 3495, su entorno CCC. RFC 2131 y RFC 3118 separan entrega y autenticación DHCP. RFC 4120 y RFC 2782 sirven de comparación para descubrimiento; RFC 6784 es linaje posterior. RFC 5021 y RFC 6251 mantienen TCP y TLS como pruebas aparte.

Los ensayos de Heng Lu se usan como lentes declaradas para no confundir especificación, autoridad, código ejecutado y realidad observada. No demuestran intención histórica ni hechos de red.

La lista decía a dónde mirar primero. Sólo los recibos posteriores podían decir qué encontró el cliente.

Sources