Resumen

  • Neighbor Discovery formaba una lista de routers por defecto, pero no decía cuál servía mejor a Internet ni qué otro atendía solo un prefijo concreto.
  • RFC 4191 añadió preferencias Alta, Media y Baja y una Route Information Option con vida limitada. El host completo aplicaba primero el prefijo más largo, después la preferencia entre iguales y anteponía el alcance conocido al rango anunciado.
  • La información era una recomendación local, no una métrica, autenticación u orden. El router no debía volcar su tabla completa y el host podía ignorar o sustituir los valores.

Routers alcanzables para destinos distintos

RFC 2461 construía Prefix List y Default Router List a partir de Router Advertisements. Para un destino fuera del enlace, el host elegía un primer salto de la lista.

Un equipo con Ethernet, Wi-Fi, túnel corporativo y red aislada podía tener varios routers vivos que no eran intercambiables. La detección de vecinos apartaba al caído, pero no explicaba que uno llegaba a Internet y otro solo al laboratorio. Redirect corregía dentro de un enlace; no podía trasladar la elección a otra interfaz.

Tres rangos que no eran una métrica

RFC 4191, de noviembre de 2005, utilizó dos bits para Alta, Media y Baja; el cuarto patrón quedó reservado. Tres niveles reforzaban que el campo no medía coste, latencia ni ancho de banda globalmente comparables.

La persona que conocía la topología debía configurarlos. No se debían derivar automáticamente de métricas internas. Con Router Lifetime cero, la preferencia de cabecera se ignoraba: retirarse como default anulaba el rango.

La opción 24 entregó pocas rutas

Route Information Option lleva longitud de prefijo, preferencia, vida y prefijo. Un túnel puede anunciar solo la red privada y otra interfaz conservar el default público. Una opción ::/0 puede sustituir la preferencia y vida de cabecera para el host completo.

Vida cero elimina la ruta de ese siguiente salto; todos unos significa infinito. Aun así, el mensaje no prueba propiedad, autoridad global ni seguridad: solo afirma durante un intervalo que el router puede servir de primer salto para ese rango.

El RFC desaconseja anunciar por defecto, volcar la tabla y superar diecisiete opciones por RA y enlace. La frontera era deliberada: llevar al host el pequeño conjunto útil, no replicar el plano de control del router.

El prefijo más largo habló primero

Type A ignora la extensión; Type B entiende la preferencia default; Type C usa también las rutas. Type C busca el prefijo coincidente más largo y solo usa Alta, Media o Baja entre prefijos de la misma longitud. Una ruta estrecha Baja vence al default Alta dentro de su rango.

Después manda la evidencia de alcance. Si el primer salto es conocido como inalcanzable, el host examina otro; si no sabe nada, lo presume alcanzable de forma provisional. Los cambios invalidan Destination Cache y obligan a recalcular. La configuración local también puede sustituir la preferencia recibida.

El router propone y el host observa. Dos bits no pueden inventar una comprobación satisfactoria.

Recuperación con demanda real

Al evitar un router preferible, el host necesita detectar su regreso. Solo debe sondearlo cuando exista tráfico útil que habría enviado por él y como máximo una vez por minuto. La preferencia justifica el interés, el tráfico justifica el coste y NUD aporta el hecho.

No exportar cada oscilación

Una ruta anunciada puede depender de estado dinámico, pero la implementación debe aislar al host de las oscilaciones internas. Un flap copiado a miles de cachés amplifica invalidaciones y cálculos. Al cesar una interfaz con Router Lifetime cero, también deberían caducar sus opciones específicas.

Una mentira específica puede pasar desapercibida

RFC 3756 documentó RA y Redirect falsificados. RFC 4191 permite atraer todo el tráfico con Alta o solo destinos sensibles con una ruta estrecha. Lo segundo puede ser menos visible. La opción no firma al emisor ni acredita su derecho sobre el prefijo.

Una vida infinita prolonga la influencia, no la convierte en verdad. Admitir al hablante y decidir qué significa su mensaje siguen siendo controles distintos.

La dirección origen añadió otra condición

RFC 8028 trató en 2016 redes con varios prefijos de proveedor. Un paquete con origen del proveedor A enviado por B puede caer en un filtro de ingreso, firewall con estado o uRPF.

El host debe relacionar el prefijo origen con el router que lo anunció. La mejor ruta de destino puede ser el egreso equivocado para ese origen. RFC 4191 resolvía una pregunta limitada; no pretendía resolver el estado de retorno.

Fuentes y límites

El modelo inicial procede de RFC 2461 y la revisión de ND de RFC 4861. Preferencias, RIO, tipos A/B/C, selección, sondeo y límites son de RFC 4191. Las amenazas están en RFC 3756 y la asociación origen–primer salto en RFC 8028.

No miden despliegue actual, valores por defecto ni recuperación universal, ni prueban que una ruta sea autorizada o globalmente cierta. El logro histórico fue una pequeña gramática temporal con decisión local.