Resumen

  • Data Offset señala el final físico de la cabecera; EOL señala el final lógico de las opciones.
  • NOP puede ajustar la posición de la opción siguiente, pero TCP no exige alineación al receptor.

Leer un espacio variable

Un receptor avanza por octetos. Puede encontrar Kind 1, NOP, y avanzar un byte; después puede leer una opción con longitud y saltar su extensión completa. Si encuentra Kind 0, EOL, termina la interpretación significativa. Los bytes que quedan hasta el límite indicado por Data Offset son relleno cero: la carga útil aún empieza en ese límite.

RFC 793 ya separaba dos formatos. EOL y NOP contienen solo el tipo; las demás opciones contienen tipo, longitud y datos. La longitud incluye los bytes de tipo y longitud. RFC 9293 conserva esta estructura y exige longitud para toda opción distinta de EOL y NOP, incluidas las futuras. Así, un receptor puede ignorar una opción desconocida sin perder el siguiente límite, siempre que la longitud sea válida.

Alineación opcional

Un emisor puede insertar NOP para colocar una opción posterior en un límite de palabra. No es una condición del protocolo. RFC 793 pedía aceptar opciones que no comenzaran en un límite de palabra y RFC 9293 mantiene esa obligación. Tampoco hay una garantía general de que NOP mejore el rendimiento.

EOL no sustituye a Data Offset, no acorta la cabecera y no inicia los datos. Solo cierra la lista lógica. Si aparece antes del límite físico, el espacio restante debe ser cero. EOL no se repite después de cada opción y no hace falta cuando las opciones llegan naturalmente al final de la cabecera.

Una extensión prudente

Las longitudes permiten atravesar significados desconocidos. Las longitudes cero o incoherentes son ilegales y requieren tratamiento defensivo. La continuidad entre RFC 793 y RFC 9293 muestra que la extensibilidad depende tanto de poder avanzar como de reconocer una opción.

Sources