Resumen

  • ENCAPS planteaba que el router de entrada obtuviera del DNS direcciones de dominios autónomos, envolviera el datagrama en una cabecera IP adicional y que el router de salida retirara esa cabecera antes de continuar con el paquete original.
  • Evitar cambios en hosts y en la mayoría de routers no eliminaba el coste: creaba nuevos registros, asignaciones y rutas de dominio, procesamiento en ambos bordes y veinte bytes de sobrecarga por datagrama en tránsito.
  • RFC 1955 era informativo y advertía que publicarlo no equivalía a que IPng aceptara sus ideas. Dependía aún de direcciones IPv4 interiores globalmente únicas y no examinaba la seguridad.

La ruta nueva estaba fuera del paquete viejo

Un host emitía un paquete corriente, con una fuente y un destino IPv4 que no conocían ENCAPS. Al llegar al primer borde, el router consultaría una asociación de dominio, construiría una segunda cabecera y convertiría todo el datagrama en carga útil. El núcleo intermedio seguiría la dirección exterior. El último borde la quitaría y entregaría al enrutamiento habitual exactamente el paquete que había entrado.

No era traducción. La dirección antigua no se reemplazaba ni se ocultaba mediante una equivalencia irreversible. El exterior añadía un contexto de tránsito y luego debía desaparecer. Esa decisión evitaba varias obligaciones del traductor, pero no era gratuita: alguien debía saber qué dominio correspondía a cada nombre y qué salida podía devolver el paquete a su contexto original.

El documento apareció en junio de 1996, aunque relata que Robert Hinden había enviado la propuesta al grupo ROAD en enero de 1992, primero como correo. Más tarde se presentó al proceso de documentos sobre IPng. El propio texto impide una lectura triunfal: su publicación no significaba aceptación por el área IPng.

La fecha doble importa. RFC 1955 no es una fotografía de una Internet que ya funcionaba así. Es el archivo tardío de una opción pensada cuando el crecimiento parecía correr más deprisa que la capacidad de elegir y desplegar una arquitectura definitiva.

Dos urgencias, una solución deliberadamente temporal

ROAD distinguía el agotamiento inminente de números de clase B, el crecimiento de las tablas y el agotamiento eventual del espacio IPv4. También distinguía límites físicos de los routers y límites humanos: mantener políticas, filtros y rutas requería cada vez más trabajo.

La respuesta no podía ser secuencial. Las medidas inmediatas debían iniciarse al mismo tiempo que la investigación de largo plazo. Para la fase corta, cambiar hosts quedaba fuera de la mesa. ENCAPS heredó esa restricción y la convirtió en argumento central.

La propuesta enumeró lo que pretendía preservar: hosts sin cambios, casi todos los routers sin cambios, protocolos existentes, direcciones existentes y ausencia de traducción. A cambio, el sistema ganaría tiempo y reduciría el detalle que cada router necesitaba conservar.

Estas frases describen un objetivo de diseño. No constituyen una medición. En el paquete documental congelado no hay censo de implementaciones, reducción observada de tablas, prueba de interoperabilidad ni resultado comercial. La historia responsable conserva la distancia entre una ventaja prevista y una ventaja ejecutada.

El DNS alimentaba la cabecera de dominio

El router de entrada debía usar las direcciones interior de origen y destino para buscar las direcciones de dominio autónomo. La pareja obtenida formaría la fuente y el destino de la cabecera externa. De ese modo, el tránsito interdominio podría operar sobre dominios en lugar de cargar con cada red interior.

RFC 1955 propuso reservar una pequeña cantidad de redes de clase A y B para codificar esos dominios. Varios espacios permitirían agruparlos en “commonwealths”. Dentro de cada agrupación habría detalle; hacia las demás bastaría una representación resumida.

Las fronteras anunciarían las direcciones de dominio en el enrutamiento interno de los dominios de tránsito. Un router ordinario las trataría como redes IP normales. La innovación se concentraba en quienes añadían y retiraban la cabecera, mientras BGP, IS-IS u OSPF podrían, en la propuesta, calcular los caminos.

Que el router intermedio no necesitara software nuevo no significa que no participara en una realidad nueva. Seguía una dirección cuyo significado especial desconocía. La compatibilidad se conseguía haciendo que una abstracción novedosa pareciera un objeto conocido.

Eso exigía coherencia entre dos sistemas. El DNS podía anunciar un dominio que la tabla no alcanzaba. La tabla podía alcanzar una dirección exterior asociada al destino equivocado. La llegada de la envoltura al borde no probaba que el datagrama interior llegaría a su servicio. Cada unión requería una evidencia distinta.

Mantener el interior intacto no borraba el estado

La NAT contemporánea hacía visible la alternativa. Traducir implica editar direcciones, ajustar sumas de control y reconocer lugares donde una aplicación transporta direcciones dentro de sus datos. Las salidas múltiples pueden requerir tablas coherentes, y el cifrado impide ciertas modificaciones. ENCAPS evitaba esos trabajos concretos porque el paquete interior no cambiaba.

Sin embargo, la envoltura dependía de una asociación, una asignación de identificadores, una ruta exterior y un punto correcto de retirada. Era posible preservar perfectamente el interior y perderse por fuera. “Sin traducción” describía una propiedad del paquete, no la ausencia de control.

El diseño suponía además que las direcciones IPv4 seguirían siendo globalmente únicas durante bastante tiempo. El texto imaginó combinar dirección de dominio e IP interior para obtener unicidad global cuando la interior dejara de tenerla. Pero entonces reaparecía el dilema: mantener hosts intactos exigiría NAT en la frontera; evitar NAT exigiría que los hosts consultaran y añadieran la cabecera.

La propuesta no eliminó esa decisión. La aplazó de forma explícita. Ésa es una virtud documental: permite ver qué promesa dejaría de cumplirse en cada siguiente paso.

Veinte bytes no contenían todo el coste

La sobrecarga física era fácil de nombrar: veinte bytes de cabecera IP por datagrama y más trabajo en los routers de entrada y salida. El coste institucional y operativo era mayor que esa cifra. El DNS necesitaría una entrada adicional por nombre; las direcciones de dominio requerirían distribución; los agrupamientos tendrían que conservar una forma comprensible; los bordes se convertirían en lugares obligatorios de diagnóstico.

El RFC no detalló la edad de caché, respuestas negativas, autenticación de asociaciones, fallos durante una actualización unilateral, comportamiento de MTU, fragmentación, atribución de ICMP o criterios para retirar el sistema. Tampoco discutió seguridad. Una cabecera elegante no responde por sí sola a ninguna de esas preguntas.

IPv6 fue más tarde el resultado formal de IPng, e IP-dentro-de-IP obtuvo una especificación más completa. Ambos son comparaciones posteriores, no descendientes demostrados de ENCAPS. La historia no necesita inventar genealogías para reconocer una familia de problemas: dónde se guarda el contexto, quién añade la capa, quién puede quitarla y qué sucede cuando una mitad sabe más que la otra.

CIDR pagó la agregación con otra moneda

CIDR también intentó prolongar la vida operativa de Internet, pero cambió la asignación y el anuncio de prefijos. La topología se reflejaba en agregados y máscaras. Los costes incluían política de asignación, capacidades de protocolo, dependencia del proveedor y presión de renumeración.

ENCAPS no resumía las mismas direcciones de la misma manera. Añadía una segunda dirección para el trayecto entre dominios. El paquete viejo se mantenía debajo, mientras el borde y el DNS traducían contexto, no bytes interiores.

Por eso no basta decir que ambos “reducían rutas”. La pregunta arquitectónica es quién absorbía el cambio. CIDR distribuía parte de él entre asignación y anuncios. ENCAPS lo concentraba en una nueva cartografía de dominios y en dos transformaciones de frontera.

Un símbolo, una configuración y un resultado

La primacía del código ejecutado impone una escalera de evidencia. El RFC prueba que una propuesta existió. Un registro DNS probaría que alguien publicó una asociación. Una configuración de borde probaría preparación. Una captura exterior probaría que se emitió una envoltura. Para demostrar el resultado faltarían la llegada al borde correcto, la retirada de la cabecera, el reenvío interior y la recepción de la aplicación.

La especificación mínima y la decisión futura localizada ofrecen una prueba adicional. Limitar inicialmente el cambio a participantes de borde puede proteger la autonomía del resto. Pero esa frontera sólo es local si existe rechazo, ruta alternativa y retirada. Un mapeo que todos deben obedecer para seguir siendo “válidos” ya no es una ayuda de transición.

Las capas de realidad completan la disciplina: dirección propuesta, registro publicado, caché cargada, cabecera construida, ruta recorrida y servicio obtenido son hechos diferentes. El error comienza cuando una capa se usa como certificado de la siguiente.

RFC 1955 no ganó. Precisamente por eso conserva una lección limpia. Contar máquinas sin cambios es sólo la mitad de una migración. La otra mitad consiste en localizar todo el estado que esas máquinas dejaron de llevar.

Fuentes y límites

La identidad y el estatus están en el registro de RFC 1955, y el mecanismo en RFC 1955. RFC 1380 documenta el problema ROAD, y RFC 1550 el proceso de documentos IPng. La estrategia distinta de CIDR procede de RFC 1519, y el contraste con la traducción de RFC 1631. Sin afirmar descendencia, se comparan la primera especificación de IPv6 e IP dentro de IP. El marco analítico se apoya en Running-Code Primacy, Minimum Initial Specification y Reality Layers.

Estas fuentes sostienen la propuesta escrita y comparaciones acotadas. No demuestran aceptación por IPng, estandarización, implementación, despliegue, adopción, rendimiento, interoperabilidad, seguridad, un operador, una captura real, un producto actual ni una genealogía causal.