Resumen

  • RFC 938 definió PORT NAK para un DATA cuyo número de secuencia cae en la ventana de acuse pero cuyo puerto de destino es desconocido: el receptor devuelve su rcv_nxt actual y descarta los datos.
  • El NAK reconoce recepción acumulada hasta esa frontera de secuencia y rechaza el número de puerto. No demuestra recepción, interpretación, autorización, persistencia ni finalización por parte de una aplicación.

Una de las frases más disciplinadas de la historia temprana de los protocolos aparece en un documento de alcance modesto. RFC 938, el Internet Reliable Transaction Protocol, dice que PORT NAK hace NAK del puerto, no del número de paquete. La precisión parece pequeña, pero evita una inflación frecuente: convertir un acuse de transporte en una prueba de que un servicio aceptó aquello que viajaba dentro.

El registro de información de RFC 938 lo clasifica como experimental/propuesto y está fechado en febrero de 1985. Por eso el texto aporta evidencia de un diseño, no de adopción masiva, rendimiento, tráfico real o uso vigente. La lección histórica está en la frontera que el diseño se negó a borrar.

IRTP funcionaba encima de IP. RFC 791 establece que el campo Protocol de IP identifica el protocolo de nivel siguiente. El registro IANA de números de protocolo mantiene hoy el 28 para IRTP con referencia a RFC 938. Esa asignación coordina un espacio de nombres; no certifica una instalación ni la actividad de una red.

La cabecera no confundía secuencia con destino local

La cabecera IRTP ocupaba ocho octetos: tipo, puerto, secuencia, longitud y suma de comprobación. El RFC enumeraba cinco tipos: SYNCH, SYNCH ACK, DATA, DATA ACK y PORT NAK. Dos de sus campos planteaban preguntas distintas. La secuencia pertenecía a la relación fiable entre hosts. El puerto representaba el protocolo superior o proceso local al que iban dirigidos los datos.

Un proceso podía reclamar varios puertos, pero sólo uno podía reclamar un número concreto. Además, la relación IRTP no era una conexión distinta por cada combinación host-puerto. La tabla del módulo se organizaba por dirección Internet remota y llevaba, entre otras variables, snd_nxt, rcv_nxt y snd_una. SYNCH y SYNCH ACK ayudaban a establecer o resincronizar ese estado entre el par de hosts.

El puerto, por tanto, no era el nombre de la conexión fiable. Era una pregunta local que surgía cuando un paquete de datos, ya evaluado dentro de la relación entre hosts, pedía un destinatario concreto. La proximidad de ambos campos no les concedía la misma autoridad.

Primero la ventana; después el puerto

La rutina de recepción de RFC 938 marca el orden. Ante un DATA, el módulo comprueba primero que el número de secuencia esté dentro de la ventana de acuse. Para un paquete que sí entra, recalcula rcv_nxt. Sólo entonces distingue entre un puerto conocido y uno desconocido.

Con un puerto conocido, la especificación permite encolar los datos para el proceso de usuario después de enviar un DATA ACK. Con un puerto desconocido, el módulo envía un PORT NAK y tira los datos. Ambos tipos de respuesta llevan el rcv_nxt actual en el campo de secuencia. Por ello el mismo intercambio puede contener una afirmación de progreso de recepción y una negativa de despacho local.

El RFC no deja ese resultado a una interpretación posterior: el PORT NAK acusa recepción de todos los números de paquete hasta el número que contiene su campo de secuencia. Lo que niega es el puerto. No pide volver a enviar ese número de paquete, ni abre un canal hacia un proceso que no lo había reclamado.

Es útil decir la consecuencia en negativo. El receptor pudo retener un hecho sobre la secuencia host a host a la vez que desechaba el contenido. Un contador de ACK no convierte la carga en mensaje aceptado. Una etiqueta de puerto no crea por sí sola un dueño local.

Entrega es una cadena, no una palabra única

Una captura con PORT NAK puede respaldar dos observaciones acotadas: que el módulo IRTP trató el paquete como perteneciente al rango relevante de recepción y notificó una frontera acumulada; y que, en ese momento, no conocía un proceso que hubiera reclamado el puerto. Nada más se sigue automáticamente.

No se deriva que la aplicación leyera bytes, que un parser los aceptara, que el emisor fuera auténtico, que una política autorizara la solicitud, que se almacenara un registro o que un trabajo terminara. Tampoco se deriva una ausencia permanente del servicio. La reclamación de un puerto es una condición local y temporal; el NAK fija una observación en un estado concreto.

Conviene conservar capas de evidencia separadas. La capa de secuencia describe el módulo y su relación con un host remoto. La capa de puerto describe una asignación local a un proceso. La capa de aplicación, si existe, tiene otras pruebas y otros responsables: validación, identidad, derechos, transacción y almacenamiento. Confundirlas permite que una afirmación mecánica de la primera capa hable por una decisión que pertenece a la última.

La Nota 64 de Heng Lu ofrece una forma útil de leer esa cautela. Una regla común puede ser mínima, determinista y verificable dentro de su propio alcance. No por eso decide qué actor local debe asumir una carga ni qué significado institucional tiene una carga útil. El cable puede comunicar un límite de secuencia; no puede otorgar autoridad a un proceso inexistente.

Fiabilidad con decisiones que quedaron locales

IRTP especificaba chequeo, sincronización, acuses y una obligación de contar con un mecanismo de retransmisión. También exigía retransmitir snd_una cuando correspondiera. Pero no imponía una única política de temporizadores o rendimiento. Esa elección se mantenía en la implementación.

También era limitada la alusión a un tiempo de silencio de dos minutos cuando se conoce una dirección remota. RFC 938 remite allí a RFC 793. La referencia ayuda a interpretar una precaución de diseño; no convierte IRTP en TCP, no vuelve equivalentes sus semánticas y no prueba una historia de despliegue común.

Por eso “reliable” no significa que el proceso esperado esté disponible, y “transaction” no significa que una tarea esté consumada. El protocolo proponía una disciplina para secuencia y un resultado para la búsqueda de puerto. Precisamente dejó intacto el espacio entre ambas cosas.

Guardar evidencia que no se contradiga más tarde

Un informe útil sobre PORT NAK conserva dirección remota, puerto, número recibido, rcv_nxt devuelto, ventana aplicable, época de la conexión, suma de comprobación, tipo de paquete, sincronización y estado de reclamación del puerto. La política local de temporización y retransmisión también merece un registro independiente, porque la especificación no la fijó.

Así se puede distinguir un puerto no reclamado de un paquete que falló antes la suma o la ventana; un reinicio con resincronización de un fallo de aplicación; una retransmisión del par de una aceptación de datos. “No entregado” es una conclusión demasiado gruesa para señales que apuntan a superficies de control diferentes.

Fuentes y límites

RFC 938 aporta la semántica de la cabecera y del PORT NAK; su ficha aporta el estado experimental/propuesto; RFC 791 acota el papel del campo Protocol; RFC 793 sólo apoya la comparación sobre tiempo de silencio; e IANA documenta la asignación 28. Ninguna de estas fuentes cuantifica adopción, tráfico, rendimiento o uso actual.

Tampoco demuestran propiedades de seguridad ni resultados empresariales. El interés de este NAK está justamente en que permite una verdad de recepción sin fingir una verdad de aplicación.