Resumen

  • Un host con gateway predeterminado podía alcanzar su destino y, sin embargo, cruzar dos veces la misma red local: primero hacia G1 y después de G1 al siguiente salto G2. ICMP Redirect permitía que G1 reenviara el paquete inicial y sugiriera a ese host el atajo.
  • El mensaje no era un protocolo de enrutamiento en miniatura. El receptor debía reconocer al emisor como su primer salto vigente, comprobar que la alternativa pertenecía al enlace de llegada y guardar sólo una excepción específica para el destino.
  • IPv6 hizo visible el perímetro local mediante origen link-local, Hop Limit 255 y límites sobre el objetivo. SEND podía autenticar al emisor dentro de una cadena de confianza, pero no demostrar que la ruta fuese universalmente óptima ni quién era dueño del destino.

El desvío que funcionaba

La ruta predeterminada resolvía un problema de escala. Un host no necesitaba conocer cada red exterior ni participar en las conversaciones entre routers. Si no encontraba una ruta más precisa, entregaba el datagrama a G1 y dejaba que la infraestructura decidiera el resto.

La separación está en el diseño original de IP. RFC 791 distingue nombres, direcciones y rutas, y describe un sistema donde hosts y gateways toman decisiones sucesivas. Conocer la dirección de X no obliga a H a poseer la misma vista topológica que G1.

Esa economía podía producir un triángulo. H y dos gateways, G1 y G2, compartían una red local. H enviaba a G1 porque era su opción predeterminada. G1 sabía que el camino hacia X comenzaba realmente por G2, también visible en ese enlace. El primer paquete recorría H–G1–G2; funcionaba, pero el tramo local se repetía sin necesidad.

RFC 792 convirtió esa observación en un mensaje ICMP. G1 reenviaba el datagrama y devolvía a H un Redirect que nombraba a G2. El consejo no reparaba un fracaso: optimizaba una entrega que ya había tenido éxito.

Ese detalle explica su rareza histórica. Muchos mensajes de control anuncian que algo salió mal. Redirect, en cambio, decía que el sistema había podido cumplir la petición y que la próxima vez el remitente podía elegir mejor. Era memoria derivada de una experiencia concreta.

Una prueba pegada al paquete

El mensaje incluía la dirección del gateway recomendado y citaba el datagrama que lo había provocado: la cabecera IP original más los primeros 64 bits de sus datos. Esa cita permitía al host relacionar el consejo con tráfico que acababa de emitir.

No era una demostración completa de la topología. Los bytes citados no revelaban las políticas de otros dominios, el estado futuro del enlace ni la titularidad de X. Su valor era más modesto: vinculaban una recomendación con una observación y ofrecían material para encontrar la conversación afectada.

Los códigos distinguían redirects para red, host, tipo de servicio y sus combinaciones. La taxonomía sugería diferentes anchuras de alcance, pero la anchura de una afirmación debía corresponder a lo que el receptor podía validar. Una observación de un solo datagrama era una base débil para entregar autoridad sobre una red entera.

Por eso RFC 1122 exigió que el host comprobara dos relaciones antes de aceptar el mensaje. La nueva dirección debía estar en la misma subred lógica por la que había llegado el Redirect. Además, la fuente del Redirect debía ser el gateway de primer salto que el host estaba utilizando para ese destino.

La segunda condición es decisiva. No pregunta simplemente si el emisor parece un router. Pregunta si H había confiado ese tráfico precisamente a G1. La autoridad nace de la relación previa: G1 puede comentar un paquete que H le entregó; un vecino arbitrario no recibe el mismo derecho.

Una excepción para X, no un mapa nuevo

La recepción válida terminaba en un cache de rutas o de destinos del host. No convertía al host en participante del protocolo de enrutamiento ni reemplazaba su gateway predeterminado para todo el mundo.

RFC 1122 ordenó tratar incluso un Network Redirect como información específica del host. El receptor normalmente no podía conocer la máscara correcta de una red remota y, por tanto, no debía extrapolar la observación a un prefijo que quizá no existiera como imaginaba. La entrada estrecha reducía el poder que podía obtener un solo mensaje.

Esto también hacía temporal el saber. Una excepción aprendida debía poder caducar, ser reemplazada o dejar paso otra vez a la ruta predeterminada. Sin una salida, un consejo verdadero ayer se convertía en una orden falsa mañana.

La distinción entre descubrimiento y selección quedó más clara con RFC 1256. Router Solicitation y Router Advertisement permitían descubrir routers predeterminados del enlace, sus preferencias y su vigencia. El propio RFC advertía que aquello no era un protocolo de enrutamiento.

Descubrir candidatos responde «¿qué routers puedo usar como salida?». Redirect responde «para este destino y después de este paquete, considera este vecino». Confundir las dos preguntas infla una pista concreta hasta convertirla en política general.

El router no debe obedecer a su propio consejo

Lo que resulta útil para un host sencillo puede ser peligroso dentro del plano de control. RFC 1812 dice que un router que usa un protocolo de enrutamiento no debe considerar rutas aprendidas por Redirect al reenviar paquetes.

Un router ya dispone de otro mecanismo para intercambiar pruebas de alcance y reaccionar a cambios. Si incorporara consejos destinados a hosts, una observación local podría esquivar métricas, políticas y prevención de bucles. El atajo dejaría de ser una optimización de borde y competiría con la constitución del enrutamiento.

El mismo documento restringe la emisión. El paquete se reenvía por la misma interfaz física por la que llegó; el siguiente salto se encuentra en la misma subred lógica que la fuente; y no se especificó una ruta de origen. Las condiciones reconstruyen el triángulo H–G1–G2. Fuera de él, la explicación «podías haber hablado directamente con ese vecino» pierde fundamento.

La regla no afirma que G2 sea el mejor camino para siempre. Afirma que G1, al procesar ese paquete, vio una alternativa local que satisfacía su tabla. La optimización conserva sentido sólo mientras se mantiene esa geometría.

IPv6 hizo comprobable el borde

IPv6 mantuvo Redirect dentro de Neighbor Discovery. Según RFC 4861, un router puede indicar un mejor primer salto o señalar que el destino está directamente on-link. En ambos casos, la semántica sigue limitada al enlace.

El receptor exige una dirección de origen link-local y un Hop Limit de 255. Como los routers decrementan el límite al reenviar, un mensaje recibido con 255 aporta evidencia de que no cruzó un router. También se comprueba que la fuente sea el primer salto vigente para el destino y que la dirección de destino del Redirect no sea multicast.

El objetivo debe ser una dirección link-local del router recomendado o coincidir con la dirección de destino cuando ésta es un vecino. Estas relaciones no prueban bondad global, pero convierten «local» en propiedades observables del paquete y del estado del host.

Al aceptar el mensaje, el host actualiza su Destination Cache. La opción Redirected Header vuelve a citar el paquete causante, mientras Target Link-Layer Address puede alimentar el Neighbor Cache. Son estados relacionados, no una licencia para reescribir la tabla de enrutamiento de un router.

Autenticar no significa coronar

El enlace local no es automáticamente confiable. Un atacante capaz de aparentar ser el primer salto puede intentar cambiar el vecino elegido por el host. El problema es incómodo porque el host necesita información local antes de alcanzar servicios externos que podrían ayudarle a validarla.

RFC 3971 diseñó Secure Neighbor Discovery, SEND, con direcciones generadas criptográficamente, firmas y certificados vinculados a anclas de confianza. Su objetivo es autenticar mensajes de Neighbor Discovery y autorizar routers dentro del modelo configurado.

SEND no convierte una identidad autenticada en un oráculo de rutas. Una firma puede demostrar quién produjo el mensaje y que éste no cambió; una cadena puede demostrar la autorización respecto de un ancla. Ninguna de las dos demuestra que G2 seguirá disponible, que el trayecto cumple todas las políticas o que el emisor posee X.

Tampoco puede suponerse despliegue universal. La presencia, ausencia o rechazo de SEND es una propiedad que debe observarse en el entorno concreto. La historia del estándar describe una posibilidad de seguridad, no un censo de configuraciones actuales.

Una autoridad de una sola arista

Redirect prosperó como una idea pequeña porque su legitimidad podía expresarse con una cadena corta. H eligió a G1. G1 observó el paquete, lo reenvió y vio a G2 en el mismo enlace. G1 citó ese paquete y propuso la alternativa. H comprobó la relación y decidió si instalaba una entrada limitada.

Cada verbo asigna una responsabilidad. El host conserva la decisión; el primer salto sólo aconseja; el protocolo de enrutamiento sigue siendo la fuente de pruebas entre routers; el cache conserva el resultado durante un tiempo controlado.

Cuando falta un eslabón, la interpretación debe encogerse. Un Redirect capturado prueba que se envió una propuesta. No prueba que el host la aceptó. Una entrada de cache prueba una decisión local, no la existencia de un derecho sobre el destino. Un camino más corto en saltos no prueba que sea el mejor según coste, seguridad o política.

La lección no es que todo Redirect sea bueno o malo. Es que la autoridad técnica puede ser proporcional al hecho que la originó: un paquete, un primer salto, un enlace y un destino. El mecanismo resulta inteligible cuando no pretende saber más.