Resumen

  • RFC 9686 permite que los dispositivos comuniquen a un servidor DHCPv6 las direcciones IPv6 generadas mediante SLAAC o configuradas de forma estática. El mecanismo recupera visibilidad operativa sin trasladar al servidor la selección de esas direcciones.
  • RFC 9915 denomina «arrendamiento» al estado de ciclo de vida que crea el servidor para el registro. Ese término no significa que DHCPv6 haya asignado la dirección: continúa siendo elegida por el dispositivo.
  • En SLAAC, calcular NextAddrRegRefreshTime en torno al 80 % de la vida válida no programa una transmisión. El refresco solo se agenda cuando la red modifica Valid Lifetime en más del 1 %; si el vencimiento previsto continúa su cuenta atrás sin ese cambio, puede no enviarse ningún refresco.
  • ADDR-REG-REPLY confirma la recepción del mensaje y detiene sus retransmisiones. No acredita almacenamiento, legitimidad, identidad, alcanzabilidad, tráfico continuado ni autoridad para imponer una medida.

La regla automática y sus premisas ocultas

Una política que ordene «poner en cuarentena toda dirección registrada asociada a una señal de riesgo» reúne decisiones de naturaleza distinta. Primero hay un hecho protocolario: una dirección fue comunicada a un servidor. Después aparece una inferencia: cierto dispositivo utilizaba esa dirección en el instante de interés. A continuación llega una valoración: el comportamiento observado infringe una regla. Finalmente se ejecuta una medida: limitar o interrumpir la conectividad.

RFC 9686 normaliza una parte del primer hecho. No observa el flujo que originaría una alerta, no autentica a un usuario y no concede facultades para sancionar. Su aportación consiste en ofrecer a la infraestructura DHCPv6 información sobre direcciones que el servidor no seleccionó: direcciones creadas mediante SLAAC o configuradas estáticamente.

La precisión terminológica resulta esencial. RFC 9915, que sustituyó a RFC 8415, establece en su sección 6.6 que el servidor crea un arrendamiento para la dirección autogenerada registrada. El dispositivo realiza las acciones periódicas previstas para renovar ese estado y, con el tiempo, el arrendamiento puede expirar. Pero la misma sección separa con claridad el ciclo de vida de la procedencia de la dirección: la selección corresponde al dispositivo, no al servidor DHCPv6.

Existen, por tanto, un arrendamiento en el servidor y una dirección no asignada por ese servidor. El arrendamiento representa el estado de ciclo de vida de la inscripción recibida; no prueba una concesión DHCPv6. Omitir por completo el término contradice RFC 9915. Interpretarlo como prueba de asignación altera igualmente el sentido de la norma.

Cómo llega una dirección al servidor

El procedimiento comienza con el anuncio de capacidad. El cliente solicita OPTION_ADDR_REG_ENABLE dentro de intercambios DHCPv6 ordinarios. Si el servidor admite el mecanismo, devuelve la opción en Advertise o Reply. Sin esa señal, el cliente no debe registrar direcciones. La falta de una entrada puede reflejar que la red no anunció la función, que el cliente la tenía desactivada, que se perdieron mensajes o que un terminal hostil decidió no colaborar. No demuestra por sí sola que la dirección no existiera.

Tras configurar satisfactoriamente una dirección autogenerada o estática válida y de ámbito global, el cliente envía ADDR-REG-INFORM. Debe incluir Client Identifier y exactamente una opción IA Address. Cada dirección se notifica por separado y desde la interfaz que la tiene configurada. Las direcciones link-local y las obtenidas mediante DHCPv6 quedan fuera de este procedimiento.

El mensaje debe originarse en la propia dirección que se registra. Cuando no interviene un relay, el servidor compara la IA Address con la dirección de origen del paquete. Si el mensaje ha sido retransmitido, la comparación se realiza con el campo peer-address del Relay-forward más interno. Esto reduce una contradicción concreta: el contenido no puede señalar una dirección distinta de la que presenta el contexto de transporte pertinente. No identifica a una persona ni demuestra que la misma fuente produjera otro tráfico en otro momento.

El servidor debe descartar ADDR-REG-INFORM si falta Client Identifier, si aparece Server Identifier, si falta IA Address, si la dirección no coincide con el origen aplicable o si se incluye Option Request. Superadas esas comprobaciones obligatorias, RFC 9686 emplea una fuerza normativa diferente para la plausibilidad topológica: el servidor debería verificar que la dirección sea apropiada para el enlace o pertenezca a un prefijo delegado al cliente. La comprobación es SHOULD, no MUST.

Si el servidor realiza esa verificación y esta falla, debe descartar el mensaje y debería registrar el fallo. El carácter obligatorio del descarte depende aquí de que la comprobación se haya efectuado y haya producido un resultado negativo. Una implementación que no realizó la prueba no puede presentar la dirección como si la hubiera superado.

Para un registro aceptado, el servidor debe registrar el acontecimiento salvo que esté configurado para no hacerlo. Debería crear una asociación entre Client Identifier y dirección IPv6. También debería marcar la dirección como no disponible para asignaciones posteriores y excluirla de futuros Advertise. Finalmente, debe devolver ADDR-REG-REPLY.

Las diferencias entre esos verbos importan. La respuesta es obligatoria; la asociación y la marca de indisponibilidad son recomendaciones; la escritura en el registro admite la excepción expresa de una configuración que la desactive. Recibir una respuesta no garantiza, por tanto, que exista una asociación persistente o un asiento histórico recuperable.

El acuse no amplía la autoridad del dato

ADDR-REG-REPLY contiene el identificador de transacción y la IA Address correspondientes. Cuando el cliente lo recibe, debe dejar de retransmitir. Esa es la función operativa de la respuesta.

RFC 9686 limita expresamente su significado: el mensaje indica que el servidor recibió un ADDR-REG-INFORM válido y que ya no es necesario repetirlo. No debe considerarse prueba de validez de la dirección y no es requisito para utilizarla. Los relays y otros equipos que inspeccionen la respuesta tampoco deben crear ni modificar estado de reenvío o seguridad basándose en ella.

En consecuencia, una respuesta correcta no demuestra que el servidor haya conservado el dato, que la dirección sea legítima, que permanezca en uso, que resulte alcanzable desde otro punto o que pertenezca a quien afirma utilizarla. Tampoco autentica al dispositivo o a una persona, acredita tráfico independiente ni autoriza una cuarentena.

La validez previa comprobada por el cliente tiene asimismo un alcance limitado. La Duplicate Address Detection de RFC 4862 determina si una dirección tentativa parece única en el enlace. El procedimiento no es infalible y no autentica al nodo. Ausencia de un duplicado detectado no equivale a identidad verificada ni a derecho exclusivo.

Calcular un instante no es programar una transmisión

El aspecto temporal de SLAAC exige una distinción especialmente cuidadosa. RFC 9686 define AddrRegRefreshInterval(address) como el 80 % de la Valid Lifetime actual. El cliente aplica además un AddrRegDesyncMultiplier elegido aleatoriamente entre 0,9 y 1,1 para evitar que muchos dispositivos actúen a la vez.

Cuando el cliente registra o refresca una dirección, utiliza ese intervalo para calcular NextAddrRegRefreshTime. Sin embargo, ese cálculo inicial no programa ni agenda ninguna transmisión de refresco. El valor queda como estado temporal de referencia; no constituye un temporizador que, al vencer, obligue a enviar otro ADDR-REG-INFORM.

La transmisión se agenda bajo otra condición: que la red cambie la Valid Lifetime de una dirección existente en más del 1 %. En ese caso, el cliente vuelve a calcular el intervalo y programa el refresco para el instante anterior entre «ahora más el nuevo intervalo» y el NextAddrRegRefreshTime ya calculado. Si el resultado se encuentra en el pasado, el refresco se realiza de inmediato.

Si la vida válida anunciada se limita a disminuir con el paso del tiempo y el instante de expiración previsto no cambia, puede no enviarse nunca un refresco. No hace falta: el servidor ya conoce el vencimiento que corresponde al arrendamiento. Por ello, sobrepasar el punto nominal cercano al 80 % sin observar un mensaje nuevo no demuestra una avería, una omisión del cliente ni una pérdida de telemetría. Confundir cálculo de estado con programación de una transmisión produciría falsas alarmas y podría activar medidas indebidas.

Cuando la red sí modifica el vencimiento previsto, el algoritmo intenta comunicarlo con margen. El multiplicador máximo de 1,1 sitúa el punto de referencia, en condiciones ordinarias, como máximo en el 88 % del intervalo original. Esto deja tiempo para retransmisiones, pero no garantiza la entrega bajo cualquier condición.

Las direcciones estáticas siguen otro régimen. Como poseen una vida válida infinita no modificada por Router Advertisements, el siguiente refresco sí se programa después de cada registro o actualización. El intervalo predeterminado es de cuatro horas y debería ser configurable. Una Valid Lifetime igual a cero indica, en cambio, que la dirección ha expirado; el servidor debe tratarla como tal.

Umbrales distintos para acciones distintas

Una automatización prudente vincula la carga probatoria al impacto de la acción, no a la comodidad del dato disponible.

Acción Evidencia mínima razonable Supervisión necesaria Reversibilidad
Añadir contexto a una alerta Registro RFC 9686 con dirección, identificador, enlace y tiempos Automatizable si conserva procedencia e incertidumbre Total: no cambia el servicio
Solicitar más telemetría Registro coincidente y señal independiente incompleta Automatización limitada y auditable Alta
Elevar la prioridad de análisis Coincidencia temporal entre registro y evidencia de tráfico Revisión posterior de fuentes Alta
Aplicar una limitación breve Tráfico observado, asociación vigente y ancla de acceso coherente Criterio predefinido, caducidad y revisión rápida Media
Aislar un equipo o puerto Varias fuentes concordantes, identidad técnica suficiente y política aplicable Autorización competente y vía de restitución Baja
Atribuir a una persona o imponer consecuencias Evidencia preservada, identidad independiente y procedimiento institucional Revisión humana separada de la operación de red Potencialmente muy baja

Estos umbrales no forman parte de RFC 9686; son una disciplina de gobierno para respetar lo que la RFC sí demuestra. El registro puede enriquecer todas las decisiones, pero no completa por sí solo ninguna de las que alteran disponibilidad, derechos o responsabilidades.

La corroboración cubre vacíos, no acumula decorado

RFC 9099 recomienda combinar registros de aplicaciones e IPFIX, Neighbor Cache histórica, DHCPv6, SAVI, puertos de conmutador, cortafuegos, autenticación y RADIUS. Cada fuente responde a una pregunta diferente.

El cortafuegos o IPFIX puede demostrar que se observó cierto tráfico. Neighbor Cache o SAVI pueden vincular una IPv6 con información de capa 2. Los datos de relay y puerto aportan contexto topológico. RADIUS o el inventario pueden asociar un acceso, una cuenta o un equipo administrado. La conclusión solo es tan sólida como la correspondencia temporal y el ámbito de cada fuente.

Dentro de FCFS SAVI, definido en RFC 6620, únicamente los puertos de conmutador están permitidos como binding anchors. Su alcance termina en ese puerto y en el tráfico local comprendido en su perímetro. No autentica por sí mismo a una persona, no valida tráfico de tránsito y no identifica el proceso que generó una comunicación.

Antes de una medida intrusiva deben conservarse la declaración del cliente, el contexto de relay o enlace, el intervalo de vigencia, una observación independiente del tráfico, la fuente utilizada para la identidad, la regla aplicable y la autoridad que aprobó la actuación. Las contradicciones y ausencias también son parte del expediente. Convertirlas en una puntuación opaca no las elimina.

Fuentes