Resumen

  • RFC 3355 transportaba L2TP sobre un circuito virtual ATM AAL5, pero cada PDU L2TP debía caber en un solo PDU AAL5; el MTU exterior limitaba el túnel y todas sus sesiones PPP.
  • Seleccionar encapsulación, establecer o borrar el VC y protegerlo eran hechos del portador. Una negociación correcta no probaba entrega interior, y borrar el SVC terminaba las sesiones.

Una sesión PPP podía creer que recorría un enlace sencillo. Debajo había un circuito virtual ATM, señalización, segmentación y una unidad exterior de tamaño finito. El túnel servía precisamente para ocultar esas piezas. No podía, sin embargo, hacer que su límite dejara de existir.

RFC 3355 se publicó en agosto de 2002 como estándar propuesto para llevar L2TP sobre ATM Adaptation Layer 5. La especificación base de L2TP decía que el túnel debía quedar ampliamente aislado de los detalles del medio y solo exigía conectividad punto a punto orientada a paquetes. AAL5 podía ofrecer esa interfaz entre LAC y LNS.

La regla decisiva era que cada PDU L2TP debía viajar dentro de un único PDU AAL5. De ahí seguía una cadena: el MTU del circuito AAL5 limitaba el MTU del túnel, y este limitaba el MRU de todas las conexiones PPP que lo utilizaban. Varias sesiones lógicas compartían una sola abertura física en el modelo.

La implementación tenía que admitir un MRU PPP mínimo de 1500 octetos. La RFC recomendaba además poder contener un paquete IP de al menos 9180 octetos dentro del PDU PPP. “Admitir” no significaba que un VC concreto estuviera provisionado para ello, que el SVC hubiera recibido esos parámetros o que el par PPP hubiera negociado ese valor. Era capacidad, no recibo de una entrega.

El servicio AAL5 debía verse como enlace bit-síncrono, dúplex y punto a punto. Podía ser PVC permanente o SVC establecido bajo demanda. Debía usar modo mensaje no asegurado sin entrega corrupta y presentar octetos completos. Conservar un límite de mensaje no convertía el servicio en fiable: longitud y CRC pertenecían a la trama, no a la autenticidad, confidencialidad o recepción por la aplicación.

La identidad del contenido tenía dos modelos. En LLC/SNAP, cada PDU nombraba explícitamente L2TP con el identificador de IANA. En multiplexación por VC, la cabecera desaparecía porque los extremos habían acordado qué protocolo ocupaba el circuito. Los mismos bytes adquirían significado por el contexto exterior.

LLC sobre PVC era obligatorio. LLC sobre SVC y VC-multiplexing eran opcionales. En un PVC, ambos extremos debían estar configurados con el mismo método. Dos dispositivos podían soportar L2TP y aun así discrepar sobre la interpretación de la carga si sus contextos de circuito no coincidían.

En un SVC, los elementos B-LLI llevaban la elección al plano de control ATM. El llamante ofrecía LLC, VC-multiplexing o ambos por preferencia. Si la llamada se aceptaba con ambas opciones, el llamado devolvía una sola. Si solo se ofrecía una opción no compatible, debía rechazarla.

La selección demostraba únicamente que una conexión había acordado una gramática para su carga AAL5. No probaba la apertura posterior del control L2TP, autenticación PPP, ajuste de tamaños, circulación de datos ni resultado de aplicación. El sobre había sido nombrado; su contenido aún debía funcionar.

El ciclo de vida atravesaba la abstracción. Cuando se reiniciaba un túnel sostenido por SVC, ambos extremos debían borrar el SVC y todas las sesiones de usuario terminaban. Una nueva petición de cliente podía iniciar otro establecimiento, pero no mantenía invisiblemente las sesiones anteriores.

También en sentido ascendente, una notificación de que el SVC AAL5 había sido borrado obligaba a desmontar el túnel y dejar inactiva la conexión de control. El portador no era una pieza reemplazable sin consecuencia. Su desaparición retiraba el enlace sobre el que vivía el estado interior.

Después de un fallo de establecimiento, decidir que el otro extremo estaba inaccesible y decidir cuándo volvía a estar disponible eran elecciones de implementación. Sin sesiones activas, cualquiera podía borrar opcionalmente el SVC. Por eso “inaccesible”, “borrado” e “inactivo” necesitaban indicar capa, observador, evento y generación.

La calidad de servicio también conservaba procedencia. Varias conexiones AAL5 podían separar clases de clientes. Distribuir inversamente un túnel sobre varios VC quedaba para estudio futuro. Los parámetros de un PVC se acordaban; los de un SVC se solicitaban. Una solicitud o descriptor configurado no probaba el servicio realmente observado.

La seguridad era independiente. RFC 3355 advertía que atacar la red ATM podía comprometer el túnel y señalaba cabeceras de autenticación, cargas cifradas o servicios de seguridad ATM. Un PID correcto, una selección B-LLI y un CRC válido no eran credenciales criptográficas.

RFC 2661 aporta el estado de túneles y sesiones; RFC 1661, PPP y MRU; RFC 2684, los dos modelos de encapsulación AAL5; RFC 2364, PPP directo sobre AAL5; RFC 2331, la señalización. RFC 3070 muestra otro soporte, Frame Relay, con otra unión. RFC 3193 añade el estado de IPsec. RFC 4459 analiza después MTU y fragmentación en túneles como problema general.

El registro IANA de L2TP conserva asignaciones, no tráfico. Ninguna entrada ni RFC demuestra por sí sola una implementación, un despliegue, un fallo medido o una recuperación. La evidencia debe seguir cada capa.

RFC 3355 deja una lección duradera: abstraer no es abolir. L2TP podía apartar ATM de la vista de PPP y seguir dependiendo de su tamaño, su acuerdo de identidad y su existencia. El túnel ocultaba el portador; el portador seguía controlando el sobre y la supervivencia de lo que contenía.

Sources