Resumen

  • RFC 2043 creó dos protocolos de control de red SNA negociados por separado: 0x804B habilitaba la ruta SNA sobre LLC 802.2 transportada como 0x004B, y 0x804D habilitaba la ruta HPR NLP transportada como 0x004D.
  • Llegar a Opened solo autorizaba a PPP a llevar la envoltura correspondiente. Como SNACP no tenía opciones de configuración y el RFC no trataba la seguridad, el estado no demostraba la otra ruta, recuperación, identidad, autorización, entrega, despliegue ni éxito de una sesión.

Hay una diferencia entre poder poner un paquete en una línea y saber qué ocurrió al final de la línea. RFC 2043 conserva esa diferencia con una precisión que los resúmenes operativos suelen borrar.

El documento, publicado en octubre de 1996, no es una historia general de PPP ni una reivindicación de SNA. Define el punto exacto en que una conexión punto a punto acepta dos formas distintas de tráfico SNA. La capa física es compartida. La autorización protocolaria no lo es.

PPP no convertía la línea en un veredicto

RFC 1661 divide la operación PPP en fases. LCP establece, configura y prueba el enlace de datos. La autenticación, si fue solicitada, y la determinación de calidad ocurren antes de la fase de protocolos de red. Después, cada protocolo de red debe configurarse con su NCP propio.

Por eso un LCP abierto no demuestra que un protocolo transportado también esté abierto. Cada NCP puede abrirse y cerrarse de manera independiente. Si llega un paquete de un protocolo compatible antes de que su NCP alcance Opened, PPP debe descartarlo silenciosamente.

RFC 2043 aplica la regla y añade una separación dentro de SNA. Su frase decisiva dice que existen en realidad dos NCP SNA: uno para SNA sobre LLC 802.2 y otro para SNA sin LLC 802.2. Se negocian separada e independientemente. Compartir cable no crea un estado común.

Los cuatro números forman dos parejas

PPP reserva valores del rango bajo para identificar paquetes de red y valores 8***–b*** para los NCP asociados. Así se leen las asignaciones que RFC 1700 ya registraba y que IANA conserva hoy.

0x804B es el protocolo de control de SNA sobre LLC 802.2. Tras su apertura, 0x004B identifica exactamente una PIU SNA XID o FID2 dentro de los campos LLC: DSAP, SSAP, control e información. Ese revestimiento mantiene una semántica propia.

0x804D es el protocolo de control de SNA sin LLC. Tras su apertura, 0x004D identifica exactamente un Network Layer Packet de High Performance Routing, con NHDR, THDR y datos.

No son cuatro códigos que digan «SNA» de forma intercambiable. El control 0x804B gobierna los datos 0x004B; 0x804D gobierna 0x004D. El estado de una pareja no completa el de la otra. Una base de datos que conserve solo “SNACP abierto” ya no puede reconstruir qué forma se permitió.

Una función asignada no equivale a una función cumplida

En la ruta 0x004B, LLC(2) se incluye para recuperación de errores de enlace. RFC 2043 ubica ese trabajo en los routers de ambos extremos del enlace PPP. La especificación, por tanto, indica dónde ocurre la recuperación.

No indica que haya ocurrido con éxito en un caso concreto. Una captura 0x004B demuestra la forma de un paquete en el punto capturado. No demuestra retransmisión, recepción remota, aceptación de la PIU, procesamiento del BIU ni continuidad de la media sesión SNA.

La ruta 0x004D prescinde de LLC. El RFC menciona que un NLP HPR podría viajar sobre LLC en PPP si la implementación incluyera la torre opcional de recuperación HPR. Esa posibilidad exige evidencia de implementación; no une los dos NCP ni transfiere el estado Opened entre ellos.

La negociación no llevaba opciones que pudieran prometer más

SNACP reutiliza el mecanismo de intercambio de LCP con solo siete códigos de control, desde Configure-Request hasta Code-Reject. Sin embargo, RFC 2043 declara que no existen opciones de configuración para SNA ni para SNA sobre LLC 802.2.

Esa ausencia limita el significado de un ACK. Las partes pueden alcanzar el estado que habilita una familia fija de paquetes, pero no negocian identidad SNA, perfil de aplicación, objetivo de recuperación, ruta, autorización, propiedad de seguridad o resultado empresarial. Un acuse no valida algo que nunca se describió en la solicitud.

Opened es el nombre de un estado de autómata, no un certificado de servicio.

La seguridad seguía fuera del contrato

La sección Security Considerations de RFC 2043 dice que no se discuten cuestiones de seguridad. PPP podía incorporar autenticación antes de la fase de red, pero RFC 1661 la dejaba desactivada por defecto salvo negociación. Cuando existe, sus pruebas deben nombrar método, par y resultado.

La apertura de SNACP no demuestra identidad, autorización dentro de SNA, confidencialidad ni integridad extremo a extremo. Tampoco el límite de tamaño aporta esa certeza. RFC 2043 liga el máximo paquete SNA al campo Information de PPP; RFC 1661 llama MRU a ese máximo y fija 1500 octetos por defecto. Es una medida del recipiente, no del resultado.

Lo que conserva el archivo y lo que no

RFC 2200 catalogó PPP-SNACP como Elective en 1997. RFC 3790 observó después que no tenía dependencia de IPv4. El registro IANA mantiene las cuatro asignaciones. Son pruebas de estado documental y de identidad numérica, no un censo de despliegue.

Tampoco la ausencia actual de erratas registradas demuestra perfección. No tenemos aquí una implementación nombrada, un ensayo de interoperabilidad, una medición de tráfico ni una sesión comercial verificada.

La lectura de Heng Lu ayuda a no inflar el documento. La especificación define una mínima condición común y localmente observable. El código, la puesta en servicio y la dependencia real requieren testigos distintos. La publicación ofrece una posibilidad de compatibilidad; no fabrica adopción.

Un registro operativo fiel conserva cuatro pasos: PPP llegó a la fase de red; un SNACP concreto alcanzó Opened; circuló el número de datos que le correspondía; otra prueba mostró el resultado posterior. El enlace no certifica la envoltura, la envoltura no certifica la entrega y la entrega no certifica la aplicación.

Fuentes