Resumen

  • RFC 1380 separó medidas operativas inmediatas, CIDR a corto plazo, una respuesta intermedia al agotamiento y la investigación de largo plazo. Las cuatro debían comenzar ya, no una después de otra.
  • CIDR compraba tiempo dentro del direccionamiento existente, pero exigía política, protocolo, implementación y despliegue. El memo advirtió que esa tarea podía quitar recursos a la solución duradera.
  • Una recomendación, una métrica más lenta, un plan de transición, una arquitectura elegida y un resultado operativo son registros distintos y tienen autoridades distintas.

Tres presiones compartían crecimiento, no plazo

RFC 1380 distinguió la escasez de números de red de clase B, la explosión de las tablas y el eventual agotamiento del espacio IP de 32 bits. Asignar varias clases C podía conservar una clase B y a la vez añadir rutas. Un router más potente ampliaba memoria sin cambiar la estructura que hacía crecer el estado. Un espacio mayor, sin agregación, repetía la carga a otra escala.

También había dos clases de límite de encaminamiento. Memoria, proceso y ancho de banda afectaban a la máquina. Configurar políticas y vigilar que el tráfico siguiera la intención afectaba a las personas. El crecimiento aproximadamente anual de las asignaciones y de la base NSFNET de Merit era evidencia fechada de presión en superficies concretas. No era un censo de cada router ni garantía de una proyección.

ROAD llevaba preguntas hacia decisiones posteriores

ROAD fue un grupo especial de una sola misión, no un grupo de trabajo permanente. Se reunió después de Santa Fe, deliberó en persona y por correo, presentó en San Diego y dejó tareas para BOF, plenarios abiertos y grupos ordinarios.

Su forma acotaba su autoridad. Podía ordenar problemas y recomendar trabajos; no poseía por ello cada asignación, estándar, implementación o migración local posterior. RFC 1380 es Informational y se define como informe preliminar de deliberaciones del IESG. Documenta un proceso, no una norma ni una bitácora de ejecución.

La recomendación de CIDR era suficientemente firme para una necesidad cercana. No existió entonces una elección final de arquitectura con direcciones mayores. Faltaban pruebas sobre transición, infraestructura, control del cambio y experiencia de implementación. La urgencia no rellenó esos huecos.

Las fases tenían nombres sucesivos y comienzos simultáneos

Un diseño único no podía resolver tablas, agotamiento y funciones avanzadas, ser elegido, implementado y desplegado antes del límite más cercano. Cambiar la capa de Internet implicaba además una base instalada extensa.

Por eso el IESG habló de fases inmediata, corta, media y larga. RFC 1380 añadió la frase decisiva: todas debían comenzar inmediatamente; no podían ejecutarse consecutivamente.

No se trataba de enviar a toda la organización al incendio más próximo. Cada horizonte necesitaba propietario y fecha de arranque. Si el trabajo duradero espera a que termine el provisional, el puente reúne usuarios, herramientas, presupuestos y dependencias. Cuando llega el turno del futuro, el puente ya es otra base instalada.

Lo inmediato frenaba; no cerraba el problema

La lista inmediata incluía asignación conservadora, coordinación con la agregación, recuperación de clases B sin usar, routers más capaces y diseño topológico. No esperaba un protocolo nuevo. El documento afirmó que ninguna medida resolvía el problema: sólo podía retrasarlo.

Cada resultado conserva por eso un alcance pequeño. Una regla nueva prueba un cambio de política. Un número recuperado prueba una devolución. Un equipo reemplazado prueba capacidad local. Una tabla menor prueba alivio en ese punto. Ninguno demuestra por sí solo el final del agotamiento, de la carga operativa o del riesgo de migración.

Además, los costes cambian de titular. El solicitante aporta más evidencia, el registro juzga más, el operador paga hardware. Simplificar topología puede reducir caminos alternativos. No tocar software de host no vuelve neutral una política.

CIDR era una coordinación, no un interruptor

RFC 1338 describió supernetting como puente de corto plazo para contener las dos primeras presiones mientras maduraba una solución duradera. Su horizonte de tres años era una hipótesis, no una promesa.

El beneficio exigía asignaciones agregables, protocolos que transportaran pares red-máscara, routers actualizados y fronteras viables con dominios antiguos e IGP. Multihoming y cambio de proveedor mantenían rutas específicas. Aplicar el plan de asignación antes del encaminamiento classless podía acelerar temporalmente la tabla.

RFC 1380 repartió por tanto el programa entre plan operativo de direcciones, extensiones de BGP, posible trabajo IDRP y preparación del despliegue. CIDR reducía presión en el esquema existente y compraba tiempo para el problema mayor. No era gratis ni pertenecía a un único actor.

RFC 1519 revisó después la especificación y conservó ese carácter de puente. Una revisión documental no prueba adopción, cumplimiento, topología ni resultado.

El puente podía gastar el destino

RFC 1380 hizo explícitas dos deudas. La transición de la capa Internet sería traumática para vendedores, operadores y usuarios; el corto y medio plazo debían reducir ese trauma o preservar una salida suave. Una mejora local podía ser una pérdida estratégica si encarecía abandonar el puente.

La segunda deuda era de oportunidad. Desarrollar y desplegar lo provisional desviaba recursos de otros proyectos, incluida la respuesta de largo plazo. Ingenieros, laboratorios, atención operativa y ventanas de cambio no pueden gastarse dos veces.

El tiempo ganado debe compararse con la capacidad consumida. Si una medida entrega dieciocho meses de margen y ocupa durante dos años al equipo de migración, la métrica local y el programa cuentan historias opuestas. El RFC no ofrece esa medición posterior; exige que el desvío se considere antes de elegir.

Una arquitectura mayor necesitaba otro expediente

El IESG no seleccionó una propuesta cuando sus efectos de transición seguían incompletos. RFC 1380 pidió estudiar infraestructura, protocolos actuales, nuevos mecanismos de rutas, asignación, rendimiento, propiedad del control de cambios, gestión, seguridad y formación. Su apéndice exigía respuestas punto por punto y experiencia implementada.

Convocatoria, Internet-Draft, revisión pública, exposición, recomendación del IESG y decisión del IAB eran actos distintos. Un calendario puede asignar autor y fecha; no certifica el mérito antes de recibir la evidencia.

IPv6 llegó mediante una decisión separada

RFC 1719 registró después que el BOF IPDecide había mostrado falta de dirección firme. Encargó al IESG una recomendación IPng mediante un proceso anunciado y abierto, y vinculó la urgencia con tasas de asignación, efectos de política, ahorro CIDR y tiempo de desarrollo, salida al campo y migración.

En 1995, RFC 1752 documentó otra acción: recomendó SIPP revisado como base de IPng, separó protocolo, autoconfiguración, transición y convivencia, y señaló que el número 6 se llamaría IPv6.

Esa historia no convierte RFC 1380 en una elección secreta de IPv6. Demuestra que hicieron falta otro paquete de pruebas, otro proceso y otra recomendación responsable. Elegir tampoco prueba migración universal, retirada de IPv4 ni éxito operativo.

Fuentes y límites

Este artículo usa los textos oficiales de RFC 1338, 1380, 1519, 1719 y 1752. Prueban diagnósticos, recomendaciones, criterios y sucesión documental. No prueban la situación de una red actual, la exactitud de cada pronóstico, la ejecución puntual de cada hito, un producto concreto, una acción local autorizada o un resultado medido.

La conclusión válida es menor: en 1992 el alivio urgente y el reemplazo duradero ya eran trabajos distintos que debían empezar juntos. Una medida provisional requería un registro del beneficio, otro del recurso consumido y otro de la salida. Sin los tres, se contaba el tiempo comprado y se perdía de vista el futuro gastado.