Resumen

  • PPP distinguió el estado del enlace común del soporte para cada protocolo multiplexado. Un valor Protocol desconocido, recibido con LCP en Opened, exigía un Protocol-Reject de código 8.
  • La respuesta devolvía el valor de protocolo en dos octetos y una porción del paquete limitada por la MRU, suficiente para atribuir el desacuerdo sin prometer una copia íntegra de la trama.
  • Rechazar un NCP podía ser RXJ+, una incompatibilidad contenible; rechazar LCP era RXJ-, porque eliminaba el lenguaje de control que hacía posible mantener el enlace abierto.

La excepción apareció dentro de un enlace válido

PPP nació con una idea más rica que la de un conducto dedicado a una sola familia de paquetes. El RFC 1134, de 1989, propuso transportar datagramas de múltiples protocolos de red sobre enlaces punto a punto. LCP administraba el enlace y una familia de Network Control Protocols se ocupaba de cada uso de capa de red.

La separación permitió que varios protocolos coexistieran, pero también hizo posible una discrepancia parcial. Un extremo podía enviar un valor en el campo PPP Protocol que el otro no conocía. Si LCP ya estaba abierto, el receptor no debía convertir automáticamente esa incompatibilidad en el final de toda la conexión. Debía informar de ella mediante un paquete LCP con código 8: Protocol-Reject.

El RFC 1331 afinó la clasificación en 1992. Cuando el protocolo era compatible pero su NCP todavía no estaba Opened, el paquete se descartaba en silencio. Cuando el valor Protocol era desconocido, se enviaba el rechazo. Así, la ausencia de respuesta podía corresponder a una fase de configuración, mientras que el rechazo afirmaba un límite de soporte.

Esa diferencia impide diagnósticos rápidos. No recibir Protocol-Reject no demuestra compatibilidad: LCP podría no estar abierto, la respuesta podría perderse o el equipo podría incumplir la norma. Recibirlo tampoco demuestra que el medio físico se haya caído. La evidencia se refiere primero a un protocolo concreto dentro de un enlace que todavía tiene contexto LCP.

El paquete de error respetó el límite del enlace

El RFC 1661 definió la forma madura. Code contiene 8. Identifier debe cambiar con cada Protocol-Reject enviado. Rejected-Protocol ocupa dos octetos y reproduce el campo Protocol del paquete que no fue aceptado.

Rejected-Information comienza con el campo Information del paquete rechazado. No incluye cabeceras de enlace ni FCS y debe truncarse para no exceder la Maximum-Receive-Unit establecida por el par. La respuesta conserva el rastro necesario para reconocer el estímulo, pero acepta la misma disciplina de tamaño que gobierna el enlace.

Una captura de ese campo no es una imagen completa de la trama. Puede terminar antes que el paquete original y omite deliberadamente elementos de la capa de enlace. El Identifier tampoco es un identificador persistente del incidente. El mecanismo produce una prueba tipada y limitada: qué protocolo se rechazó y qué información alcanzó a devolverse dentro de la MRU.

El RFC 1548 conservó el mecanismo en 1993 y el RFC 1661 lo mantuvo un año después. La continuidad muestra que el control de errores formaba parte de la arquitectura estable de PPP, no que todos los equipos lo implementaran correctamente.

El emisor recibió una orden de dejar de insistir

Al recibir Protocol-Reject, una implementación debe dejar de enviar paquetes del protocolo indicado en la primera oportunidad. La fórmula del RFC 1661 admite que pueda existir trabajo en cola o en vuelo; no autoriza a tratar el rechazo como una pérdida temporal y reintentar sin fin.

Los protocolos de control de red muestran el alcance. El RFC 1332 define IPCP para configurar IP sobre PPP. El RFC 5072 define IPv6CP. Son ejemplos de NCP independientes, no observaciones de un despliegue concreto. Si uno es rechazado, el servicio de red asociado no está disponible por el mero hecho de que LCP continúe abierto. Otro protocolo solo puede seguir si tiene soporte y ha completado su propia configuración.

El rechazo, además, solo puede enviarse con LCP en Opened. Recibido en otro estado, debería descartarse silenciosamente. El estado funciona como autorización contextual: una declaración de incompatibilidad puede dirigir al par únicamente cuando ambos han establecido el plano de control que le da significado.

RXJ+ y RXJ- separaron el daño local del estructural

El RFC 1331 llamó RXJ+ a una recepción de rechazo aceptable. Su ejemplo incluye Protocol-Reject de un NCP. El hecho pertenece al funcionamiento normal: el equipo debe detener el tipo de paquete, pero el enlace no tiene que terminar por esa razón.

RXJ- es diferente. Si Protocol-Reject señala LCP, el error es catastrófico e irrecuperable y termina la conexión. No cambia el código del paquete; cambia la capa negada. Un NCP puede desaparecer dejando LCP como base común. Cuando LCP es el protocolo desconocido, los dos extremos ya no comparten la herramienta con la que configuran, prueban y cierran ordenadamente el enlace.

Por eso «el enlace siguió activo» es una afirmación acotada. Puede ser cierta para un rechazo de NCP y, a la vez, inútil para una aplicación cuyo único servicio dependía de ese NCP. La disponibilidad del portador y la disponibilidad de la función son preguntas distintas.

Un número asignado no equivalía a una función instalada

El registro de IANA para PPP enumera el código LCP 8 como Protocol-Reject y publica asignaciones del campo Protocol. Sirve para decodificar valores y evitar colisiones de nombres. No certifica que un dispositivo implemente el protocolo, que un NCP esté abierto ni que una red lo utilice en la actualidad.

El RFC 3818 revisó la política de asignación de los espacios PPP y la vinculó al consenso IETF. La existencia de una gobernanza duradera demuestra extensibilidad administrada, no penetración comercial. Para afirmar soporte hacen falta configuración, estados y tráfico; para afirmar rechazo hacen falta el Code 8 y su secuencia posterior.

Fuentes