Resumen

  • RFC 3102 permitía que un host de un ámbito privado usara una dirección pública completa o una dirección compartida con puertos, bajo un bind y un arrendamiento administrados por la pasarela.
  • La visibilidad del parámetro público no resolvía el camino: el host debía distinguir destinos locales y públicos, y no había una solución general para aplicaciones multiparte entre ámbitos.

Dos direcciones para un solo host

La intuición de RSIP se ve mejor desde el host. Una dirección privada le permitía existir en la red local y llegar a la pasarela. Para hablar con el exterior, pedía otra representación: una dirección del ámbito público y, a veces, un conjunto limitado de puertos. Esa segunda presencia no reemplazaba la primera. Las dos coexistían, y el host tenía que saber cuándo usar cada una.

En NAT tradicional, la traducción ocurría en el borde sin que el host necesitara conocerla. Eso facilitaba el despliegue, pero rompía protocolos que transportaban direcciones o dependían de que el encabezado no cambiara. Los RFC 3102–3105 propusieron mover la información pública a la pila del extremo. El host construía el paquete con la fuente prestada y lo enviaba encapsulado a la pasarela; la pasarela quitaba el túnel y lo encaminaba.

RSA-IP entregaba una dirección entera y única durante el plazo. RSAP-IP entregaba una dirección que podía compartirse y puertos exclusivos dentro de ella. La primera se parecía a una dirección temporal; la segunda descomponía lo que parecía una identidad única en recursos más pequeños. En ambos modos la pasarela conservaba el pool y decidía la concesión.

Por eso «prestar» es más preciso que «trasladar». El parámetro aparecía dentro del host y de sus paquetes, pero no salía del control del borde.

La concesión se convertía en una máquina de estados

RFC 3103 describía el diálogo. El host se registraba y obtenía un identificador de cliente. Solicitaba recursos y recibía una respuesta con dirección, puertos, identificador de vínculo, duración, túnel y política. Podía ampliar el plazo, consultar, pedir escucha para tráfico entrante, liberar un vínculo y cancelar el registro.

La riqueza del protocolo evita una simplificación peligrosa. Estar registrado no significaba tener una dirección. Tener una asignación no significaba haberla instalado. Un bind no demostraba que el túnel transportara datos. Un paquete de ida no demostraba retorno. Cada paso tenía su propia autoridad y su propio reloj.

La pasarela podía negar una dirección sugerida si estaba ocupada, si no quedaban recursos o si la política la prohibía. También debía descartar paquetes que usaran una dirección, un puerto, un destino o un túnel no autorizados. El host controlaba la construcción del paquete; la pasarela controlaba si esa construcción correspondía a una concesión vigente.

Para reconstruir un incidente hay que conservar petición y respuesta, identificador de cliente, bind, recursos exactos, política remota, vida del arrendamiento, ruta del host, encapsulación, decisión en la pasarela y tráfico en ambos sentidos. Una columna llamada «asignado» no alcanza.

Elegir lo local era parte del protocolo

El host tenía que decidir si un destino pertenecía a su red privada o si debía salir por la interfaz RSIP. En una subred sencilla podía usar la máscara. En redes más complejas, RFC 3102 permitía que la pasarela almacenara redes y máscaras privadas y respondiera consultas.

La solución envejecía con la topología. Si las rutas cambiaban durante una sesión, el host podía necesitar una pregunta nueva por cada destino. El RFC no ocultó el límite: no se conocía una solución general robusta y tampoco se sabía cuán grave sería en la práctica.

Las aplicaciones multiparte convertían el problema en contradicción. Una parte podía entregar una dirección a otra como si fuera un identificador global. Un receptor local necesitaba quizá la dirección privada; uno externo, la pública. Forzar siempre la representación pública podía llevar incluso el tráfico local por la pasarela. RFC 3102 admitía que no había arreglo universal.

La dirección, entonces, no era contexto suficiente. Hacían falta la posición del observador, el estado de rutas y la política del host. La localidad pasó de ser una intuición del cableado a una decisión explícita y posiblemente obsoleta.

El fin del arrendamiento no borraba el pasado

El tiempo limitaba la concesión. Un host podía extenderla o liberarla; la pasarela podía dejarla vencer o retirar recursos. Esto permitía recuperar direcciones y puertos, pero no sincronizaba automáticamente todos los estados dependientes.

TCP podía mantener el antiguo par en TIME_WAIT. Si un puerto regresaba al pool y se reasignaba demasiado pronto, la nueva sesión heredaba el riesgo de paquetes o protecciones de la anterior. La expiración administrativa y la reutilización segura no eran el mismo hecho.

Los reinicios también separaban memorias. Después de fallar el host, la pasarela podía conservar vínculos que el cliente ya no recordaba. Después de fallar la pasarela, el host podía creer válida una asignación que el servidor había perdido. RFC 3103 definía intercambios para rehacer la relación, pero ninguna de las dos copias bastaba por sí sola.

Un control operativo debe comparar inicio, extensión, liberación, expiración, reinicios y primer paquete aceptado después de reconciliar. Si se mira solo la dirección, varias generaciones de autoridad parecen una sola.

Compartir el localizador rompía la identidad aparente

Con RSA-IP, el DNS dinámico podía tratar la dirección como una cesión temporal completa. Con RSAP-IP, varios nombres podían apuntar al mismo número mientras los servicios pertenecían a hosts distintos según el puerto. Un observador externo podía creer que todo lo alojado allí era un único sujeto. El RFC aconsejaba cautela al mezclar esa modalidad con DNS.

RFC 3104 llevó la separación a IPsec. Varios clientes detrás de una misma dirección pública podían iniciar IKE y ESP o AH frente a un par que no conocía RSIP. La dirección visible ya no identificaba al par real. Los identificadores de IKE debían cumplir esa función.

Para devolver IKE, la pasarela podía usar puerto de destino, cookie del iniciador y dirección de destino. Para AH o ESP usaba protocolo, SPI y dirección. El SPI debía ser único tanto para el cliente como para el espacio compartido de la pasarela. Una dirección común era un punto de entrega, no un principal criptográfico.

El mecanismo no cubría todas las iniciaciones desde fuera y requería cooperación de la implementación IPsec. Incluso con encabezados internos intactos, la aplicación no obtenía transparencia gratis.

Descubrir el servidor no equivalía a ser admitido

RFC 3105 usó SLP para anunciar service:rsip, capacidades, vida de la publicación y carga. Los ámbitos podían dirigir grupos de clientes a una pasarela; un cliente podía elegir el servidor con menos conexiones declaradas.

Pero el ámbito de SLP no era control de acceso. La publicación mostraba una oferta, no un derecho. La carga podía cambiar antes de conectar. Tras descubrir todavía había que registrarse, recibir recursos, instalar el camino y probarlo.

Esa separación revela quién controlaba cada superficie. El administrador configuraba descubrimiento y ámbito. La pasarela otorgaba recursos y política. El host escogía localidad y formaba paquetes. El par remoto aceptaba identidades y sesiones. El resultado pertenecía a la observación del tráfico, no a una sola base de datos.

Experimental no significaba invisible

Los RFC 3102–3105 fueron Experimentales. La nota del IESG destacó cambios importantes en hosts y pasarelas, problemas con puertos flotantes y complejidad operativa. El propio marco dijo que RSIP no era una solución duradera a la escasez de direcciones. Las fuentes no prueban adopción amplia ni victoria sobre NAT.

Su valor histórico está en otra parte. RSIP obligó a nombrar los componentes que una traducción transparente reunía dentro del borde: registro, concesión, arrendamiento, política, túnel, descubrimiento, recuperación y elección de ámbito.

Una dirección pública prestada podía aparecer intacta en el paquete. No por eso demostraba propiedad, identidad única, ruta correcta, autenticación o entrega. La pasarela prestaba el localizador; el servicio solo existía cuando todas las piezas y ambos sentidos del tráfico coincidían.

Sources

  1. https://www.rfc-editor.org/rfc/rfc3102.html
  2. https://www.rfc-editor.org/info/rfc3102
  3. https://datatracker.ietf.org/doc/rfc3102/
  4. https://www.rfc-editor.org/rfc/rfc3103.html
  5. https://www.rfc-editor.org/info/rfc3103
  6. https://datatracker.ietf.org/doc/rfc3103/
  7. https://www.rfc-editor.org/rfc/rfc3104.html
  8. https://www.rfc-editor.org/info/rfc3104
  9. https://datatracker.ietf.org/doc/rfc3104/
  10. https://www.rfc-editor.org/rfc/rfc3105.html
  11. https://www.rfc-editor.org/info/rfc3105
  12. https://www.rfc-editor.org/rfc/rfc1631.html
  13. https://www.rfc-editor.org/rfc/rfc2663.html
  14. https://www.rfc-editor.org/rfc/rfc2993.html
  15. https://www.rfc-editor.org/rfc/rfc3022.html