Resumen

  • RFC 2153 creó un espacio común para que los proveedores no asignaran en secreto Codes y Types PPP incompatibles.
  • El OUI identifica al administrador del significado; Kind y Values siguen siendo privados, por lo que una trama válida puede resultar desconocida o prohibida.
  • Configure-Ack acepta exactamente una solicitud; activar el mecanismo, usarlo en ambos sentidos y entregar servicio son hechos posteriores.

La dirección era exacta; el mensaje seguía cerrado

Un registro muestra Code 0, longitud correcta, OUI y Kind. La clasificación no tiene ambigüedad. Sin embargo, el equipo receptor puede carecer del módulo que interpreta ese Kind o de la política que autoriza sus valores. La precisión del nombre no transporta el diccionario.

La RFC 2153, informativa y publicada en 1997, resolvió un problema concreto: impedir que extensiones propietarias se apropiaran de Codes de LCP/NCP o Types de opción y chocaran entre sí. No convirtió los algoritmos privados en estándares.

El paquete Vendor Specific usa Code 0, Identifier, Magic-Number, OUI, Kind y Values opcionales. Puede enviarse incluso antes de LCP Opened. Recibirlo causa RXR o RUC, pero la respuesta es específica del proveedor; Code-Reject conduce al evento permitido RXJ+. Esa secuencia confirma recepción y tolerancia del autómata, no comprensión ni éxito.

La opción Vendor-Specific usa Type 0. Antes de aceptarla, la implementación debe verificar que OUI y Kind designan un mecanismo conocido y entender por completo los valores negociados. Es una frontera deliberada entre sintaxis, semántica y decisión.

Reconocer no es autorizar

El OUI identifica a la organización que administra el significado. El Kind no tiene normalización común, y Values depende de la implementación. Tampoco autentica al emisor. RFC 1661 permite autenticación del par después de establecer el enlace, mientras RFC 2153 permite el paquete propietario antes de Opened y no analiza seguridad.

La serie CF0000 se creó para proveedores solo de software. RFC 5342 cerró nuevas asignaciones y RFC 7042 mantuvo el cierre sin cambio técnico. El registro PPP de IANA conserva pocas entradas: demuestra procedencia numérica, no código instalado.

RFC 1661 distingue las respuestas. Ack exige opciones reconocibles y valores aceptables, y reproduce la solicitud exactamente. Nak señala valores inaceptables en opciones comprendidas. Reject señala una opción desconocida o no autorizada para negociar. Por ello, un tablero debe conservar solicitud, respuesta, dirección y generación; no basta la palabra “aceptada”.

La cadena completa añade el módulo y versión que entendió Values, la autoridad local, los parámetros instalados, el primer paquete del mecanismo, NCP Opened, tráfico de red y resultado de aplicación. RFC 3772 creó después protocolos PPP específicos de proveedor, pero dejó su seguridad en manos de cada protocolo.

Los registros de RFC Editor, Datatracker y errata describen el documento. Running-Code Primacy exige observar la ejecución; Minimum Initial Specification limita el acuerdo común; Reality Layers evita convertir una etiqueta en un resultado.

Fuentes