Resumen

  • Neighbor Unreachability Detection conserva una afirmación limitada: hubo evidencia reciente de que el camino de ida entregó paquetes a la capa IP del vecino. Al agotarse el temporizador, esa evidencia pasa de REACHABLE a STALE, aunque ningún paquete haya fallado.
  • Si no hay un vecino alternativo, RFC 7048 permite retener la dirección de enlace y sondear con más paciencia. La continuidad del envío no autentica al vecino ni prueba propiedad, autorización o éxito de la aplicación.

Un panel de operación pinta en ámbar una entrada de Neighbor Cache. El tráfico sigue pasando, pero la etiqueta dice STALE. Si el color se interpreta como salud del equipo, el panel parece estar equivocado. Si se interpreta como edad de la evidencia, describe exactamente lo que sabe: la dirección de capa de enlace sigue almacenada; lo que ya no está vigente es la confirmación positiva.

Esa diferencia es el núcleo de Neighbor Unreachability Detection, NUD. La máquina no tiene por qué elegir de inmediato entre “vivo” y “muerto”. Puede conservar una pista de reenvío, degradar su confianza, esperar a que haya demanda y buscar una prueba nueva. El diseño administra conocimiento incompleto sin disfrazarlo de certeza.

Erik Nordmark figura en la historia documental de ese diseño. Es uno de los cuatro autores de RFC 4861, especificación Standards Track de Neighbor Discovery para IPv6. Es el primer autor citado de RFC 7048, escrito con Igor Gashinsky, que modifica el comportamiento cuando NUD abandona demasiado pronto. También participa en RFC 3756, documento Informational sobre modelos de confianza y amenazas. La autoría acredita trabajo dentro de un proceso colectivo del IETF; no prueba invención exclusiva, conformidad de un producto ni mando sobre la red de una operadora.

Qué confirma realmente REACHABLE

RFC 4861 define la alcanzabilidad desde el punto de vista del nodo que envía. Debe existir evidencia positiva de que el camino de ida funciona: los paquetes alcanzan la capa IP del vecino y allí son procesados correctamente. Si el vecino es un router, la afirmación incluye que reenvía como router.

El alcance es deliberadamente estrecho. No equivale a decir que una aplicación está disponible, que el camino de vuelta es simétrico, que el propietario del dispositivo es quien dice ser o que una orden produjo el efecto esperado. Habla de un siguiente salto concreto, observado durante un intervalo limitado.

Hay dos familias principales de confirmación. Una Neighbor Advertisement solicitada puede responder a una Neighbor Solicitation. Una capa superior también puede informar de progreso si su señal permite inferir que los paquetes avanzaron por el primer salto.

Por ejemplo, un ACK TCP nuevo puede mostrar que datos enviados recientemente llegaron al extremo remoto. Si la ruta pasa por el vecino del caché, eso respalda la conclusión de que el camino de ida hasta ese vecino funcionó. También la llegada de datos nuevos, no duplicados, puede indicar que confirmaciones anteriores alcanzaron al par.

La inferencia no crece porque sea útil. El ACK no identifica al vecino de capa de enlace, no acredita a la organización dueña del equipo, no demuestra que el retorno siga el mismo camino y no certifica la transacción de negocio. Una prueba de progreso de TCP puede renovar una afirmación de primer salto; no puede firmar todas las capas que la rodean.

Un caché con memoria, demanda y duda

Los cinco estados conceptuales de RFC 4861 separan problemas distintos.

INCOMPLETE indica que todavía se está resolviendo la dirección de capa de enlace. REACHABLE conserva una confirmación positiva reciente. Cuando vence el tiempo asignado a esa confirmación, la entrada pasa a STALE. No se borra la dirección. No se emite una sonda por el simple transcurso del tiempo. Solo se reconoce que la prueba envejeció.

La próxima vez que un paquete necesita la entrada, el estado cambia de STALE a DELAY. El paquete puede salir hacia la dirección conocida. El breve periodo de demora da oportunidad a una capa superior para aportar una confirmación sin generar tráfico Neighbor Discovery adicional.

Si no llega, la entrada pasa a PROBE. Se envían Neighbor Solicitations unicast a la dirección almacenada. Una Neighbor Advertisement solicitada y válida puede devolver la entrada a REACHABLE. En el algoritmo base, agotar el número de sondas lleva a borrar la entrada y repetir la selección de siguiente salto o la resolución.

La secuencia demuestra que un registro last_seen es demasiado pobre. ¿Fue visto un anuncio no solicitado? ¿Llegó un ACK TCP? ¿Respondió el vecino a una sonda? ¿Cuándo se utilizó por última vez la entrada? ¿Existía otro router elegible? Cada pregunta posee un mecanismo, una caducidad y un responsable distinto.

Un anuncio espontáneo viaja en la dirección equivocada

Una Router Advertisement o una Neighbor Advertisement no solicitada puede traer datos necesarios. Puede informar de una dirección de enlace nueva o de la presencia de un router. Sin embargo, solo demuestra que el mensaje viajó desde el vecino hasta quien lo recibe. La cuestión de NUD es si los paquetes enviados hacia el vecino recorren el camino contrario.

Por eso RFC 4861 prohíbe usar como confirmación de alcanzabilidad los Router Advertisements y los Neighbor Advertisements con el indicador Solicited desactivado. Oír una voz no demuestra que la otra persona pueda oírnos. Aprender una dirección no demuestra que el envío llegue.

Si un recolector actualiza last_reachable_at ante cualquier anuncio, una señal espontánea puede prolongar indefinidamente un estado verde. Además, el investigador ya no sabe si la transición correspondió a una sonda activa. El recibo mínimo conserva dirección del mensaje, indicador Solicited, interfaz, objetivo, cambios de dirección de enlace y estado anterior y posterior.

La automatización debe poder decir “recibí información del vecino” sin decir “confirmé el camino de ida”. Fusionar ambas frases regala autoridad a un paquete que no la contiene.

La impaciencia cambia de valor cuando no hay alternativa

RFC 7048 observa que el comportamiento típico realiza tres intentos separados aproximadamente por un segundo. Con otro router por defecto disponible, fallar rápido tiene sentido: dejar de usar al vecino silencioso permite probar una salida real.

La misma regla puede ser dañina si no existe otro vecino. Una pausa breve en Wi-Fi, un enlace que despierta despacio o una congestión transitoria puede durar más que el presupuesto. Al borrar la entrada, el nodo inicia resolución, a menudo con multicast, y pierde temporalmente la única dirección de enlace plausible. No ha encontrado redundancia; ha descartado contexto.

El cambio de RFC 7048 crea, para ese caso, un estado conceptual UNREACHABLE. La dirección de enlace se conserva y los paquetes pueden seguir enviándose. Las sondas continúan con retroceso exponencial. Eventualmente deben usar multicast, porque la dirección de enlace del vecino pudo cambiar y una cadena eterna de unicast a la dirección antigua no la descubriría.

La palabra no es un parte de defunción. UNREACHABLE dice que el mecanismo de prueba no obtuvo una confirmación, no que la implementación dejó de transmitir ni que el servicio terminó. Si aparece un siguiente salto alternativo válido, la entrada no confirmada no debería impedir seleccionarlo. Ciertas entradas creadas mediante Redirect pueden eliminarse en vez de conservarse.

No existe un temporizador universalmente prudente. La sonda paciente protege continuidad cuando no hay salida. Puede retrasar la recuperación cuando sí hay otra. La decisión exige conocer las alternativas en ese instante y dejar constancia de la política elegida.

El estado correcto puede nacer de un mensaje falso

RFC 3756 describe el límite de confianza. En enlaces donde un atacante puede inyectar Neighbor Discovery, una Neighbor Advertisement falsificada puede simular la confirmación solicitada. El caché puede apuntar a una dirección de enlace maliciosa o inexistente y mantener allí el tráfico. La máquina de estados habrá seguido su regla, pero la evidencia de entrada era hostil.

Por eso REACHABLE no significa autenticado. Tampoco una dirección IPv6 revela por sí sola a la persona, empresa, firmware o política que controla el equipo. Los controles de acceso al enlace, la criptografía, el inventario, la autorización de aplicación y los comprobantes de resultado son fuentes distintas.

Un expediente operativo debe unirlas sin sustituirlas. Para NUD conserva interfaz, dirección IP y de enlace, fuente de confirmación, secuencia de sondas, alternativas disponibles, contexto de seguridad y versión de software. Para la aplicación conserva por separado la identidad autenticada, la decisión de permiso, la versión del recurso y el resultado. “El vecino respondió” nunca debe reescribir “la acción fue autorizada”.

Crédito preciso, responsabilidad precisa

El perfil del IETF consultado el 30 de agosto de 2026 enumera 25 RFC y un rol activo de revisor en el Internet of Things Directorate para Erik Nordmark. Esos datos pueden cambiar. Las cabeceras de los documentos fijan una atribución más duradera: Thomas Narten, Nordmark, William Simpson y Hesham Soliman en RFC 4861; Nordmark e Igor Gashinsky en RFC 7048; Pekka Nikander, como editor, James Kempf y Nordmark en RFC 3756.

RFC 4861 y RFC 7048 son Standards Track. RFC 3756 es Informational. Ni la posición del nombre ni la categoría del documento prueba que una implementación haya adoptado correctamente sus reglas. El código en funcionamiento debe mostrar qué señales superiores acepta, cómo administra estados, cuándo descubre alternativas y qué deja en los registros.

La norma hace posible comparar sistemas independientes. No opera el sistema particular. Esa frontera es coherente con el propio NUD: conserva solo la afirmación que su mecanismo puede sostener y exige nuevas pruebas cuando cambia la decisión.

El vecino no quedó viejo a una hora exacta. Envejeció la evidencia de quien observaba. Esa frase, menos dramática, es mucho más útil para decidir.

Fuentes