Resumen

  • El FCS de PPP cubría los campos definidos de la trama, no los delimitadores, los bits de arranque y parada ni el material insertado para transparencia. El emisor hacía stuffing después del cálculo y el receptor lo deshacía antes de comprobar.
  • El ACCM de recepción solo permitía retirar antes del FCS los controles inferiores a 0x20 seleccionados, porque equipos intermedios podían introducirlos. Era una regla direccional y acotada, no una licencia para borrar cualquier cambio.
  • El stuffing por octetos y por bits resolvía el mismo problema con representaciones distintas. Un FCS correcto indicaba detección de errores sobre la trama restaurada, no identidad, autenticación ni una ruta física intacta.

El byte observado podía no pertenecer al mensaje

Supongamos que una captura serie muestra un carácter de control que el extremo emisor no puso en la trama. Un módem, un controlador de terminal u otro equipo de comunicaciones pudo insertarlo. Si el receptor lo incorpora sin más al FCS, una trama buena parece corrupta. Si elimina cualquier byte incómodo, la corrupción real puede desaparecer con él.

PPP convirtió la excepción en una lista estrecha. RFC 1662 ordena descartar antes del cálculo FCS los octetos señalados por el Async-Control-Character-Map de recepción. También exige revertir las secuencias Control Escape. El objeto verificado es así la trama reconstruida mediante reglas compartidas, no todos los bytes físicos vistos en todos los puntos de la ruta.

Llamar a ese paso “canonicalización” ayuda a describirlo, pero no nombra un campo del protocolo. La seguridad del procedimiento procede del orden y de la enumeración, no de una interpretación libre del receptor.

Primero el FCS; después, la forma apta para la línea

La trama HDLC-like queda entre dos Flags 0x7e. Dentro aparecen Address, Control, Protocol, Information, Padding opcional y FCS. Este mide 16 bits por defecto y dispone de una variante de 32. Su cálculo incluye desde Address hasta Padding, pero excluye Flags, el propio FCS, los bits de arranque y parada y lo insertado para transparencia.

En un enlace con octet stuffing, 0x7d es Control Escape. El emisor debe escapar como mínimo 0x7e y 0x7d. La secuencia importa: calcula el FCS y, solo después, recorre el contenido entre Flags. Cada octeto protegido se sustituye por 0x7d seguido del valor original XOR 0x20. Por eso 0x7e se transmite como 0x7d 0x5e y 0x7d como 0x7d 0x5d.

El receptor revierte la operación antes de comprobar. Elimina Control Escape y aplica XOR 0x20 al octeto siguiente. Si a Control Escape le sigue inmediatamente un Flag, la trama se aborta; no se inventa un dato. La reversibilidad marca la diferencia entre una forma temporal de transporte y el contenido bajo integridad.

El mapa decía qué necesitaba una dirección

Los controles ASCII chocaban con la lógica de algunas líneas asíncronas. El control de flujo por software podía interceptar XON en 0x11 o XOFF en 0x13, incluso ignorando el bit de paridad. PPP escapaba esos valores para atravesar la ruta y podía filtrar en recepción los controles bajos configurados como posibles inserciones del trayecto.

Cada extremo asíncrono mantenía un ACCM de recepción de 32 bits y otro de envío de hasta 256. Hay cuatro mapas entre los dos sentidos de un enlace, no una lista negra global.

La opción ACCM de LCP es de tipo 2 y longitud 6, con un mapa de cuatro octetos. Un bit a uno obliga al par a mantener escapado ese control cuando transmite hacia quien pidió la opción. Un bit a cero solo dice que no es necesario; no prohíbe escapar. El emisor puede proteger valores adicionales por restricciones locales que conoce mejor.

La autoridad queda repartida. El receptor fija el mínimo para su camino de entrada. El emisor conserva prudencia local. Un Configure-Nak debería sugerir la unión de los conjuntos necesarios para que controles introducidos en la ruta puedan ignorarse al llegar. Ninguna decisión se convierte en política universal para otros enlaces.

La versión síncrona añadía un bit, no un octeto de escape

En bit-synchronous framing, el emisor inserta un cero después de cada serie de cinco unos, una vez calculado el FCS y también dentro de él. El receptor retira ese cero antes de su cálculo. Así no aparece por accidente la secuencia de un Flag en el cuerpo de la trama.

El invariante es el mismo: añadir transparencia después de crear el valor de control y retirarla antes de validarlo. La imagen en el cable no lo es. Un conversor asíncrono-síncrono se responsabiliza de traducir entre ambos stuffing. RFC 1662 exige que un extremo síncrono reconozca la opción ACCM para facilitar esa conversión, pero aclara que el reconocimiento no prueba que el propio extremo haga mapping de octetos.

Una configuración aceptada puede sostener una función del intermediario. No basta para ubicar dónde se ejecutó la transformación.

Descartar una trama no siempre sumaba un error FCS

PPP separó la malformación del fallo de checksum. Una trama demasiado corta, un Control Escape colgante justo antes del Flag de cierre o una violación del octet framing se descartan en silencio y no cuentan como error FCS. En el modo por bits, una secuencia de más de seis unos también es inválida.

Por ello, vigilar solo el contador FCS oculta averías de framing. Una captura tomada después de que un driver haya quitado los escapes no representa lo mismo que una captura serie cruda. Si un analizador aplica el ACCM, el modo de stuffing o el FCS equivocados, puede producir un “checksum incorrecto” que el extremo nunca calculó.

Un registro mínimo debe conservar dirección, mapas de envío y recepción, modalidad de enlace, forma del FCS, punto de captura, fase de decodificación, contadores de trama inválida y bytes crudos y reconstruidos.

El polinomio no autenticaba al par

RFC 1570 definió alternativas Null, de 16 y de 32 bits, negociadas por dirección y limitadas por fase. RFC 1662 también recomendó 32 bits cuando NRZI debilitaba las propiedades de detección del FCS de 16. Eran decisiones sobre errores, no sobre identidad.

La sección de seguridad de RFC 1662 advierte por separado que la capa de enlace puede no enterarse de un cambio en la conexión física y que una inserción o una identidad de llamada suplantada puede romper supuestos ajenos al framing. Una trama procedente de la continuidad física equivocada puede llevar un FCS perfecto. El cálculo responde si unos bits concuerdan con su control, no si el remitente estaba autorizado.

La aportación histórica de PPP fue definir una excepción pequeña. Permitió que la ruta adaptara la representación sin redefinir la carga, porque las exclusiones eran reversibles, direccionales y enumeradas. Convertir esa excepción en permiso general para borrar bytes destruiría el límite de integridad que debía conservar.

Fuentes