Resumen

  • Configure-Ack no podía negociar mientras confirmaba: tenía que repetir exactamente el Identifier, el orden y los bytes de las opciones de la última Configure-Request.
  • LCP llevaba dos acuerdos independientes. Nak sugería valores posibles, Reject cerraba una opción y Opened solo llegaba después de haber enviado y recibido un Ack.

Un sí con una cifra nueva era otra cosa

Un extremo pide que el otro no le envíe tramas mayores que cierto límite. La contraparte entiende Maximum-Receive-Unit, considera más práctico otro tamaño y lo devuelve dentro de Configure-Ack. La intención parece cooperativa, pero el paquete es inválido.

Según RFC 1661, un Ack válido copia el Identifier de la solicitud más reciente y conserva las opciones exactamente, con el mismo orden y contenido. Solo procede cuando todas son reconocibles y sus valores resultan aceptables. Aceptar no incluía la facultad de editar.

La rigidez elimina una ambigüedad de estado. Si la respuesta pudiera corregir la propuesta, el solicitante tendría que adivinar si su petición fue aceptada, sustituida o mezclada con otra configuración. Con pérdidas, retransmisiones y mensajes cruzados, ambas memorias podrían divergir sin notarlo. La copia exacta reduce la prueba a algo observable: estos mismos bytes recibieron conformidad.

El Identifier enlaza respuesta e intento. Cambia cuando cambian las opciones y después de una respuesta válida; una retransmisión puede conservarlo. No identifica a una persona ni autentica el equipo. Solo impide que una respuesta vieja tome el lugar de la conversación actual.

La alternativa y el límite no eran el mismo mensaje

Configure-Nak sirve cuando el tipo de opción se entiende y puede negociarse, pero el valor no satisface al receptor. El Nak omite lo ya aceptable, devuelve las opciones discutidas y puede sustituir sus valores por otros que sí aceptaría. También puede señalar una opción obligatoria que la solicitud no incluyó.

La sugerencia no modifica la petición pendiente. El solicitante decide si emite una Configure-Request nueva; si cambia su contenido, usa un Identifier nuevo. Solo entonces existe otra propuesta susceptible de recibir un Ack idéntico.

Configure-Reject trata una frontera más dura. La opción es desconocida, no está implementada o la política local no permite negociarla. Reject copia la opción rechazada y conduce a eliminarla del siguiente intento. Una opción booleana, sin valor alternativo, no puede recibir una sugerencia y por eso se rechaza.

Ack, Nak y Reject distribuían poderes diferentes: confirmar, indicar terreno posible y negar ese terreno. Ninguno autorizaba al vecino a reescribir una exigencia local.

La misma línea alojaba dos propuestas

Salvo que una opción diga otra cosa, la configuración de LCP se aplica por sentido y normalmente describe la recepción del emisor de Configure-Request. La petición de A explica cómo A puede recibir de B; B presenta otra petición para recibir de A.

Los dos intercambios pueden cruzarse. A puede haber recibido conformidad para su lista y aún no haber decidido la respuesta a la lista de B. RFC 1171 ya llamaba Ack-Received a ese estado. Haber obtenido un sí no concede automáticamente el sí opuesto.

RFC 1331 fijó la condición decisiva: el establecimiento acaba cuando Configure-Ack ha sido enviado y recibido. La señal de portadora ni un solo Ack permiten a un extremo declarar por sí mismo que todo el enlace está abierto.

La doble prueba admitía diferencias reales. La capacidad de recepción, la autenticación exigida y las formas de compresión podían ser asimétricas. PPP buscaba una configuración compatible, no equipos idénticos.

Omitir una opción activaba el valor predeterminado

Configure-Request enumera cambios deseados, no todas las características. RFC 1661 recomienda no incluir opciones con su valor predeterminado. La ausencia, por tanto, también tiene significado: rige el valor definido por la norma.

Una captura que solo almacena opciones explícitas no reconstruye el enlace. Hace falta añadir los predeterminados aplicables y respetar el sentido de cada petición. El estado efectivo es una composición, no una sola lista.

Todas las opciones de una solicitud se evalúan simultáneamente. Ack confirma el conjunto ordenado completo; Nak muestra únicamente los valores en disputa; Reject recoge lo que queda fuera de la conversación. Así la decisión conserva una unidad precisa sin obligar a revelar todas las capacidades del dispositivo.

El lenguaje de control no podía depender del acuerdo discutido

Algunas opciones cambian el formato de las tramas. Si un extremo empieza a comprimir campos porque cree que la opción ya rige, mientras el otro aún espera el formato normal, hasta los paquetes que deberían reparar la diferencia pueden volverse ilegibles.

RFC 1548 y RFC 1661 evitan ese círculo: los paquetes LCP de configuración, terminación y Code-Reject se envían como si ninguna opción estuviera habilitada. No se comprimen los campos de dirección, control ni protocolo en esa vía.

No es un acuerdo por defecto. Es una gramática de emergencia que sigue siendo reconocible mientras el acuerdo falta. La optimización de datos no recibe autoridad para destruir la ruta de control.

El silencio y el regateo tenían final

Configure-Request emplea un Restart timer porque el medio puede perder paquetes. Max-Configure limita los intentos sin una respuesta válida; debe poder configurarse y RFC 1661 recomienda diez transmisiones como valor inicial.

También puede haber respuestas sin convergencia. Max-Failure cuenta los Naks consecutivos y tiene cinco como recomendación. Después, nuevos Naks pasan a Reject y el receptor deja de añadir sus propias opciones deseadas. Una negociación que no reduce la distancia deja de merecer tiempo ilimitado.

Los contadores no demuestran ataque, avería ni mala fe. Permiten que cada extremo cierre localmente una tentativa cuyo expediente no llega a ser suficiente.

LCP abierto no quería decir IP listo

Los cuatro códigos ya figuraban en RFC 1134, de noviembre de 1989. Sobrevivieron a RFC 1171, RFC 1331, RFC 1548 y a la norma base RFC 1661 de julio de 1994. Durante esa evolución también se hizo más nítida la secuencia de autoridad.

Primero aparece la disponibilidad física. LCP configura lo independiente de la capa de red. Si se negoció autenticación, esta ocurre después. A continuación, un Network Control Protocol separado abre cada protocolo de red. Solo el NCP correspondiente habilita su tráfico.

Por eso Configure-Ack no prueba identidad, autenticación, dirección IP, rutas ni servicio. Prueba exclusivamente que quien respondió aceptó una propuesta LCP concreta.

El registro PPP de IANA mantiene Request, Ack, Nak y Reject como códigos 1 a 4, además del espacio de opciones. El registro acredita una sintaxis coordinada, no cuántas redes la usan hoy ni si todos los productos la ejecutan bien.

La interoperabilidad nació de un consentimiento estrecho

PPP convirtió “estar de acuerdo” en varios hechos modestos: copia exacta para aceptar, mensaje distinto para sugerir, frontera explícita para rechazar, estado separado por dirección y límites para el silencio y la repetición. Las capas posteriores debían ganar su propia habilitación.

No hizo falta una autoridad central que fijara el tamaño, la compresión o la autenticación de cada enlace. Tampoco un extremo obtuvo mando sobre el otro. La norma común definió pruebas pequeñas y locales; la política permaneció donde se asumía el riesgo.

Fuentes y límites

RFC 1134, RFC 1171, RFC 1331, RFC 1548 y RFC 1661 sustentan la evolución, los paquetes, los estados y los límites de convergencia. IANA sustenta las asignaciones vigentes. No documentan adopción actual, conformidad de proveedores, rendimiento, prácticas de operadores ni un tiempo de espera universal. La lectura institucional del mecanismo como autoridad bilateral mínima es una inferencia editorial.