Resumen

  • Neighbor Unreachability Detection de IPv6 exigía confirmación reciente del camino de ida. Al envejecer esa confirmación, la entrada pasaba a STALE, pero el protocolo no la borraba ni generaba tráfico hasta que alguien volvía a utilizarla.
  • El primer envío abría DELAY para que TCP u otra capa superior demostrara progreso; solo la falta persistente de prueba llevaba a PROBE. RFC 7048 añadió UNREACHABLE y retroceso exponencial para no confundir un cambio de preferencia con el abandono definitivo del vecino.

La tabla no era un censo de vivos y muertos

Una entrada de vecinos reúne una dirección IPv6, una dirección de enlace y un estado. Es tentador leer REACHABLE como viva y STALE como muerta. La máquina original de Neighbor Discovery evitó esa simplificación desde RFC 1970, publicado en 1996.

STALE decía que había transcurrido ReachableTime desde la última confirmación positiva del camino. Nada más. El vínculo almacenado no había sido refutado y ni siquiera tenía que comprobarse si ninguna aplicación deseaba usarlo. RFC 2461 conservó ese modelo en 1998 y RFC 4861 lo convirtió en la referencia de 2007.

La decisión reducía trabajo inútil. Desde el punto de vista de la corrección, una entrada antigua podía permanecer indefinidamente mientras estuviera ociosa. La memoria podía exigir recolección por otra política, pero el mero silencio no obligaba a emitir Neighbor Solicitations ni a reconstruir una asociación que todavía no afectaba ningún paquete.

La prueba tenía dirección

NUD no preguntaba si el vecino había dicho algo recientemente. Preguntaba si un paquete enviado hacia él había alcanzado su capa IP. Esa diferencia descartaba dos señales seductoras: una Router Advertisement y una Neighbor Advertisement no solicitada llegaban desde el vecino, pero solo demostraban el trayecto inverso.

La confirmación válida podía nacer de una Neighbor Advertisement solicitada. La solicitud había llegado al objetivo y su respuesta había vuelto. También podía proceder de una capa superior capaz de demostrar que la comunicación avanzaba.

TCP daba ejemplos concretos. Un ACK nuevo solo podía reconocer datos que el receptor había recibido. Datos nuevos, no duplicados, también podían implicar que los ACK anteriores llegaron al otro extremo. Para un destino remoto, ese progreso demostraba que el router de primer salto había transportado tráfico reciente. Protocolos sin ese diálogo, o un router que simplemente reenvía paquetes, debían recurrir a sondas.

Era una prueba operacional, no una identidad. No garantizaba que el vecino seguiría disponible, que el servicio remoto estuviera sano ni que la dirección de enlace perteneciera jurídicamente a nadie. Su alcance era suficiente y estrecho: mantener una decisión local de reenvío.

El tráfico ordinario recibía la primera oportunidad

La transición de REACHABLE a STALE podía ocurrir al expirar el tiempo o diferirse hasta el siguiente envío. Cuando ese envío llegaba, el nodo empleaba la dirección de enlace almacenada y cambiaba a DELAY. El valor predeterminado de esa espera era cinco segundos.

DELAY evitaba preguntar dos veces. Después de una pausa, el inicio de una conexión TCP podía ofrecer enseguida el progreso que NUD necesitaba. Si aparecía la confirmación, la entrada retornaba a REACHABLE y no se enviaba ninguna sonda adicional.

Si la espera terminaba sin prueba, el nodo enviaba una Neighbor Solicitation unicast y entraba en PROBE. Unicast tenía sentido porque la asociación ya se conocía; se estaba comprobando ese camino. Multicast pertenecía a la fase en que la dirección de enlace debía descubrirse de nuevo.

La secuencia convertía el uso en prioridad. El tiempo rebajaba la confianza. Un paquete hacía relevante la duda. DELAY esperaba evidencia gratuita. PROBE pagaba el coste de una comprobación explícita solo cuando las tres condiciones coincidían.

Los valores predeterminados también evitaban marchar al unísono

RFC 4861 fijó como constantes de referencia una base alcanzable de 30 segundos, un segundo entre retransmisiones, cinco segundos antes de la primera sonda y tres solicitudes unicast. Sin embargo, ReachableTime se calcula aleatoriamente entre 0,5 y 1,5 veces la base. Las Router Advertisements pueden anunciar valores no nulos para la base y la retransmisión.

La aleatoriedad reduce el riesgo de que muchos equipos compartiendo enlace comiencen a verificar vecinos en la misma cadencia. También muestra por qué “30 segundos” no describe una caducidad universal.

Una Router Advertisement podía modificar el reloj, pero no confirmaba el camino. El protocolo separó la influencia sobre el parámetro de la evidencia sobre el funcionamiento: poder sugerir la duración no daba al router poder para declararse alcanzable.

Una respuesta rápida podía multiplicar el problema

Según la máquina original de RFC 4861, PROBE repetía solicitudes unicast y, tras el límite configurado, descartaba la entrada. Con los valores predeterminados, tres transmisiones separadas por un segundo bastaban para abandonar la asociación. El siguiente salto podía recalcularse o la resolución multicast comenzar de nuevo.

Con dos routers, la rapidez era valiosa. Con uno solo, una interrupción transitoria de capa 2 podía durar más que esa ventana. Borrar la entrada no creaba una ruta alternativa; cambiaba solicitudes dirigidas por descubrimiento multicast y hacía más ruidoso un enlace que intentaba recuperarse.

RFC 6583 documentó el coste de esa dinámica desde otro ángulo. En una subred IPv6 /64, solicitudes hacia innumerables direcciones inexistentes podían desbordar el proceso NDP. Si esa carga impedía responder a sondas o actualizar entradas en uso, el sistema perdía vecinos legítimos, lanzaba más resolución multicast e interrumpía flujos existentes. Por eso recomendó priorizar NUD, que trabaja sobre destinos activos, frente a la creación especulativa de entradas.

En 2014, RFC 7048 declaró que NUD era demasiado impaciente. Su actualización añadió el estado conceptual UNREACHABLE. Después del umbral, el vecino dejaba de contar como conocido alcanzable para elegir ruta, pero la entrada podía conservar su dirección de enlace. Los paquetes podían seguir utilizándola si no había salida mejor, mientras las sondas continuaban con retroceso exponencial.

En algún momento las solicitudes debían pasar a multicast para detectar una dirección de enlace cambiada. Si ya no se enviaban paquetes por la entrada, las sondas podían detenerse. El algoritmo de ejemplo proponía intentos acumulados a 1, 4, 13 y 40 segundos y un máximo posible de 60 segundos. Era una forma válida de implementar la corrección, no una encuesta de equipos desplegados.

UNREACHABLE no era una tumba

El nuevo estado permitió responder de manera distinta a dos preguntas. ¿Debe preferirse otro router? ¿Debe cesar toda recuperación del vecino anterior? La primera puede requerir velocidad; la segunda depende de que exista una alternativa real.

El retroceso exponencial mantiene la posibilidad de recuperar el único camino sin generar una tormenta constante. Al mismo tiempo, marcar la entrada como no conocida alcanzable permite que el algoritmo de primer salto pruebe otra opción. Un mismo fracaso observado ya no obligaba a una única consecuencia.

La definición de confirmación permaneció intacta. Progreso superior o una respuesta solicitada devolvían REACHABLE. Un anuncio espontáneo seguía sin demostrar el camino de ida. RFC 7048 modificó la estrategia tras el fracaso, no rebajó la calidad de la evidencia.

DAD y NUD compartían paquetes, no propósito

RFC 4862 usa Neighbor Solicitation y Neighbor Advertisement para Duplicate Address Detection. DAD actúa antes de asignar una dirección unicast y busca otro reclamante de una dirección tentativa. NUD actúa sobre un vecino ya usado y busca confirmación del camino asociado a la caché.

El silencio limitado de DAD puede permitir que una dirección deje de ser tentativa. En NUD, el silencio envejece la confianza y solo el tráfico inicia la escalada. Confundirlos transforma una coincidencia de formato en una equivalencia de autoridad que los RFC nunca concedieron.

Fuentes y límites

La historia y los estados proceden de los RFC 1970, 2461 y 4861. RFC 4862 marca el límite con DAD; RFC 6583 aporta el problema operacional; RFC 7048 actualiza la recuperación. Estos textos no demuestran configuraciones actuales de fabricantes, adopción, tamaños de tabla, tasas de fallo ni conformidad de una red concreta.