Resumen

  • El NLPID 0xcf separa PPP de otras encapsulaciones Frame Relay, pero un valor comprimido solo se interpreta como PPP cuando PFC está activo y el NCP asociado ya fue negociado.
  • Respuestas con el mismo Identifier LCP desde distintas framing addresses pueden revelar una conexión multipunto; una encapsulación equivalente tras completar NCP obliga a reabrir Link Establishment.

Un analizador puede reconocer tres bytes y equivocarse sobre todo lo demás. cf-c0-21 parece una firma rotunda: PPP, LCP, Configure-Request. Pero no dice si la petición es válida, si el otro extremo es único, si LCP llegó a Opened, si hubo autenticación o si algún paquete de cliente alcanzó su destino. RFC 1973 resulta valioso porque mantiene esas cuentas separadas.

El documento, publicado en junio de 1996, describe PPP sobre un circuito Frame Relay configurado punto a punto. PPP aportaba LCP, protocolos NCP, autenticación y compresión. Esas funciones suponían dos pares. Frame Relay aportaba circuitos virtuales, pero su infraestructura podía estar conectada de forma multipunto. El formato debía, por tanto, proteger una conversación bilateral sin atribuir a la capa inferior más certeza de la que ofrecía.

La frontera que no podía inferirse

PPP utilizaba normalmente framing similar a HDLC basado en ISO 3309. Hubo una esperanza de hacerlo coexistir con Frame Relay en el mismo enlace. RFC 1973 la descartó: Q.922 permite extender la dirección de uno a dos o cuatro octetos, y los subcampos DLCI pueden confundirse con la lectura ISO 3309. Si el receptor no puede decidir con seguridad dónde termina una dirección, la convivencia no es interoperabilidad.

La alternativa fue un orden visible: Flag 0x7e, Q.922 Address, Control, NLPID 0xcf, PPP Protocol, Information y Padding. La dirección y el control pertenecen a la entrega Frame Relay; 0xcf selecciona PPP; el campo Protocol selecciona LCP, un NCP o el protocolo transportado. Cada campo escoge una gramática. Ninguno acredita por sí solo a un emisor.

Por esa razón, Address-and-Control-Field-Compression quedó prohibido. En PPP HDLC-like, los valores fijos podían omitirse. En Frame Relay, Address y Control no eran constantes y podían cambiar dentro de la red de conmutación. La optimización habría borrado contexto variable.

Un árbol de decisión después del encabezado

Protocol-Field-Compression sí tenía utilidad. Reducía PPP Protocol de dos octetos a uno y, en este framing, la eliminación del NLPID más la compresión alineaban Information a 32 bits. RFC 1973 recomendaba negociar PFC cuando mejorara el rendimiento.

El receptor examinaba el primer octeto posterior al encabezado. Si era cero, debía asumir el formato de RFC 1490. Si era 0xcf, encontraba el NLPID explícito de PPP. Si no era cero ni 0xcf, solo podía esperarlo como PPP Protocol comprimido cuando PFC estuviera habilitado y el NCP correspondiente ya se hubiera negociado. Sin ambas condiciones, volvía a la interpretación RFC 1490.

El mismo byte cambia de significado con el estado guardado. Para evitar una ambigüedad adicional, el PPP Protocol 0x00cf quedó reservado. El texto permitía tratarlo como indicación de otro paquete PPP Protocol posterior, no como prueba de aceptación. IANA conserva hoy 0xCF en el registro NLPID y 00cf como reservado en las asignaciones PPP.

Cuando una solicitud recibe demasiadas respuestas

Los paquetes LCP iniciales colocan cf-c0-21 después del encabezado: cf para el NLPID PPP y c021 para LCP sin comprimir. Reconocer Configure-Request hace entrar el enlace en Link Establishment. Todavía no hay un acuerdo terminado.

La especificación ofrece entonces una pista topológica. Si un feed punto a punto fue conectado por error a una red multipunto o grupo multicast, varios nodos pueden contestar. Múltiples respuestas al mismo Configure-Request, con el mismo Identifier pero desde framing addresses diferentes, deberían generar una indicación de mala configuración.

El Identifier correlaciona. Las direcciones distinguen orígenes observados. La multiplicidad completa la señal. Una sola respuesta no prueba que no haya otros pares; el DLCI no es una identidad global; y el silencio del sistema de alertas tampoco prueba normalidad. Algunas implementaciones, advierte el RFC, podrían carecer de capacidad física para registrar o comunicar esas direcciones.

La encapsulación equivalente que ya no era equivalente

Durante Link Establishment no se podían enviar paquetes con otros NLPID, y los recibidos debían descartarse silenciosamente hasta la fase Network-Layer Protocol. La máquina PPP incompleta conservaba así el control de su propia interpretación.

Después de negociar con éxito el NCP de un protocolo, la llegada de ese mismo tráfico bajo una encapsulación equivalente de RFC 1490 adquiría otro significado. Indicaba que el par podía haber perdido estado PPP. RFC 1973 exigía regresar a Link Establishment y transmitir un nuevo LCP Configure-Request. El objetivo era impedir un agujero negro: un extremo seguía enviando según un acuerdo que el otro ya no recordaba.

Volver al principio no recuperaba los paquetes descartados ni identificaba la causa. Tampoco autenticaba al par o garantizaba una nueva apertura. Convertía un síntoma de datos en un intercambio de control observable.

Si la configuración PPP o una función negociada como la autenticación era obligatoria, la implementación podía entrar en Termination al fallar. Si no, cuando el emisor alcanzara Max-Configure debía pasar a enviar únicamente frames encapsulados según RFC 1490. Parar para conservar una propiedad y continuar rebajándola eran decisiones locales distintas.

Márgenes escritos para equipos concretos

El enlace debía ser full-duplex, permanente o conmutado. Las señales de control Frame Relay podían producir eventos Up y Down para LCP, pero su fallo no podía impedir el funcionamiento correcto de PPP. Magic Number y PFC eran opciones recomendadas. El MRU inicial era 1600; el MTU de red no debía superar 1500 salvo negociación específica de un MRU remoto de 2048 o más.

Algunos switches solo admitían frames de 262 octetos. Por eso PPP debía poder limitar LCP a 259 octetos antes de terminar la negociación, dejando espacio para NLPID y Protocol. XID e Inverse ARP no eran requisitos de estos enlaces PPP porque NCP proporcionaba la función necesaria. El alcance de estas reglas no se extiende a toda red Frame Relay.

RFC 2427 sustituyó después a RFC 1490 y RFC 1294 como especificación general multiprotocolo, no a RFC 1973. Los números registrados y los textos normativos no demuestran uso presente, configuración de fabricantes, incidentes o entrega de servicio. Además, RFC 1973 declara que no discute seguridad: el framing no aporta por sí mismo integridad, confidencialidad ni autenticación.

Fuentes