Resumen

  • RFC 3145 añadió al aviso de desconexión L2TP una causa específica de PPP, pero la mantuvo opcional, no obligatoria y sin efecto sobre la sesión.
  • Código, protocolo de control y dirección forman un informe situado; no demuestran por sí solos fallo físico, culpa, recepción por el usuario ni cierre contable.
  • La interoperabilidad mejoró porque el estándar preservó las coordenadas del testimonio en lugar de convertir un número registrado en autoridad sobre los hechos.

El borde que atendía no era el borde que sabía

L2TP permitía que un concentrador de acceso, LAC, llevara una sesión PPP hasta un servidor de red, LNS. El túnel ocultaba detalles de PPP para que su control siguiera siendo general. Esa virtud dejaba una pregunta sin transportar: cuando PPP terminaba, ¿qué había observado el host que conocía la negociación?

Call-Disconnect-Notify ya incluía Result Code y Error Code de L2TP. Esos atributos explicaban el resultado del control del túnel. No tenían por qué describir que LCP agotó un temporizador, que no hubo un NCP utilizable, que una dirección no fue aceptada o que una política administrativa cerró la llamada.

La diferencia se volvía contractual cuando LAC y LNS tenían dueños distintos. El primero podía ver el acceso y hablar con el usuario; el segundo podía conservar el estado PPP. Sin un recibo común, cada organización tenía un relato técnicamente plausible y difícil de comparar con el otro.

RFC 3145 creó ese recibo: PPP Disconnect Cause Code AVP, Vendor ID 0 y tipo 46, válido solo en CDN. Incluía código de causa, número de protocolo de control PPP, dirección y texto UTF-8 opcional. Sin embargo, debía usarse junto con los códigos L2TP, no en su lugar. El hecho “el túnel notificó el final” y el hecho “este peer atribuyó a PPP esta condición” no eran intercambiables.

El diagnóstico no recibió un botón de mando

El bit Mandatory tenía que ser cero. Un receptor antiguo podía ignorar el nuevo atributo sin rechazar el mensaje de control. Así, desplegar observabilidad no se convirtió en requisito para ejecutar correctamente la desconexión.

El RFC delimitó también su efecto: información y registro solamente. La AVP no debía cambiar el túnel ni la sesión PPP. La máquina de estados producía la acción; un host producía la explicación; una investigación posterior podía producir una conclusión. Confundir esos tres productos habría convertido una mejora de visibilidad en un canal de control accidental.

El atributo podía ocultarse. IPsec podía proteger la relación L2TP. Ambas medidas ayudan a saber quién envió el mensaje y a evitar lectura o modificación no autorizada. Ninguna convierte el diagnóstico local en causa probada. La autenticidad del hablante no es infalibilidad del hablante.

Toda dirección tiene un punto de vista

Dirección cero significaba error global, uno “en el peer” y dos “en local”. Local era el host que redactaba la AVP. Un recolector que lo traduce automáticamente como cliente, proveedor, víctima o responsable pierde la referencia y añade una conclusión.

Algunos códigos necesitaban esa coordenada. En una terminación normal, indicaba qué lado envió LCP Terminate-Request. Para cifrado o rellamada obligatorios, distinguía quién exigió la función y quién la rechazó. En autenticación, diferenciaba protocolos locales rechazados por el peer de protocolos pedidos por el peer que el sistema local no aceptaba. Una negativa puede ser política correcta; la última acción no determina la culpa.

El número de protocolo de control situaba el informe en otra dimensión. Los errores globales usaban cero; los de enlace, LCP; los de autenticación, su método; los de red, el NCP afectado. Podían enviarse varias AVP cuando fallaban varios NCP. Si se enviaba una, debía representar el fallo más reciente. Reciente no significa único ni causalmente dominante.

Por eso “código 16” no es un registro suficiente. Hace falta conservar qué peer lo emitió, en qué túnel y sesión, dentro de qué CDN, para qué protocolo y dirección, a qué hora y bajo qué protección. El número adquiere valor al conservar sus coordenadas.

Un vocabulario común no cerraba el caso

Los valores iniciales 0 a 20 nombraban falta de información, desconexión administrativa, terminación normal, temporizadores, ausencia de paquetes LCP reconocibles, posible bucle por Magic Number, falta de Echo Reply, incompatibilidades multilink, negativa de cifrado o rellamada, fallos de autenticación, ausencia de NCP disponibles y falta de convergencia de direcciones.

La lista permitía comparar productos. No distinguía todas las causas de cada síntoma. Un timeout de eco es compatible con pérdida, congestión, una ruta de retorno filtrada, un peer caído o un proceso local bloqueado. Un fallo de autenticación registra el resultado del intercambio, no la identidad ni la intención de una persona.

El RFC advirtió que futuras extensiones no debían revelar que un nombre era correcto y solo el secreto era incorrecto. La precisión diagnóstica podía convertirse en oráculo para un atacante. La buena observabilidad no maximiza indiscriminadamente el detalle; transporta el mínimo que ayuda a operar sin regalar una prueba de credenciales.

El texto UTF-8 opcional tampoco tenía autoridad superior. Ser legible no lo hacía verdadero, seguro para cualquier audiencia ni efectivamente mostrado. Debían conservarse por separado texto original, traducción para usuario y campos estructurados. Si una traducción dice “contraseña incorrecta” donde el código solo dice “fallo de autenticación”, la interfaz inventa evidencia.

Estandarizar la lectura, no certificar la realidad

Un borrador anterior usó Vendor ID 43 de 3Com. RFC 3145 permitió aceptar esa forma como equivalente y recomendó no transmitirla. El receptor podía interpretar registros antiguos; el emisor debía usar la asignación IETF. La compatibilidad fue selectiva y auditable.

La función de IANA era mantener el espacio de valores. Eso autoriza la decodificación: qué significa formalmente un número. No certifica despliegue, frecuencia ni verdad de una instancia. El peer crea el informe; el registro estabiliza su lenguaje; los paquetes y estados operativos deciden cuánto resiste el informe al contraste.

La contabilidad era otra línea temporal

RFC 3145 dijo que el motivo podía ser útil para contabilidad y depuración. Útil no quería decir suficiente. Los atributos de accounting de túnel RADIUS correlacionan sesiones y permiten observar inicio, actualizaciones, parada y contadores. La causa PPP puede orientar la explicación de una parada. No prueba que Stop haya llegado, que los octetos estén completos o que el cobro sea correcto.

La evidencia del plano de datos también es independiente. Un eco agotado debe compararse con contadores y alarmas. Un error de autenticación, con la secuencia de estados, sin diseminar secretos. Una terminación normal, con el intercambio LCP. La causa señala dónde buscar; no reemplaza lo encontrado.

Finalmente, un mensaje al usuario exige recibo propio. Generarlo, entregarlo y que una persona lo vea son eventos diferentes. El AVP no demuestra ninguno de los dos últimos.

El funcionamiento conservó el derecho a contradecir

RFC 3145 encarna una regla más amplia: estandarizar la mínima afirmación interoperable, conservar su procedencia y dejar que el comportamiento observable la confirme o la limite. El código está en la capa simbólica; el CDN es un acto; PPP y los paquetes muestran funcionamiento; contabilidad y experiencia son consecuencias.

Los sistemas modernos suelen absorber un reason, eliminar quién lo dijo y desde dónde, redactar una frase amistosa y declararla causa global. El diseño de 2001 fue más cuidadoso. El motivo podía cruzar el túnel; la autoridad para dictar sentencia no viajaba con él.

Fuentes