Resumen

  • RFC 4950 define un objeto de pila de etiquetas MPLS para determinados mensajes ICMP multipartitos. Se aplica a ICMPv4 e ICMPv6 y usa la estructura de extensión y los encabezados de objeto de RFC 4884.
  • El LSR puede incluir la pila tal como llegó al router que informa, conservando el encabezado IP original y los octetos iniciales de la carga útil. El objeto puede acompañar a Time Exceeded y Destination Unreachable.
  • Un traceroute mejorado puede mostrar los nodos visitados y el estado de encapsulación MPLS del datagrama original en cada nodo que responde, sujeto a soporte, política, filtrado y comportamiento TTL.

El mecanismo operativo resuelve una omisión concreta. Si un datagrama encapsulado en MPLS no puede entregarse y un LSR genera un error aplicable, el ICMP normal puede informar del datagrama IP expuesto, pero no de las etiquetas que participaron en el reenvío. RFC 4950 añade un objeto de extensión RFC 4884 con la pila entrante completa. No elimina la información ICMP original: deben conservarse el encabezado IP original y los octetos iniciales de la carga útil.

Cada entrada de la pila ocupa exactamente cuatro octetos. Según la descripción de RFC 4950, contiene una etiqueta de 20 bits, tres bits de uso experimental denominados así en el texto de 2007, un bit de fondo de pila y un TTL de ocho bits. Esos campos describen lo que recibió el router que envía el informe. No son una orden de reparación, una autorización de ruta o de LSP, una autenticación, una concesión de acceso ni una prueba criptográfica. Una etiqueta divulgada no concede permiso para cambiar el reenvío ni demuestra propiedad, intención o cumplimiento de una política.

El primer elemento de verificación es una captura de paquetes que conserve el tipo y código ICMP, el encabezado de extensión RFC 4884, el objeto de pila MPLS y su encabezado de objeto. Hay que decodificar cada entrada de cuatro octetos, registrar etiqueta, bits experimentales, bit de fondo y TTL, y guardar por separado el encabezado IP citado y la carga útil inicial. Después conviene comparar la captura con una respuesta ICMP clásica y con las observaciones de traceroute en el mismo punto. Así se delimita la evidencia observada sin convertirla en una afirmación sobre todo el camino.

El segundo elemento es una matriz controlada. Cuando la política lo permita, variar destino, vida útil solicitada de la sonda y profundidad de la pila entrante. Para cada respuesta, anotar si es Time Exceeded o Destination Unreachable, si aparece el objeto, cuántas entradas devuelve y si el filtrado o un equipo intermedio cambia el resultado. Cada resultado sigue siendo una observación local del router que informa. No prueba el camino completo de extremo a extremo, la causa raíz ni que todos los saltos hayan entregado información equivalente.

RFC 4950 no define la relación general entre MPLS e ICMP ni la manipulación del TTL específica de una encapsulación. Por ello, el comportamiento TTL relacionado con RFC 3032 influye en lo que puede observarse con traceroute, pero esta extensión no elige el modelo TTL. Un procedimiento capaz de ocultar el traceroute básico también puede ocultar el mejorado. La afirmación del RFC sobre un despliegue ampliamente extendido pertenece a su contexto histórico; no demuestra cobertura actual universal, valores predeterminados comunes entre fabricantes, uniformidad entre implementaciones ni políticas actuales de divulgación.

Los operadores pueden divulgar selectivamente la información MPLS según su política, por ejemplo por dirección de destino, configuración global o profundidad de la pila entrante. Es una decisión operativa, no una garantía del protocolo. La ausencia del objeto no demuestra que el paquete no estuviera encapsulado en MPLS: el soporte, la política, el filtrado, la compatibilidad y el TTL pueden suprimir la observación.

Fuentes