Resumen

  • RFC 4861 terminaba la secuencia de detección con la eliminación de la entrada después del número configurado de sondas sin respuesta.
  • RFC 7048 creó UNREACHABLE: se pueden preferir otros vecinos mientras la dirección de enlace se conserva y las nuevas búsquedas usan multicast y retroceso exponencial.

El coste de olvidar demasiado pronto

Neighbor Unreachability Detection no consulta continuamente a cada vecino. Una confirmación positiva puede ser el progreso indicado por una capa superior o una Neighbor Advertisement solicitada. Una entrada usada pasa normalmente por REACHABLE, STALE, DELAY y PROBE. Solo PROBE envía Neighbor Solicitations unicast a la dirección de enlace guardada.

En el modelo de RFC 4861, alcanzar el límite de retransmisiones sin respuesta borraba la Neighbor Cache Entry. RFC 7048 presenta como valores habituales tres transmisiones separadas por un segundo. Ese desenlace era conveniente cuando existía otro router predeterminado o cuando una entrada creada por Redirect podía descartarse para rehacer la selección del siguiente salto.

El problema aparecía sin alternativa. Borrar la entrada no inventa otro camino: el siguiente tráfico debe resolver de nuevo la dirección y puede generar solicitaciones multicast repetidas durante una avería transitoria de capa 2.

UNREACHABLE no significa que el camino funcione

RFC 7048 cambia el punto terminal. En vez de eliminar la entrada, el nodo aumenta el tiempo de retransmisión, envía una Neighbor Solicitation multicast y entra en UNREACHABLE. La entrada ordinaria conserva la dirección de enlace y los paquetes IPv6 pueden seguir dirigiéndose allí. Sin embargo, el vecino no cuenta como «conocido como alcanzable», por lo que la selección puede preferir una alternativa.

Las entradas creadas por Redirect reciben un trato distinto: pueden eliminarse y no deberían usarse para transmitir mientras estén UNREACHABLE. Además, la recolección de basura sigue permitida, incluso puede dar prioridad a estas entradas.

Preguntar a más vecinos con menor frecuencia

La búsqueda debe pasar a multicast dentro de los 60 segundos posteriores a la retransmisión inicial, incluso si las primeras solicitudes UNREACHABLE fueron unicast. Así puede responder un vecino cuya dirección de enlace haya cambiado. Las retransmisiones posteriores deben usar retroceso exponencial, con un máximo razonable, por ejemplo 60 segundos. Si deja de haber tráfico, deben detenerse hasta que vuelva a usarse la entrada o sea recolectada.

Los temporizadores de ejemplo de RFC 7048 ilustran una política; no fijan un calendario idéntico para todas las implementaciones. RFC 6583 añade el contexto de operación: resolver grandes cantidades de direcciones no asignadas puede agotar colas y cachés de Neighbor Discovery. No define la transición a UNREACHABLE.

La innovación histórica fue separar dos decisiones: dejar de preferir un vecino y destruir la última evidencia de su mapeo. La segunda ya no es automática.

Fuentes