Resumen

  • RFC 1335 proponía que cada host conservara una dirección permanente dentro de su red y obtuviera temporalmente una dirección externa, globalmente única, de un External Address Sharing Service (EASS).
  • El texto era informativo y se presentaba como una “idea”, no como informe de despliegue: las pruebas disponibles no muestran que los operadores lo implantaran ni que resolviera el agotamiento de IPv4.

Solemos imaginar la dirección de Internet como una etiqueta pegada a una máquina. RFC 1335 preguntaba si esa etiqueta debía ser global en todo momento. Su respuesta, formulada en medio de la preocupación de principios de los años noventa por el espacio de 32 bits, separaba la dirección útil dentro de una red de la dirección escasa necesaria para comunicarse fuera de ella.

El propio memorando es explícito sobre su condición. Fechado en mayo de 1992, se declara informativo, dice que no especifica un estándar de Internet, se describe como un documento de “ideas” e invita al debate. Eso importa: muestra lo que una propuesta consideraba posible, no que existiera un servicio operativo. RFC 1335

La presión partía del sistema de asignación por clases tal como lo describían sus autores. Una tabla rotulada abril de 1992 contaba 7.006 redes de clase B asignadas de un total de 16.383 y advertía que el espacio B podía agotarse pronto si continuaba el crecimiento. La clase C ofrecía muchos más números de red, pero solo 254 números de host por red, insuficientes para la mayoría según el memorando. Son cifras y pronósticos contemporáneos del documento, no una medición retrospectiva de cuándo ocurrió el agotamiento.

RFC 1335 comparaba la propuesta con opciones que se debatían entonces. El supernetting y lo que llamaba C-sharp reorganizarían las asignaciones de clase C, pero, según el memorando, exigirían cambios en el enrutamiento exterior y quizá coordinación global. Otras familias reutilizarían el campo de 32 bits con otro significado y reescritura en los límites, lo que, a juicio de los autores, requeriría cambios sustanciales en gateways y enrutamiento. Es la caracterización que hace el memorando de esas alternativas, no una evaluación neutral de cada una.

Dual Network Addressing (DNA) dividía el trabajo. Cada máquina conservaría una dirección interna, única solo dentro de su propia red, como dirección permanente allí. La red mantendría además un fondo limitado de direcciones externas globalmente únicas. Cuando un host necesitara comunicarse con otra red, podría pedir una dirección externa temporal al External Address Sharing Service local y devolverla después. El EASS era un punto administrativo y técnico de asignación entre el uso local y el alcance global; no una afirmación de que una dirección autentique a una persona, máquina o transacción.

La política no era simplemente “todos comparten”. RFC 1335 describía tres clases: las máquinas que necesitaran comunicaciones frecuentes entrantes y salientes podrían recibir direcciones externas permanentes; las que tuvieran prohibida la comunicación exterior no recibirían ninguna; y las demás compartirían direcciones temporales para comunicaciones iniciadas por el cliente, sin aceptar llamadas desde fuera según el modelo descrito. La asignación se convertía así tanto en una cuestión de política operativa como de formato de paquetes.

Para que funcionara, los hosts necesitarían cambios de software que admitieran dos interfaces o direcciones IP lógicas en una interfaz física. El memorando también proponía un DNS sensible al origen: un servidor de nombres devolvería una dirección interna o externa según el origen de la consulta. Sugería que DHCP podía prestar la función de EASS. Esa sugerencia no demuestra que DHCP implantara DNA ni que ambos sistemas compartieran una genealogía directa.

La adopción gradual desde cada red es su rasgo de gobernanza más interesante. RFC 1335 sostenía que distintas redes podrían adoptar DNA en momentos diferentes sin cambiar los algoritmos de enrutamiento exterior ni afectar a quienes no lo adoptaran. La intervención propuesta se desplazaba así desde la coordinación global del enrutamiento hacia los fondos locales, el software de los hosts y las políticas de cada red. Pero el documento no aporta registros de despliegue, pruebas de interoperabilidad, observaciones de tráfico ni cifras de adopción para comprobar esa promesa.

Los documentos posteriores sirven para marcar límites, no una sucesión demostrada. RFC 1518 y RFC 1519 establecieron CIDR como estrategia normalizada para asignar direcciones y agregar rutas; CIDR opera en la escala de prefijos y enrutamiento, no en la de direcciones internas y fondos temporales de DNA. RFC 1531 especificó después DHCP como marco de configuración que incluía asignaciones reutilizables, sin demostrar que se implantara EASS. RFC 1631 describió la traducción de direcciones en una frontera: es una comparación acotada, no prueba de que DNA causara NAT. Y RFC 1752 registra una recomendación de IPng aceptada por la IESG, una decisión institucional distinta del documento abierto de ideas de RFC 1335. RFC 1287 · RFC 1518 · RFC 1519 · RFC 1531 · RFC 1631 · RFC 1752

RFC 1335 permite separar con claridad propuesta y resultado. El problema de la escasez podía abordarse cambiando quién recibe un número globalmente único, durante cuánto tiempo y bajo qué política local, no solo ampliando o reorganizando el sistema global de enrutamiento. El texto no dice que el modelo se desplegara, fuera seguro o interoperable, ni que tuviera éxito. Incluso señala que no trata los aspectos de seguridad. Una dirección temporal puede ser un mecanismo de asignación; no es identidad, permiso, prueba de alcanzabilidad ni constancia de que una comunicación de aplicación terminó.