Resumen
- LSRR y SSRR incluían direcciones intermedias en la cabecera IPv4 para que los sistemas participantes pudieran procesarlas.
- Las normas posteriores conservaron el formato, pero hicieron que el reenvío de origen no local estuviera desactivado por defecto y recomendaron descartar esas opciones.
La dirección de destino de IPv4 no siempre era el destino final de la siguiente decisión de reenvío. Cuando el paquete alcanzaba la dirección indicada allí, la opción podía presentar otra. El sistema que aceptaba participar sustituía el destino por la siguiente dirección, escribía la dirección de su interfaz de salida en el espacio liberado y adelantaba el puntero cuatro octetos. La ruta viajaba dentro del paquete y podía cambiar en cada salto.
LSRR, opción 131, permitía usar el enrutamiento normal entre los puntos enumerados. SSRR, opción 137, exigía que el siguiente punto fuera directamente alcanzable. Ambas opciones tenían longitud, puntero y espacios para direcciones; sus campos debían validarse antes de usarse. El indicador de copia hacía que acompañaran a todos los fragmentos, mientras que el límite de 60 octetos de la cabecera IPv4 restringía el tamaño de la lista.
Nada de esto convertía la propuesta del remitente en una orden universal. Cada sistema podía aplicar sus filtros y políticas. SSRR podía fallar cuando el siguiente salto no estaba en una red directamente conectada. Las direcciones registradas mostraban qué sistemas habían procesado la opción, no una prueba autenticada de todo el camino.
RFC 1122 trasladó parte de la cuestión al administrador del host. Un equipo podía actuar como salto intermedio, pero el reenvío de origen no local debía tener un interruptor de desactivación y ese interruptor debía comenzar desactivado. También seguían aplicándose las reglas de filtrado de las pasarelas. Un fallo de una ruta incompleta podía notificarse mediante ICMP Destination Unreachable, código 5, Source Route Failed.
RFC 6274 describió riesgos como eludir controles de enrutamiento, alcanzar sistemas por una interfaz inesperada, revelar topología y forzar recorridos innecesarios. También exigió prudencia al analizar la longitud y el puntero antes de leer o escribir una dirección. Su recomendación fue descartar LSRR y SSRR por defecto, manteniendo una activación explícita para entornos que realmente necesitaran la función, incluidos algunos casos de diagnóstico o peering.
RFC 7126 convirtió esa evaluación en tres políticas distinguibles: descartar el paquete, ignorar la opción y reenviar normalmente, o procesarla conforme a RFC 791. Para ambas opciones, el valor predeterminado recomendado era «drop» y debía documentarse. Ignorar no significa descartar: el paquete puede seguir hacia un equipo distinto del que el remitente esperaba en ese punto.
La historia termina con una pérdida de confianza predeterminada, no con la eliminación de la función. El enrutamiento por origen sigue formando parte de IPv4, pero su sintaxis ya no implica cooperación automática de la red.
Fuentes
Informe para miembros
Contexto ampliado del perfil
Inicia sesión con el nivel de membresía adecuado para desbloquear el informe completo y las notas de las fuentes.
Solo para Strategic Circle
Strategic Circle
Abierto a todos los lectores. Desbloquea informes de perfil después de unirte e iniciar sesión.
Únete a Strategic CircleSolo para Leadership Alliance
Leadership Alliance
Para propietarios y directivos cualificados de activos de propiedad intelectual; inicia sesión para desbloquear los informes de la alianza.
Unirse a Leadership Alliance
