Resumen

  • RFC 3437 permitió al LAC comunicar opciones LCP deseadas y permitidas al LNS; después, el LNS devolvía sus últimos Configure-Request enviado y recibido.
  • Los cuatro AVP transportaban conocimiento y recibos, no autoridad. El deseo no era permiso, un paquete no era resultado de servicio y exigir soporte podía romper sesiones antiguas.

Quien veía el cable no gobernaba la sesión

El LAC conocía las condiciones de la interfaz: MRU, ACCM, compresión PFC y ACFC o FCS alternativo. El LNS remoto terminaba la sesión PPP y ejecutaba LCP. L2TP sólo ofrecía indicios amplios —síncrono o asíncrono, digital o analógico— y dejaba un vacío entre observación local y decisión remota.

RFC 3437, de diciembre de 2002, creó un puente mínimo. Su texto, ficha, expediente, historial, referencias, citas y erratas prueban documentación, no adopción.

El proxy caducaba

PPP construía el enlace mediante LCP; el framing tipo HDLC ligaba ACCM, PFC, ACFC y FCS al medio. Las extensiones LCP y CHAP recuerdan que autenticación y framing tenían dueños distintos.

El LAC podía ejecutar Proxy LCP antes de entregar la llamada. Pero el LNS conservaba política de autenticación, la MRU podía tener restricciones remotas y el cliente podía reabrir LCP. Por eso el LAC podía omitir los AVP proxy para obligar al LNS a negociar, o enviar proxy y nuevas restricciones juntos.

Cuatro significados y dos direcciones

LCP Want Options (49) decía qué prefería el LAC; LCP Allow Options (50), qué podía soportar. Se enviaban en ICCN u OCCN. Una opción permitida no tenía que ser deseada, y una deseada podía ser rechazada.

Al terminar LCP, Set-Link-Info llevaba LNS Last Sent LCP Confreq (51) y LNS Last Received LCP Confreq (52), paquetes completos desde el campo Code. Las dos primeras piezas movían saber físico hacia el controlador; las dos últimas devolvían evidencia. Si el LAC enviaba Want o Allow, tenía que aceptar el regreso.

Los Confreq no demostraban autenticación, configuración de red, contabilidad, alcance ni aplicación. Eran pruebas de mensajes de negociación. Convertirlos en un indicador de “sesión correcta” habría mezclado capas.

Compatibilidad o exigencia

Los AVP eran no obligatorios. Un par antiguo podía ignorarlos; el bit M podía hacer fatal la falta de soporte. El RFC sólo recomendaba esa dureza cuando operar sin la extensión fuera inadmisible. La visibilidad tenía así un precio explícito en disponibilidad.

Se asignaron números nuevos porque un equipo antiguo podía rechazar un AVP conocido dentro de un mensaje donde antes no cabía. Un atributo opcional desconocido resultaba menos peligroso que uno familiar en un contexto imposible. Los registros L2TP y PPP de IANA prueban asignación, no tráfico.

Las opciones revelaban rasgos de interfaz y podían ayudar a inferir topología. Datos semejantes ya viajaban en LCP; cambió su presentación, no su existencia. RFC 3145, RFC 3193, RFC 3438 y RFC 3931 sitúan otros límites de L2TP sin convertir este intercambio en prueba de seguridad.

Un recibo para cada realidad

Las capas de realidad de Heng Lu separan intención, límite declarado, mensaje, estado y resultado. La primacía del código en ejecución exige probar AVP desconocidos y reaperturas. La especificación inicial mínima ayuda a leer la economía de cuatro registros. Son lentes posteriores, no motivos atribuidos a los autores.

RFC 3437 mostró que el control remoto no necesita fingir omnisciencia. Necesita recibir límites locales, devolver evidencia y conservar la diferencia entre lo pedido, lo posible y lo ocurrido.

Fuentes