Resumen

  • Uniform propaga el estado del límite de saltos a través de la frontera de etiquetas, por lo que los LSR del túnel siguen siendo visibles desde fuera del LSP.
  • Pipe pretende que el túnel parezca un solo salto; Short Pipe se diferencia en el egreso, donde el paquete transportado recibe el tratamiento de un salto normal de reenvío.
  • RFC 3443 no define un mecanismo de señalización del modelo. El operador lo selecciona mediante configuración o una interfaz de gestión, y los controles normales de decremento y descarte siguen limitando el reenvío.

El mecanismo empieza con una decisión local, no con una señalización entre pares. En el ingreso, un push de etiqueta sigue el modelo elegido. Los LSR de tránsito hacen swap y procesan el estado TTL correspondiente. En el egreso, un pop —posiblemente PHP, es decir, la eliminación por el salto penúltimo— debe dejar el paquete con el tratamiento indicado por el modelo. RFC 3032 aporta el contexto de codificación de la pila de etiquetas, y RFC 3270 el contexto operativo de MPLS para servicios diferenciados; ninguno convierte el TTL en autorización de rutas o autenticación de pares.

En Uniform, el estado TTL de MPLS y el del paquete transportado se propagan a través de la frontera de etiquetas. Así, los LSR intermedios permanecen visibles para el tráfico observado fuera del túnel, siempre sujeto a una implementación correcta y al camino realmente recorrido.

Pipe establece una abstracción distinta: el túnel debe aparecer como un solo salto ante el tráfico exterior, sin importar cuántos LSR atraviese. En un push Pipe o Short Pipe, la nueva etiqueta recibe un TTL configurado por el operador, en lugar de copiar el TTL de la cabecera situada debajo. RFC 3443 señala que muchas implementaciones utilizaban 255 cuando se publicó, pero ese valor es una tendencia histórica de implementación, no un mandato universal.

Short Pipe cambia el tratamiento en la salida. La cabecera del paquete transportado se procesa como si el egreso del túnel fuera un salto ordinario de reenvío, incluido el decremento especificado. El RFC describe un decremento extremo a extremo equivalente con y sin PHP cuando los procedimientos se aplican correctamente. La regla común sigue siendo esencial: el TTL saliente normalmente es el TTL entrante menos uno, y el paquete no se reenvía si falla la comprobación del TTL saliente.

El riesgo de corrección aparece en las fronteras. Una implementación PHP puede retirar la etiqueta superior antes de que el siguiente equipo realice la operación esperada por el modelo. Una pila jerárquica añade más fronteras: las etiquetas externas e internas deben recibir el push, swap o pop correcto. Una implementación incompleta o inconsistente puede generar expiración, visibilidad o resultados de traceroute inesperados aunque la configuración declarada no haya cambiado.

Que un traceroute no muestre saltos internos no demuestra por sí solo que se use Pipe o Short Pipe, qué camino se siguió ni que todos los dispositivos aplicaran el modelo de forma consistente.

Un dispositivo de verificación concreto debe comparar el mismo flujo controlado con cada modelo, registrar el TTL inicial de la etiqueta insertada, revisar la profundidad de la pila y las operaciones en ingreso, tránsito y egreso, y observar el TTL del paquete antes y después de PHP. Debe incluir una sonda con TTL bajo que falle en la comprobación prevista, un caso con varias etiquetas y una comparación con PHP activado y desactivado cuando el entorno permita esa prueba. Son elementos de verificación, no umbrales obligatorios ni comandos de un proveedor.

La ruta de decisión del operador es: definir primero si la visibilidad interna del túnel es necesaria para la operación; elegir después Uniform, Pipe o Short Pipe; registrar el TTL inicial configurado sin asumir 255; verificar push, swap, pop y PHP en cada frontera relevante; probar expiración y pilas múltiples; y documentar qué puede concluir un observador externo. El modelo solo controla la propagación del TTL y la visibilidad. No establece un LSP, no autoriza una ruta, no autentica un extremo ni un par, no concede acceso, no cambia la política de reenvío y no cifra el tráfico.

Los RFC no establecen la prevalencia actual de ningún modelo, un valor predeterminado universal entre proveedores, una tasa medida de reducción de incidentes ni una política universal sobre cuándo conviene ocultar o exponer saltos. RFC 3443 también indica que su aclaración no introduce nuevos problemas de seguridad más allá de las especificaciones MPLS a las que remite.

Fuentes