Summary

  • Antes de poner otra red en marcha, una organización necesitaba direcciones y una ruta que las demás redes pudieran seguir; el ejemplo de RIPE de 1992 muestra por qué importaba agruparlas.
  • En 1993, 83 registros locales asignaron 16.871 números de red; 157.004 actualizaciones de la base de datos medían otro trabajo. Toda red que se conectaba a Internet necesitaba un rango de direcciones; el tráfico también necesitaba indicaciones para llegar a ella. En 1992, Europa afrontaba una pregunta de ingeniería detrás de esas dos ideas sencillas: ¿cómo podían crecer las redes sin que las rutas dejaran de ser manejables para los equipos que transportaban el tráfico? El informe de RIPE explica el problema con una organización hipotética que necesita ocho números de clase C. Si son consecutivos, una sola ruta puede describirlos; si están dispersos, hacen falta más entradas de ruta. Pensemos en un destino y las indicaciones para llegar: agrupar destinos cercanos permite que los routers sigan menos instrucciones separadas. El informe documenta esa decisión de diseño, no un fallo ni una congestión medidos. Muestra por qué la forma en que un proveedor asignaba direcciones importaba más allá de la organización solicitante.

Las cifras de 1993 cuentan dos tareas diferentes. Los registros locales asignaron 16.871 números de red. Por separado, el NCC procesó 157.004 actualizaciones de la base de datos. Una asignación concedía espacio de direcciones; una actualización modificaba un registro sobre una red, una ruta, un dominio DNS o un contacto, que los operadores podían consultar para coordinar las redes. Son trabajos distintos, y el informe anual no dice cuántas actualizaciones correspondían a una asignación. Por tanto, el mayor total de actualizaciones no puede leerse como el número de redes u organizaciones que recibieron direcciones.

Dos tareas, un sistema

El informe describe al NCC como registro regional. Delegaba bloques de direcciones en los registros locales, les daba apoyo y buscaba que las asignaciones fueran justas y regulares. Los registros locales, operados por proveedores de Internet, asignaban espacio de direcciones en su propio contexto de servicio. Para solicitudes grandes o cuando no había un registro local adecuado, el NCC atendía la petición directamente. El diseño no era una oficina única que asignaba cada número ni un conjunto de libros locales desconectados: vinculaba la asignación local con una capa central de suministro y coordinación.

Un informe trimestral anterior explica el recorrido de una solicitud. En 1992, el NCC entregaba números a proveedores y centros de información de red, que luego los reasignaban a organizaciones. Por lo general, los solicitantes individuales debían acudir a su proveedor; el NCC podía actuar directamente en casos excepcionales. El RFC 1366 expuso la razón general: los registros regionales podían atender mejor a comunidades con distintas geografías e idiomas, mientras el Internet Registry seguía siendo el registro raíz y predeterminado donde no existía una autoridad delegada. El RFC 1466 actualizó ese diseño en 1993.

El registro era más amplio que la cola de asignaciones

El mismo informe dice que la base de gestión de red de RIPE contenía datos sobre redes IP, dominios DNS, políticas de enrutamiento y contactos pertinentes. Sus entradas crecían más rápido desde que el sistema regional de registros entró plenamente en funcionamiento, en septiembre de 1992. En 1993, el NCC rediseñó y volvió a implementar el proceso de actualización de la base: casi todas las actualizaciones pasaron a ser totalmente automáticas. Durante el año se procesaron 157.004 actualizaciones.

Esa cifra no equivale a asignaciones de direcciones. El informe no define una actualización como un objeto, una persona, una solicitud o una decisión automática. Por eso deben separarse los 16.871 números de red asignados de las 157.004 actualizaciones de la base. La base abarcaba más que la asignación de recursos, y automatizar sus cambios no indica si una persona evaluó una solicitud. El informe ofrece volumen, no tasas de error, costes laborales ni carga de revisión.

Por qué importaba la capa local

El sistema situó la asignación cerca de los proveedores que atendían a las redes, pero mantuvo en el NCC la delegación de bloques, el apoyo, los casos excepcionales y la coordinación. Esa estructura permitía atender más solicitudes sin exigir que una única oficina decidiera cada asignación. Los proveedores formaban parte del mecanismo de registro, no eran solo usuarios de un servicio central.

El informe presenta el modelo como un medio para promover la equidad y la regularidad, pero esa es la descripción del propio NCC. No prueba un trato igual entre los 83 registros, cuántas solicitudes se rechazaron ni si todos siguieron los mismos procedimientos. Tampoco permite saber cuántos europeos estaban conectados. Documenta una forma de operar y su carga, no la adopción de Internet.

La lección histórica es más concreta que afirmar que los registros eran «solo una base de datos». El expediente público dependía de una distribución de autoridad y servicio: los proveedores asignaban localmente, el NCC delegaba y coordinaba, y una base conservaba varias clases de información operativa. En 1993, el mantenimiento de ese registro se automatizaba a gran escala, pero la asignación aún dependía de personas e instituciones que decidían dónde debía tramitarse cada solicitud.

Fuentes: RIPE NCC Annual Report 1993 (RIPE-113); RIPE NCC Quarterly Report, Issue 1, June 1992 (RIPE-062); RFC 1366; RFC 1466.