Resumen

  • RFC 1393 creó la opción IPv4 82 y un mensaje ICMP específico para que cada router declarara su salto, la velocidad del enlace de salida y la MTU.
  • Ahorrar sondas en el origen exigía trabajo nuevo en todos los saltos; la propuesta nunca se desplegó ampliamente, pasó a Historic y hoy se recomienda filtrarla.

Un solo paquete, muchas postales

El traceroute convencional aprovecha ICMP Time Exceeded, una respuesta que los routers ya necesitaban producir cuando se agotaba el TTL. El emisor prueba TTL 1, 2, 3 y reconstruye el trayecto. RFC 1393 objetaba el coste aproximado de 2n paquetes, la repetición de los saltos cercanos, los cambios de ruta entre sondas y la falta de visibilidad directa del regreso.

La alternativa introducía el tipo 82: bit de copia cero, clase 2 de depuración y medición, número de opción 18. Dentro viajaban un identificador elegido por el origen, contadores de ida y vuelta y la dirección IPv4 a la que debían responder los routers. El identificador no era el campo Identification de IPv4.

El origen iniciaba la ida en cero y colocaba 0xFFFF en el contador de vuelta. Cada router compatible debía incrementar el contador correspondiente, enviar un ICMP Traceroute al origen e incluir la velocidad y la MTU del enlace de salida, con valor cero cuando no pudiera determinarlas. El paquete marcado debía conservar la ruta que habría seguido sin la opción.

Si el destino copiaba la opción en su respuesta y ponía a cero el contador de vuelta, también podía observarse el camino inverso. Así nacía la promesa de n+1 paquetes. Pero los contadores no eran TTL: solo avanzaban cuando un router emitía el informe. Una ausencia, por tanto, era un hueco de evidencia, no prueba de un trayecto más corto.

El coste cambió de dueño

La reducción de trabajo en el emisor trasladaba obligaciones al plano de reenvío. RFC 1393 admitía que los routers necesitaban código nuevo y no trataba la seguridad. RFC 7126 señaló después que el procesamiento especial y la generación de ICMP en cada salto podían explotarse para agotar CPU.

RFC 6814 cerró el experimento: la opción nunca tuvo despliegue amplio en Internet pública, RFC 1393 quedó obsoleto y su estado pasó a Historic. RFC 7126 afirma que bloquear el tipo 82 no tiene impacto operativo ni de interoperabilidad y recomienda que routers, pasarelas de seguridad y cortafuegos descarten esos paquetes.

La necesidad de medir rutas sobrevivió. Lo que no prosperó fue una arquitectura cuya ventaja requería que todos los equipos del camino ofrecieran un servicio adicional.

Fuentes