Resumen

  • La pila MPLS incluida en el error describe el estado de llegada, no la transformación de salida ni una configuración consultada más tarde.
  • El objeto conserva un contexto de reenvío que la cita del datagrama IP podía omitir después de retirar las etiquetas.
  • La estructura común mejora el diagnóstico, pero la compatibilidad de los lectores, el TTL y la divulgación siguen delimitando lo que puede observarse.

Antes no significa después

Un router puede recibir una pila de etiquetas, consultar la superior y decidir sustituirla, retirarla o añadir otras. Cada momento tiene un estado distinto. Mostrar una sola pila sin decir a cuál de esos momentos pertenece deja abierta una ambigüedad decisiva.

La RFC 4950, publicada en agosto de 2007, escogió un instante concreto para el objeto MPLS que añadía a ICMP: la pila tal como llegó al router que genera el error. Un único objeto representa la pila completa, en ese orden y con ese formato.

La elección impide varias reconstrucciones demasiado cómodas. El informe no muestra por sí solo qué pila habría salido después de una operación satisfactoria. No equivale a leer la configuración vigente cuando el analista abre el archivo. Tampoco describe todos los paquetes que pasaron por el mismo lugar.

Es una instantánea delimitada. Su utilidad depende de mantener el límite, no de borrarlo para que la pantalla parezca una explicación total.

Una instantánea que antes se perdía

El problema se producía al preparar el error. Según la introducción de la RFC 4950, un router de conmutación de etiquetas que recibe un datagrama MPLS imposible de entregar retira la pila completa y deja a la vista el datagrama IP. Este pasa al tratamiento de errores.

Una respuesta ICMP puede incluir el motivo del fallo, la cabecera IP y los primeros octetos de la carga original. La cita puede ser fiel. Sin embargo, falta la pila que rodeaba al paquete cuando llegó, aunque esa era la información que el router habría utilizado para reenviarlo.

No se trataba necesariamente de una falsedad en el informe. Era una selección incompleta de la evidencia para la pregunta que se quería responder.

La extensión recomienda incluir la pila en determinados errores y exige conservar también la cabecera IP y el comienzo de la carga. La información nueva no sustituye a la cita anterior: ambas relacionan aspectos diferentes del suceso.

La cita ayuda a reconocer la comunicación afectada. La pila permite examinar el contexto de reenvío de ese paquete al entrar en el punto que responde.

El límite original de la cita

La RFC 792, de septiembre de 1981, definía para Time Exceeded la cabecera de Internet y los primeros 64 bits de los datos del datagrama original. Esos ocho octetos contribuían a asociar el error con el proceso adecuado. En protocolos que usaban puertos, se suponía que sus números estaban en esa parte inicial.

La finalidad no era registrar todos los estados de cada equipo intermedio. Era dar a la fuente información suficiente para reconocer a qué comunicación se refería el aviso. Tampoco cabe convertir ese formato histórico en una regla según la cual todas las versiones posteriores de ICMP citarían siempre exactamente ocho octetos de carga.

MPLS planteaba una ausencia que no se arreglaba citando más datos IP. La pila se encontraba antes de la cabecera IP y ya había sido retirada. La parte que faltaba no era simplemente la continuación de la cita.

La RFC 3032, de enero de 2001, sitúa las entradas de etiquetas entre las cabeceras de enlace y la cabecera de red. Cada entrada ocupa cuatro octetos; la superior aparece primero y el bit S marca la última. La consulta de la etiqueta superior determina el siguiente salto y una operación sobre la pila.

Por eso el estado de entrada aporta algo que no estaba necesariamente en la descripción IP. Conserva una parte del mecanismo que condicionaba el reenvío.

Valores que necesitan un lugar

La etiqueta no tiene un significado mundial por el mero hecho de poder imprimirse como un número. La RFC 3031 la define como un identificador de significado local para una clase de equivalencia de reenvío. No es una codificación de la dirección IP de destino.

Dos valores iguales en dos routers no demuestran una misma identidad permanente. Hacen falta el espacio de etiquetas correspondiente y la asociación local. Del mismo modo, un trayecto puede emplear valores distintos a medida que cambia el contexto de reenvío.

La RFC 4950 registra una clase de objeto y un subtipo compartidos: Class-Num 1 y C-Type 1 para la pila entrante. Estos números identifican la forma de leer el informe. No asignan las etiquetas individuales que los routers incluyen en él.

La convención común permite intercambiar evidencia local. No convierte la evidencia en un catálogo universal de rutas.

Cuatro octetos por entrada, otra frontera para el objeto

El objeto puede añadirse a Time Exceeded y Destination Unreachable, tanto en ICMPv4 como en ICMPv6. Su ámbito no se extiende automáticamente a cualquier otro mensaje ICMP.

Su longitud suma cuatro octetos de cabecera y cuatro por cada entrada. Así, una pila de tres entradas da lugar a un objeto de dieciséis octetos. Es un cálculo ilustrativo de la estructura, no una observación de tráfico. La cabecera general de extensión que precede al objeto se cuenta aparte.

Cada entrada contiene veinte bits de etiqueta, tres bits denominados EXP en el documento de 2007, uno de S y ocho de TTL. La RFC 5462, de febrero de 2009, cambió el nombre EXP por Traffic Class, TC, y aclaró su uso. No aumentó el tamaño de las entradas.

Las muestras antiguas deben leerse con esa diferencia temporal. Una leyenda EXP en una salida histórica no significa que hoy esos bits puedan utilizarse como espacio experimental sin restricciones. El nombre de entonces y la interpretación posterior forman parte de la historia del mismo campo.

Esta precisión de formato acompaña a la precisión temporal. Para conservar una instantánea útil hay que saber qué bytes pertenecen a ella, en qué orden y con qué significado.

El informe se dividió en partes

La estructura que sostiene el objeto procede de la RFC 4884, de abril de 2007. Ciertos mensajes ICMP pueden contener la región que cita el datagrama original, seguida de una cabecera de extensión y de uno o más objetos.

Para separar la cita del suplemento, el documento introduce un atributo de longitud de ocho bits en un espacio previamente reservado. Cuenta palabras de 32 bits en ICMPv4 y de 64 bits en ICMPv6. Al incluir extensiones, la región citada debe contener al menos 128 octetos, rellenarse con ceros si el original era menor y respetar la alineación prevista.

El mínimo chocó con una costumbre anterior. La RFC describe implementaciones producidas entre 1999 y su publicación que ya colocaban extensiones después de exactamente 128 octetos de cita, sin especificar el nuevo atributo de longitud.

Algunos lectores buscaban entonces una posición fija. Un emisor moderno podía citar más, y un lector moderno seguir la longitud anunciada. El lector antiguo, en cambio, seguiría buscando en el mismo sitio.

Quien necesitara compatibilidad con esos lectores debía conservar exactamente 128 octetos. Quien no la necesitara podía ampliar la cita dentro de los límites de tamaño del mensaje. El estándar hacía explícita una frontera; no actualizaba por sí solo el software instalado.

La excepción tenía que ser visible

La regla normal de una aplicación conforme es interpretar una longitud cero como ausencia de extensiones. Eso deja sin reconocer las respuestas antiguas que sí contenían un suplemento pero no lo declaraban mediante el atributo.

La RFC 4884 exige por ello que un traceroute conforme ofrezca un modo no predeterminado para interpretar esas respuestas. En mensajes suficientemente largos, ese modo busca una cabecera válida en la posición histórica, suponiendo una cita de 128 octetos y comprobando versión y suma de verificación.

No es lo mismo seguir un límite declarado que reconocer una práctica antigua por su disposición. Mantener separados ambos modos permite explicar por qué dos herramientas interpretan de forma distinta los mismos bytes.

Las aplicaciones clásicas que desconocen las extensiones pueden tomar los bytes nuevos como continuación del datagrama citado. La RFC estudia sus posibles efectos; no garantiza que todas las aplicaciones antiguas permanezcan intactas ante cualquier extensión.

La cabecera usa la versión 2. Un objeto desconocido no vuelve necesariamente malformado todo el mensaje, pero las longitudes y la sintaxis requieren validación. La suma de verificación tampoco autentica criptográficamente al emisor. Una estructura legible es una condición de interpretación, no una garantía de identidad.

El error también tiene su propio viaje

La pila que figura dentro del informe no debe confundirse con las etiquetas que pueden transportar ese informe.

La RFC 3032 describe un problema de retorno: un router interior a un dominio MPLS puede no conocer la ruta hacia la fuente IP original. En ciertos casos, puede encapsular el ICMP generado y hacerlo avanzar primero hacia el destino del paquete inicial, hasta alcanzar un router capaz de dirigirlo a la fuente.

Se copian valores de etiquetas, pero se ajustan los TTL para el viaje del nuevo mensaje. Esa pila externa es un mecanismo de transporte. El objeto de la RFC 4950 es una descripción de la llegada del paquete que falló.

La distinción afecta también a los tiempos. Un recorrido indirecto de la respuesta contribuye al tiempo de ida y vuelta observado. La presencia de etiquetas citadas no permite atribuir automáticamente ese tiempo a un enlace concreto del recorrido de ida.

El informe lleva una instantánea del pasado y, a la vez, vive su propia historia de entrega.

La instantánea no obliga a que haya un error

La RFC 4950 advierte que no redefine todas las relaciones entre MPLS e ICMP ni los tratamientos de TTL específicos de las encapsulaciones. Cuando estos impiden el funcionamiento de traceroute básico, también limitan su versión ampliada.

La RFC 3443, de enero de 2003, distingue modelos relevantes. Uniform sincroniza los TTL interior y exterior en los extremos del túnel. En los modelos Pipe, el valor inicial exterior puede no guardar relación con el interior.

Una sonda que varía su TTL IP no provoca necesariamente una respuesta de tiempo excedido en cada salto interno como espera su emisor. Eso no elimina los límites del TTL exterior ni prohíbe todo ICMP. Solo muestra que enriquecer una respuesta no cambia automáticamente las condiciones que la producen.

El operador también puede decidir qué información adjuntar según el destino del ICMP, una configuración global o la profundidad de la pila entrante. La RFC 4950 contempla, por ejemplo, revelar datos a direcciones de administración.

La falta de una línea de etiquetas puede deberse a generación, entrega, divulgación o lectura. No demuestra por sí sola una ausencia de MPLS. El texto de 2007 afirmaba que el mecanismo ya estaba ampliamente desplegado, pero esa afirmación histórica no es un censo actual ni una fecha de adopción simultánea.

La mejora consistió en conservar una parte del estado antes de que desapareciera del tratamiento del error. Su valor disminuye cuando se le pide que diga más de lo que ese instante permite.