Resumen

  • La opción Alternate Checksum Request, Kind 14, solo cambiaba la conexión si los dos SYN llevaban exactamente el mismo número de algoritmo. La ausencia, el desacuerdo o el silencio de un stack antiguo devolvían toda la sesión al checksum TCP estándar.
  • Los SYN y RST siempre mantuvieron el cálculo estándar. La variante Fletcher de 32 bits necesitaba además Kind 15 en los segmentos aplicables. RFC 4614 registró después falta de interés y RFC 6247 declaró Historic el mecanismo y obsolete sus dos opciones.

Una salida que no podía recordar la negociación

TCP necesita responder a segmentos que no pertenecen a una conexión conocida. Un host puede enviar RST precisamente porque no tiene el estado que el emisor supone. Pedirle que recupere un algoritmo alternativo acordado en un handshake anterior convertiría el rechazo sin estado en una operación dependiente del estado ausente.

RFC 1146 evitó la contradicción: los RST debían usar siempre el checksum TCP estándar. El receptor podía interpretar la negativa con la regla compartida por cualquier implementación, aunque los segmentos ordinarios de una conexión válida hubieran usado otro cálculo.

Los SYN también permanecían en el estándar, pero por una razón temporal. Transportaban la propuesta antes de que existiera un acuerdo. La entrada y la salida universal conservaron la lengua antigua; la alternativa quedó circunscrita al interior de una sesión cuyos dos extremos sí conocían el resultado.

Esta excepción importa al leer capturas. Un RST con suma estándar no prueba que el acuerdo falló. Un SYN estándar tampoco contradice la presencia de Kind 14. Tipo de segmento y estado de conexión delimitan qué algoritmo era legítimo.

La propuesta debía sobrevivir antes de poder cambiar la regla

RFC 793 definió el checksum TCP como el complemento a uno de la suma de palabras de 16 bits del encabezado, los datos y el pseudoencabezado. RFC 9293 mantiene la obligación: el emisor debe generarlo y el receptor debe verificarlo.

Antes del primer SYN, esa era la única regla de integridad común. Si el mensaje que proponía un algoritmo nuevo hubiese estado protegido ya por ese algoritmo, el destinatario habría tenido que aceptar el método antes de leer de forma fiable la solicitud.

Por eso Kind 14 viajaba dentro de un SYN validado con el checksum estándar. El receptor abría el sobre con la regla conocida y luego examinaba la petición para los segmentos futuros.

La antigua suma no era un residuo que el experimento olvidó retirar. Era la autoridad de arranque. Una nueva interpretación del mismo campo solo podía nacer de mensajes que ambos lados ya sabían comprobar.

Dos SYN daban dos permisos independientes

Alternate Checksum Request tenía Kind 14 y longitud de tres octetos. El último indicaba el algoritmo: 0 para el estándar, 1 para Fletcher de 8 bits con resultado de 16, y 2 para Fletcher de 16 bits con resultado de 32.

Un SYN podía ofrecer uno de esos valores. El SYN de la otra dirección debía incluir Kind 14 con el mismo valor exacto. Solo ese par habilitaba la alternativa.

Si una parte elegía 1 y la otra 2, la especificación no ordenaba negociar el menor ni respetar una preferencia. Se usaba el estándar durante toda la conexión. Si faltaba una de las opciones, ocurría lo mismo.

La decisión no se heredaba de una sesión anterior ni se infería de la versión del software. Cada conexión exigía dos actos observables. El iniciador no tenía poder para hablar en nombre del respondedor; ambos iban a interpretar los segmentos, así que ambos debían producir una elección.

El host antiguo convertía ignorancia en fallback

RFC 1122 exige que una opción TCP desconocida con longitud se ignore sin error. Un stack anterior a RFC 1146 podía saltar Kind 14 y responder con un SYN ordinario.

El stack nuevo no trataba la falta de respuesta coincidente como consentimiento tácito. Veía que la condición bilateral no se había cumplido y mantenía el checksum estándar para toda la sesión.

Así, un despliegue parcial no producía dos interpretaciones incompatibles. El host antiguo hacía exactamente lo que siempre había hecho; el nuevo asumía la responsabilidad de regresar a la base.

El mecanismo protegía la conectividad, aunque también ocultaba la no adopción. Una aplicación veía que connect() funcionaba. Sin telemetría del handshake, no sabía si la alternativa había sido aceptada o si el fallback había salvado la llamada.

El resultado largo abrió un segundo carril

Fletcher de 8 bits producía 16 bits y cabía en el campo existente. Fletcher de 16 bits producía 32. RFC 1146 puso la parte A en el campo normal y la parte B en Alternate Checksum Data, Kind 15.

Kind 15 no repetía el permiso. Era una carga recurrente de los segmentos ordinarios aplicables después de seleccionar el algoritmo 2. Consumía espacio de opciones y obligaba a parsers, analizadores y endpoints a conservar el estado de la negociación.

Una Kind 15 mal formada o usada donde no correspondía debía provocar descarte, RST y aborto de la conexión. La tolerancia del comienzo no se extendía a un campo de integridad ambiguo después del acuerdo.

Hay una frontera coherente. Antes de compartir estado, ignorar lo desconocido conserva la base. Después de compartirlo, aceptar una representación incompleta rompe la promesa de que ambos lados juzgan los mismos bytes de la misma forma.

El éxito de TCP no medía el éxito de la opción

El fallback permitía instalar código en un extremo sin interrumpir a los demás. Eso reducía el peligro de experimentar en una red heterogénea.

La ventaja del nuevo algoritmo, sin embargo, solo aparecía si ambos extremos se actualizaban, escogían el mismo número y el camino conservaba las opciones. El coste de implementación podía llegar primero a muchas máquinas; el beneficio requería parejas coincidentes.

Una métrica de conexiones establecidas absorbía las dos salidas. Contaba igual una sesión alternativa y una sesión que volvió silenciosamente al estándar. La compatibilidad eliminaba el síntoma que habría revelado la falta de coordinación.

El mismo diseño que facilitaba desplegar el primer endpoint elevaba la dificultad de justificar el segundo. El fallback seguro y la fricción de adopción eran dos consecuencias de no permitir un cambio unilateral.

Experimental describía el mandato limitado

RFC 1146 apareció en marzo de 1990 con categoría Experimental y declaró que no se recomendaba para sistemas de producción. Era una especificación para probar interoperabilidad, no un calendario de sustitución.

RFC 1071 documentó propiedades y técnicas de aplicación del Internet checksum estándar. Da contexto a la base, pero sus ejemplos —algunos con held errata— no prueban que Alternate Checksum se desplegara.

En 2006, RFC 4614 señaló que el trabajo no había atraído interés. Esa frase no autoriza a afirmar que jamás existió una implementación ni que Fletcher era matemáticamente inválido. Describe la atención recibida por la propuesta.

En 2011, RFC 6247 trasladó RFC 1146 a Historic, observó que no había alcanzado despliegue amplio y ordenó marcar Kind 14 y 15 como obsolete. Su análisis específico de spoofing se refiere a T/TCP; no debe atribuirse al mecanismo de checksum como motivo de retirada.

La conclusión respaldada es sobria: una extensión experimental y bilateral no obtuvo interés ni implantación suficientes para permanecer como vía actual, y el proceso de estándares cerró su estado.

La memoria del registro no es tráfico vivo

El registro TCP Parameters de IANA conserva Kind 14 y 15 con la marca obsolete. También conserva los números 0, 1, 2 y 3 en la tabla de Alternate Checksum Algorithms.

La permanencia permite interpretar paquetes históricos y evita reasignar un código con un significado incompatible. Prueba qué se reservó y cuál es su estado registrado.

No prueba soporte actual, prevalencia ni recomendación. Una fila de IANA no ha visto los dos SYN de una conexión. Tampoco obsolete significa que todos los dispositivos antiguos hayan dejado de emitir el campo.

Las pruebas pertenecen a capas distintas: registro para semántica y estado; captura bilateral para acuerdo; segmentos posteriores para uso; inventario de implementaciones para alcance. Una sola capa no debe hablar por las demás.

La salida común fijó el tamaño real de la innovación

El RST estándar muestra que la nueva regla nunca poseyó todo TCP. Gobernaba una región temporal y bilateral: segmentos ordinarios de una conexión cuyos dos participantes habían coincidido.

Fuera de esa región, la base continuaba disponible. Un peer antiguo podía ignorar la propuesta; un host sin estado podía rechazar; una discrepancia podía regresar al estándar. No había que adivinar intención.

La suma nueva tuvo que pedir permiso a la antigua porque solo la antigua podía verificar la petición antes del acuerdo. Conservó además una salida antigua porque ningún acuerdo de conexión podía obligar a quien carecía de esa conexión. Esas dos fronteras hicieron segura la prueba y, a la vez, dejaron claro cuánto trabajo coordinado requería convertirla en práctica.

Fuentes