Resumen

  • Una respuesta exitosa de RFC 5007 puede contener datos, una lista de enlaces para seguir consultando o ningún enlace conocido; «éxito» no equivale a «equipo presente».
  • La afirmación defendible depende del conjunto de servidores consultados, el tratamiento de datos parciales y conflictivos, la revisión local obtenida y una observación separada del efecto.

En una sala de control alguien pregunta: «¿sigue conectado el equipo?». El sistema consulta un servidor DHCPv6, recibe datos y responde que sí.

El protocolo y la pregunta no eran iguales.

RFC 5007 creó Leasequery para que procesos y dispositivos recuperen de forma ligera información de enlace desde servidores DHCPv6. Incluso declara que el mensaje solo consulta: no cambia el estado de la dirección, el prefijo ni el enlace. El resultado es lo que el servidor sabe y decide devolver, no una medición directa del extremo.

Su ejemplo operativo parte de un paquete IPv6 que llega a un concentrador de acceso. El concentrador quiere actualizar la información del cliente al que está arrendada esa dirección. El paquete observado y el enlace recuperado ocupan capas diferentes. El primero puede iniciar el proceso; el segundo no autentica por sí mismo el origen del paquete ni anticipa que el extremo continuará disponible.

Una respuesta satisfactoria tiene tres formas. OPTION_CLIENT_DATA contiene enlaces que actualizan el estado local. OPTION_LQ_CLIENT_LINK enumera varios enlaces y obliga a emitir consultas adicionales por cada dirección de enlace. La ausencia de ambas opciones significa que ese servidor no encontró enlaces, aunque el intercambio haya terminado con éxito. Antes de hablar de presencia, un sistema debe saber cuál de las tres recibió.

Tampoco todos los fallos dicen «no existe». Un estado de error puede pedir otra consulta, otro servidor o la terminación conforme a la política local. Si el solicitante conoce el servidor que posee información autoritativa, debería consultarlo. Si no lo conoce, debería acudir a todos los servidores conocidos o configurados. Una búsqueda que termina tras el primer obstáculo puede ser prudente y, a la vez, incompleta.

Las autoridades pueden aportar piezas distintas. RFC 5007 recomienda unir datos disjuntos, como una dirección mantenida por un servidor y un prefijo delegado por otro. Cuando dos fuentes informan del mismo valor, sus datos se consideran solapados o conflictivos. La preferencia se guía por el OPTION_CLT_TIME más reciente.

Los errata del RFC son decisivos aquí. El erratum técnico 3763 elimina la frase original que ordenaba descartar datos sin OPTION_CLT_TIME. En un par de conmutación, el servidor secundario puede tener el enlace sin haber realizado la última transacción con el cliente. Si hay otra respuesta con tiempo, esa respuesta merece preferencia; si solo llegó la respuesta sin tiempo, los datos no se vuelven inválidos automáticamente. El erratum editorial 4816 corrige el nombre de la opción multienlace a OPTION_LQ_CLIENT_LINK.

La marca temporal tampoco hace el salto a la realidad física. Expresa cuánto tiempo ha transcurrido desde la última transacción conocida por ese servidor al construir la respuesta. No prueba quién usó el equipo, si el paquete actual es legítimo, si el equipo aún responde ni si una regla de acceso permitió el tráfico.

El problema de arranque con delegación de prefijos expone un círculo operacional. Tras reiniciarse, el concentrador quizá no pueda inyectar una ruta; sin ruta no llega tráfico; sin tráfico no se dispara la consulta a demanda. RFC 5007 menciona una reconstrucción anticipada y la deja fuera de la especificación. RFC 5460 añade después consultas masivas y RFC 7653 notificaciones activas. No son propiedades implícitas de cada LEASEQUERY-REPLY.

La autenticación reduce unas incertidumbres y deja otras intactas. El servidor puede restringir datos incluso a un solicitante de confianza. Un relé fiable puede transportar una consulta originada en un lugar no fiable. Un servidor malicioso puede entregar información incorrecta sobre arrendamientos o rutas. Saber qué participante firmó o protegió el intercambio no confirma que su estado esté actualizado ni que describa un resultado externo.

La caché negativa también debe llevar apellido. RFC 5007 aconseja recordar que una consulta reciente no devolvió datos, para limitar cargas y ataques. Eso describe una decisión de recursos durante un intervalo. No es una declaración permanente de inexistencia.

Un recibo operativo debería guardar:

  1. el disparador, la dirección o DUID, el tipo de consulta y el enlace;
  2. el universo autoritativo esperado y los servidores realmente consultados;
  3. solicitudes, respuestas, autenticación, relés, reintentos y causa de cierre;
  4. la variante de éxito o error y las restricciones de información;
  5. la expansión de listas de enlaces y las piezas aún pendientes;
  6. la fusión de datos disjuntos y la resolución de conflictos;
  7. el uso o ausencia de OPTION_CLT_TIME;
  8. la revisión del estado retenido y la edad de la caché negativa;
  9. la decisión de ruta, filtro o acceso y su resultado observado aparte.

No es un requisito oculto de RFC 5007, sino una recomendación de gobierno inspirada en las capas de realidad de Heng Lu. El registro del servidor, el intercambio, el estado local, la decisión de control y el efecto necesitan vínculos probatorios, no un mismo color verde.

RFC 7513 usa Leasequery como posible apoyo para recuperar enlaces SAVI. Eso no convierte una dirección arrendada en identidad civil o corporativa. El contexto original está en RFC 3315, RFC 3633 y el antecedente IPv4 RFC 4388. Las revisiones posteriores RFC 8415 y RFC 9915 tampoco eliminan el límite probatorio de una respuesta capturada.

Fuentes