Resumen

  • IPv4 comprobaba únicamente su cabecera mutable. Cada router podía verificarla, reducir TTL o cambiar campos permitidos y dejar un nuevo checksum para el estado resultante, sin garantizar los datos.
  • TCP y UDP incluían cabecera, contenido y una pseudocabecera con direcciones, protocolo y longitud. Esa cobertura ayudaba a descubrir entregas equivocadas, pero no autenticaba a nadie ni certificaba la ruta.
  • La aritmética de complemento a uno tiene cero positivo y negativo. RFC 1141 podía generar 0xFFFF cuando el recálculo completo producía 0x0000; RFC 1624 corrigió el límite. IPv6 retiró el checksum de su cabecera base, no la responsabilidad de las capas superiores.

La cabecera que cambiaba en tránsito

TTL disminuye en cada punto de procesamiento de IPv4. La fragmentación modifica longitud, banderas y desplazamiento. Algunas opciones también pueden alterar la cabecera. El router no recibe una pieza destinada a permanecer sellada.

RFC 791 define el checksum como el complemento a uno de la suma en complemento a uno de todas las palabras de dieciséis bits de la cabecera. Durante el cálculo, el propio campo vale cero. La cobertura termina en la cabecera.

El router valida la versión entrante, descarta un fallo, realiza una modificación autorizada y actualiza el valor. No conserva una firma del origen: produce una afirmación local sobre la cabecera que enviará. Su vigencia dura una versión y un tramo entre puntos de procesamiento.

El RFC también excluye control de errores sobre los datos, acuses y retransmisiones. Aprobar el checksum IPv4 no dice que el payload esté intacto. Protege la información que IP necesita para procesar, no todo lo que viaja detrás.

Tres ámbitos dentro del mismo paquete

IPv4 suma su propia cabecera. RFC 768 hace que UDP sume cabecera, datos y pseudocabecera. RFC 793 cubre cabecera y texto TCP más una pseudocabecera de 96 bits.

La separación permite reducir TTL sin tocar el resultado de transporte. El router renueva IPv4; los extremos conservan TCP o UDP. Una comprobación de enlace puede rodear además la trama, pero sólo habla de una adyacencia.

Superar varias comprobaciones no las fusiona en una garantía. Cada una posee su propio material, productor y caducidad. Ninguna conoce por sí sola la identidad institucional, la política aplicada o la historia completa del camino.

Datos IP prestados al transporte

La pseudocabecera UDP reúne dirección de origen, destino, protocolo y longitud UDP. TCP usa origen, destino, protocolo y longitud TCP. No se transmite como bloque separado: el receptor reconstruye esos datos y los incluye en su cálculo.

RFC 768 y RFC 793 indican que así se obtiene protección contra datagramas o segmentos mal encaminados. Un segmento intacto no debería validarse con facilidad si aparece bajo otro destino o protocolo.

Sin embargo, la suma no autentica. Quien crea un paquete puede calcularla; quien modifica deliberadamente los campos cubiertos puede renovarla. No demuestra titularidad de una dirección, exactitud registral, licitud de una ruta ni ausencia de interceptación.

El transporte toma sólo los hechos de red de los que depende. Cruzar una frontera de capa para calcular no le concede autoridad sobre esa capa.

El valor semántico de dos ceros

En complemento a uno, 0x0000 es cero positivo y 0xFFFF cero negativo. RFC 768 utiliza ambas representaciones: si el checksum UDP calculado da cero, se transmite todo unos; un campo transmitido todo ceros significa que el emisor no generó checksum.

Así, 0xFFFF puede representar una comprobación válida cuyo resultado fue cero, mientras 0x0000 puede indicar omisión en UDP sobre IPv4. El protocolo conserva la diferencia entre «calculado» y «no calculado» aunque la aritmética permita tratar los dos valores como equivalentes.

RFC 8200 cierra esa opción por defecto en IPv6. UDP debe calcular el valor; cero se codifica 0xFFFF, y el receptor descarta todo ceros. Sólo ciertos túneles UDP pueden emplear una excepción limitada bajo requisitos específicos.

Velocidad sin imponer una sola implementación

RFC 1071 describe propiedades que permitieron adaptar el cálculo a máquinas distintas. Respetando la posición par o impar de los bytes, la suma es conmutativa y asociativa: puede dividirse y reunirse. Puede ejecutarse en ambos órdenes de bytes, con acumuladores más anchos, bucles desplegados o trabajo paralelo. Si sobra un byte, se añade un cero sólo para calcular.

El contrato fija qué se suma y qué bits deben salir, no un programa universal. Esa autonomía termina donde cambia el resultado. Perder el último byte, mezclar su paridad o plegar mal el acarreo deja de ser una optimización compatible.

Cambiar TTL sin recorrer todo

Cuando un router reduce TTL conoce la palabra afectada. RFC 1141 explica cómo actualizar el checksum almacenado retirando el valor anterior y añadiendo el nuevo. Para reducir TTL en uno, se agrega 1 o 256 según su posición, usando complemento a uno.

RFC 1624 menciona también fragmentación y actualización de source route. El ahorro es razonable: el coste sigue al cambio. Pero el resultado incremental debe ser idéntico al de sumar desde cero la cabecera revisada.

Una igualdad que fallaba justo en cero

RFC 1624 documenta que la fórmula anterior asumía una propiedad distributiva que no se mantiene cuando el resultado es cero. En su ejemplo, una palabra cambia de 0x5555 a 0x3285 y el resto suma 0xCD7A. El recálculo completo produce 0x0000; el método de RFC 1141 produce 0xFFFF.

Una cabecera IP contiene al menos un campo no nulo. La suma en complemento a uno de entradas no nulas puede producir cero negativo, nunca positivo; después del complemento final, el campo puede ser 0x0000, pero 0xFFFF no es un resultado canónico posible.

La fórmula corregida es HC' = ~(~HC + ~m + m'), con todas las adiciones en complemento a uno. Evita la transformación inválida y recupera la igualdad con el recálculo completo.

Algunos receptores sumaban también el campo recibido y comparaban con cero negativo, como recomendaba RFC 1071; en el ejemplo podían aceptar ambas formas. Otros recalculaban y comparaban directamente el valor. Pruebas de un producto encontraron la condición, y el análisis y la simulación validaron la corrección.

La tolerancia de ciertos destinos no convierte en canónica una salida imposible. El productor debe respetar el resultado común porque no controla la estrategia del receptor.

IPv6 redibujó la frontera

La cabecera base de IPv6 en RFC 8200 no incluye checksum de capa Internet. TCP, UDP e ICMPv6 sí incorporan una pseudocabecera IPv6 con direcciones de 128 bits, longitud de capa superior y Next Header.

El RFC explica que ICMPv6 necesita esa cobertura porque los campos IPv6 relevantes ya no están protegidos como en IPv4. Quitar el campo no significó declarar resuelta la integridad; trasladó el cálculo a los protocolos que dependen de esos datos.

IPv4 hacía que cada router verificara y renovara una pequeña afirmación incluso junto a controles de enlace y transporte. IPv6 eliminó ese trabajo repetido de la cabecera fija, conservó los controles de extremo y endureció la regla UDP por defecto.

Fuentes y límites

RFC 768 sustenta UDP y los ceros; RFC 791, IPv4; RFC 793, TCP; RFC 1071, las propiedades de cálculo; RFC 1141, la actualización; RFC 1624, la corrección; RFC 8200, la frontera IPv6.

No prueban un inventor único, una implementación universal, la prevalencia actual de offload ni una tasa concreta de errores no detectados. Un resultado válido no excluye modificación deliberada y recálculo; uno inválido no identifica por sí solo dispositivo, enlace o persona.

La conclusión histórica es acotada: al precisar bytes, productor y alcance, Internet hizo visibles muchas inconsistencias sin convertir una suma en testimonio sobre todo el paquete.