La era de las direcciones classful y el nacimiento de la escasez administrativa

Resumen

• Una red que requería 300 direcciones de host ordinarias excedía la capacidad práctica de una red de Clase C de 254 en 46 direcciones. La siguiente clase nativa ofrecía 65.534 direcciones de host ordinarias, mientras que dos Clases C ofrecían 508, con el posible coste de una ruta adicional y más coordinación. La geometría classful, por tanto, hacía de la asignación una elección entre costes dispares en lugar de una simple lectura de la demanda de hosts.
• Tres instantáneas contemporáneas muestran que las redes de Clase C dominaban el recuento de unidades de números de red asignados, mientras que las asignaciones de Clase A dominaban la capacidad de direcciones representada. En enero de 1983, 31 asignaciones de Clase A representaban el 99,648 por ciento de los valores de dirección numéricos cubiertos por los totales publicados; 1.042 Clases C representaban el 0,051 por ciento.
• El material conservado no proporciona una muestra emparejada de solicitudes, rechazos y decisiones tempranas. No puede establecer un efecto general de ventaja del primero en moverse, un acceso desigual de los solicitantes o los criterios utilizados en una decisión de clase temprana particular. Apoya una conclusión más limitada: las asignaciones duraderas realizadas antes de que los criterios posteriores se hicieran explícitos podían crear una opción ventajosa dependiente de la trayectoria plausible.
• La escasez de espacio de direcciones, el crecimiento del estado de enrutamiento, el problema de dimensionamiento de un solicitante individual y la atención administrativa limitada eran restricciones separadas. Aparecieron en momentos diferentes y a menudo apuntaban hacia elecciones de asignación diferentes.
• Múltiples Clases C, subnetting, bloques contiguos y delegación regional eran alternativas viables de la época, pero cada una imponía costes de enrutamiento, hardware, coordinación o administrativos. Un contrafactual justo no puede asumir que el enrutamiento sin clases estuviera disponible durante toda la década de 1980.

Un planificador de red que esperaba 300 hosts ordinarios se encontraba con una discontinuidad precisa. Una red de Clase C contenía 256 valores posibles en su campo de dirección local de ocho bits. Según las restricciones posteriormente aclaradas sobre los valores de host todo-ceros y todo-unos, suministraba 254 direcciones de host ordinarias. Por tanto, el requisito era 46 direcciones más allá de una Clase C, no dos. El número dos describe la diferencia entre 256 valores numéricos y 254 direcciones de host ordinarias; no describe el déficit frente a un plan de 300 hosts.

Dos redes de Clase C podían cubrir el requisito inmediato con 508 direcciones de host ordinarias. Sin embargo, seguían siendo dos redes classful, que potencialmente requerían dos entradas de enrutamiento visibles externamente, dos registros y coordinación local adicional. La siguiente clase nativa, Clase B, suministraba 65.536 valores numéricos de dirección local, o 65.534 direcciones de host ordinarias. Eso era aproximadamente 258,008 veces la capacidad práctica de hosts de una Clase C y más de 218 veces el requisito declarado de 300 hosts.

El protocolo no contenía una clase intermedia. No decidía si la conservación de los valores de dirección era más importante que la conservación del estado de enrutamiento, si el hardware de la organización podía subnetear de manera segura, si dos redes más pequeñas podían coordinarse sin interrupción, o cuánto crecimiento debía acreditarse. Esas cuestiones debían resolverse fuera del patrón de bits.

Este es el punto en el que la granularidad técnica se convirtió en escasez administrativa. La escasez no comenzó solo cuando el pool restante se acercaba al agotamiento. También aparecía cada vez que la necesidad de un solicitante caía en el amplio hueco entre las unidades disponibles y un administrador debía determinar qué coste aceptaría el sistema de asignación.

La geometría creó una frontera de decisión

RFC 791, publicada en septiembre de 1981, definió una dirección de Internet como cuatro octetos, o 32 bits. Sus bits de orden superior seleccionaban uno de los tres formatos de dirección ordinarios y, por tanto, fijaban la división entre el número de red y la dirección local.

La notación de barra se incluye solo como una traducción moderna de los límites fijos de clase. No debe leerse retrospectivamente como evidencia de que un administrador en 1981 podía asignar una longitud de prefijo arbitraria. Una Clase B no era un punto en un menú continuo. Sus bits iniciales indicaban a las implementaciones classful que tratasen los dos primeros octetos como la porción de red. Una Clase C fijaba el límite después de tres octetos. El sistema no ofrecía de forma nativa una asignación enrutable globalmente a medio camino entre ellas.

La relación de capacidad numérica de una clase a la siguiente era exactamente 256. Una Clase A contenía (2^{24}) valores de dirección local, una Clase B (2^{16}) y una Clase C (2^8). Después de excluir los valores de host todo-ceros y todo-unos ordinarios, las relaciones prácticas eran ligeramente mayores:

• (16.777.214 / 65.534 = 256,007782) capacidades de Clase B por Clase A.
• (65.534 / 254 = 258,007874) capacidades de Clase C por Clase B.

Las exclusiones necesitan ser datadas. RFC 791 estableció la geometría de clases pero no publicó una tabla de hosts utilizables moderna.RFC 950, publicada en 1985, explicó los significados especiales de los campos cero y todo-unos en el contexto del subnetting y las difusiones.RFC 1122estableció en 1989 que los campos de host, red y subred no podían tomar valores todo-ceros o todo-unos excepto en casos especiales definidos.

Para comparar asignaciones, los valores numéricos totales son la medida menos dependiente de supuestos: (2^{24}), (2^{16}) o (2^8) por red. Para reconstruir el problema de capacidad de hosts ordinarios de un solicitante bajo las reglas posteriormente aclaradas, las cifras familiares de menos dos son apropiadas. Mezclar esas dos medidas produce afirmaciones engañosas, como demuestra el ejemplo de los 300 hosts.

Los patrones de bits de orden superior también dividían el espacio completo de 32 bits de manera desigual. Las direcciones que comenzaban con0ocupaban la mitad de todas las cadenas de bits. El patrón10ocupaba un cuarto. El patrón110ocupaba un octavo. Los patrones de orden superior restantes estaban reservados o desarrollados para otros propósitos, incluidos multicast y experimentación. Así, un pequeño recuento de números de red de Clase A controlaba una parte enorme del espacio de direcciones numérico, mientras que el inventario mucho mayor de números de red de Clase C ocupaba una fracción más pequeña.

Esta distinción entre unidades de número de red y capacidad representada es fundamental. Un registro podía contener miles de entradas de Clase C y solo unas pocas docenas de entradas de Clase A, haciendo que la Clase C pareciera dominante como carga de trabajo. El mismo registro, medido por valores de dirección numéricos, podía estar abrumadoramente concentrado en la Clase A. Ninguno de los dos denominadores es inherentemente incorrecto. Responden a preguntas diferentes.

El recuento de números de red se aproxima al número de unidades classful que debían ser registradas y, cuando eran visibles externamente, enrutadas. La capacidad representada mide cuántos valores de dirección había dentro de las asignaciones listadas. Ninguno es un recuento de solicitantes. Ninguno mide hosts activos, utilización, visibilidad de enrutamiento, propiedad organizativa o valor económico.

La arquitectura classful, por tanto, producía dos formas de imprecisión a la vez. Proporcionaba muy pocas capacidades intermedias para los solicitantes, y hacía que la distribución aparente dependiera en gran medida de la unidad de análisis del observador. El juicio administrativo entraba en la primera frontera. El juicio histórico puede errar en la segunda.

El enrutamiento hizo atractiva operativamente la unidad más grande

El hueco entre la Clase B y la Clase C habría sido menos consecuente si los routers hubieran podido agregar redes adyacentes arbitrarias sin cambiar su interpretación. Durante gran parte del periodo, no podían.

La arquitectura original trataba Internet como una jerarquía de redes classful. Un gateway podía enrutar basándose en la porción de red mientras dejaba al destinatario interpretar el campo de dirección local. Esa disposición era económica cuando un número de red se correspondía razonablemente bien con una red física o una organización. Se volvió más difícil de sostener a medida que las universidades, empresas y redes públicas acumulaban edificios, redes de área local, conexiones punto a punto y gateways internos.

RFC 950 describió tres opciones generales para una organización con múltiples LAN. Podía obtener un número de red de Internet separado para cada cable. Podía hacer que varias LAN parecieran una red transparente. O podía dividir una única red asignada en subredes.

La primera opción preservaba implementaciones de host simples pero exportaba complejidad local al sistema de enrutamiento global. RFC 950 advertía que propagar cada red local globalmente causaría una explosión en el tamaño de la tabla de enrutamiento, incluso en gateways con poco espacio para información de enrutamiento. El bridging transparente evitaba números de red de Internet adicionales pero traía sus propias limitaciones de escala y dominio de fallos. El subnetting permitía que una red classful externa contuviera varias redes internas, conservando entradas de enrutamiento global a costa de implementaciones locales más capaces.

La aritmética de subredes ilustra por qué la Clase B se volvió atractiva para un campus en crecimiento. Si se usaban seis bits de su campo local de 16 bits para subredes, la geometría bruta producía 64 patrones de subred y 1.024 patrones de host dentro de cada subred. Bajo la convención de la época que excluía los patrones de subred todo-ceros y todo-unos, quedaban 62 subredes ordinarias. Aplicando las exclusiones de host ordinarias quedaban 1.022 valores de host por subred. El producto era:

[62 \times 1,022 = 63,364]

Esa organización podía operar docenas de redes internas detrás de un único número de Clase B externo. El arreglo usaba muchos más valores de dirección de los que un campus pequeño requería inicialmente, pero economizaba en números de red visibles externamente y dejaba espacio para el crecimiento interno.

El subnetting no era gratuito. Los hosts y gateways necesitaban entender máscaras. Las asignaciones existentes dentro del campo local podían entrar en conflicto con un límite de subred recién elegido. El software debía decidir si un destino era local o requería un gateway usando más que el límite de clase fijo.

La guía operativa de 1989RFC 1118describió el problema de compatibilidad directamente. Mucho software disponible, notablemente 4.2BSD, no podía manejar direcciones subnetteadas sin software adicional, mientras que 4.3BSD soportaba subnetting tal como se lanzó. Otros sistemas variaban. Algunos podían funcionar como hojas pero no como gateways dentro de una parte subnetteada de la red.

RFC 1118 también dio al coste de enrutamiento una escala concreta. Dijo que algunos nodos importantes podían almacenar e intercambiar información para solo unas 700 redes. Aconsejó a un campus no anunciar más de dos números de red discretos. Se decía a un sitio que esperara exceder ese límite que considerara el subnetting.

El dilema del asignador, por tanto, no era simplemente “bloque grande versus bloque pequeño”. Era una elección entre recursos consumidos en diferentes lugares:

• Una Clase B consumía una gran parte del pool de direcciones finito pero podía conservar entradas de enrutamiento externas.
• Varias Clases C conservaban valores de dirección numéricos pero podían añadir rutas y trabajo de coordinación local.
• El subnetting conservaba estado externo pero requería equipos compatibles y competencia operativa.
• Posponer la decisión no conservaba ni el esfuerzo de renumeración futuro ni la atención administrativa si el solicitante superaba pronto la asignación inicial.

El crecimiento del estado de enrutamiento hizo la compensación cada vez más urgente.RFC 1338reprodujo una serie de Merit que mostraba 173 rutas anunciadas en julio de 1988, 603 en julio de 1989 y 4.775 en febrero de 1992. La comparación completa de julio de 1988 a febrero de 1992 era:

[4.775 / 173 = 27,601]

Eso fue un aumento de 27,601 veces en 43 meses. La comparación más corta de julio de 1989 a febrero de 1992 era:

[4.775 / 603 = 7,919]

Eso fue un aumento de 7,919 veces en 31 meses. Son comparaciones diferentes y no deben combinarse.

RFC 1338 argumentaba que asignar de cuatro a dieciséis Clases C en lugar de una Clase B podía ralentizar el agotamiento de Clase B pero empeorar el crecimiento de la tabla de enrutamiento a menos que los protocolos de enrutamiento entre dominios pudieran representar agregados arbitrarios de red y máscara. El remedio propuesto, por tanto, dependía de más que una nueva regla de registro. Los routers y protocolos debían transportar información que no encajaba en los viejos límites de clase.

El solicitante de 300 hosts ahora parece menos un ejercicio aritmético trivial. Dos Clases C ofrecían capacidad inmediata suficiente, pero podían requerir dos rutas. Una Clase B reducía la representación externa a una red mientras reservaba 65.536 valores numéricos. La arquitectura creaba la discontinuidad. El enrutamiento y el equipo determinaban los costes relativos. El sistema administrativo debía seleccionar una opción imperfecta.

La interfaz temprana de decisión permanece incompleta

RFC 791 explicaba lo que significaba una clase. No especificaba quién debía recibir una. Esa decisión se movió a través de un conjunto cambiante de instituciones y procedimientos.

En septiembre de 1981,RFC 790publicó los números de red asignados y dirigió las solicitudes de asignación a Jon Postel en el Instituto de Ciencias de la Información de la Universidad del Sur de California. El registro mostraba números asignados, reservados y no asignados, pero no publicaba una prueba general completa para elegir entre Clase A, B y C.

Para enero de 1983,RFC 820documentaba un entorno de políticas más elaborado. Etiquetó las asignaciones como de investigación y desarrollo, defensa o comercial. Su apéndice resumía las recomendaciones acordadas entre la oficina del programa de la Red de Datos de Defensa y DARPA en septiembre de 1982. Para la comunidad de investigación, las recomendaciones vinculaban la concesión de identificadores de red a la evidencia de que el solicitante estaba adquiriendo software de gateway estándar o implementando un gateway que cumpliera los requisitos del Protocolo de Gateway Externo.

Ese criterio concernía a la elegibilidad y la preparación operativa. No suministraba una regla de dimensionamiento completa. Podía distinguir a un solicitante preparado para participar en el entorno de red relevante de uno sin capacidad de gateway adecuada, pero no le decía a un administrador si una organización cualificada que planeaba 500 hosts debía recibir dos Clases C o una Clase B.

RFC 820 también registró un desfase de implementación entre la división de responsabilidades prevista y la operación real. La división propuesta no se había implementado completamente, y Postel seguía siendo el coordinador para las asignaciones de números. Las descripciones formales de roles y el manejo diario aún estaban convergiendo.

El arreglo institucional cambió durante la década. LaGuía de los Registros SRI ARC/NICdel Computer History Museum fecha la transferencia de la administración de Números Asignados y la asignación global de direcciones IP de USC-ISI al contrato SRI NIC en 1987. El instrumento de descripción identifica correspondencia y material de denominación y direccionamiento que podría contener registros de solicitudes, pero no revela por sí mismo el razonamiento detrás de ninguna decisión de clase individual.

RFC 1118 suministró una descripción pública del procedimiento orientado al solicitante en 1989. Se instruía a una red conectada prospectiva para enviar un mensaje a[email protected], solicitar la plantilla de dirección conectada, completarla y devolverla. La dirección asignada se enviaría entonces de vuelta por correo electrónico o postal. La guía añadía que quedaban pocos números de Clase A y que, en términos prácticos, la mayoría de los solicitantes debían elegir entre Clase B y Clase C.

Esto establece que había un formulario, un canal de retorno y un resultado. No reproduce los formularios completados ni demuestra qué campos determinaban la clase seleccionada en un caso específico. Una descripción procedimental no es un conjunto de datos de solicitud-decisión.

La confirmación conservada enviada a la Universidad de Bristol es igualmente limitada. La universidad reproduce un mensaje fechado el 8 de marzo de 1991 asignando137.222.0.0, una red de Clase B, aBRISTOL-NET. Identifica la clase, número, contacto técnico y fecha. También aconseja al destinatario sobre el registro de tablas de host, direccionamiento de difusión y resolución de direcciones.

La confirmación no contiene la solicitud presentada por Bristol, la previsión de hosts, el plan de subredes, las alternativas consideradas, las preguntas hechas por el hostmaster o las razones para seleccionar Clase B. Prueba un resultado, no la regla de decisión del administrador. Es una respuesta sin la solicitud y deliberación correspondientes.

La evidencia directa reunida aquí, por tanto, no reconstruye un par completo de solicitud-respuesta o solicitud-decisión temprana. Las afirmaciones sobre lo que un administrador temprano realmente veía deben permanecer como hipótesis. Un administrador plausible podría haber considerado los hosts esperados, la topología, los gateways, el software y la conectividad porque esos asuntos eran operativamente relevantes y aparecían en la guía pública. El material conservado no demuestra que todos ellos fueran presentados o ponderados en una decisión temprana particular.

La distinción importa porque las tablas de asignación completadas son evidencia especialmente tentadora. Muestran lo que se registró después de la aprobación. No muestran la clase solicitada, el tamaño ofrecido primero, la previsión de un solicitante, un rechazo, una reducción, un retraso o una necesidad no presentada. Inferir la interfaz de decisión de la tabla completada convertiría los resultados en motivos.

En agosto de 1990,RFC 1174describió los roles institucionales de manera más formal. La función IANA en USC-ISI retenía la autoridad central para asignar y distribuir identificadores numéricos y la autoridad discrecional para delegar porciones de esa responsabilidad. La responsabilidad sobre los identificadores de red y sistema autónomo se había depositado en el Internet Registry operado por SRI International en el DDN-NIC. El documento recomendaba retener las funciones centrales de IANA e Internet Registry mientras se delegaban bloques a organizaciones aprobadas internacionalmente.

Esos roles no deben colapsarse. La función IANA, el Internet Registry, el servicio NIC y el Internet Activities Board ocupaban posiciones relacionadas pero distintas. El IAB emitía recomendaciones. La función IANA poseía la autoridad de asignación y delegación. El Internet Registry reunía y mantenía registros y procesaba las asignaciones de números. El solicitante normalmente se encontraba con el sistema a través de un hostmaster y un número devuelto.

RFC 1174 prueba que la discreción y la delegación eran conceptos institucionales reconocidos para 1990. No prueba cómo se ejercía la discreción en un caso particular de 1983 o 1991.

Medir la distribución sin inventar solicitantes

Se puede construir una medición reproducible a partir de instantáneas publicadas contemporáneas, siempre que su unidad de observación permanezca estrecha.

La unidad utilizada aquí es una unidad de número de red classful tal como la cuenta la fuente citada. No es una organización, solicitante, prefijo enrutado, host, titular actual, transferencia o transacción económica. Si una fuente asocia un rango que contiene 1.024 redes de Clase C con un nombre, la medición cuenta 1.024 unidades classful. No pretende que el rango represente 1.024 beneficiarios.

Tres instantáneas publicadas proporcionan puntos útiles de comparación:

1. Los totales de enero de 1983 para números de red de Clase A, B y C asignados en RFC 820.
2. RFC 1166, publicada en julio de 1990, y sus totales para redes asignadas para Internet y usos independientes.
3. RFC 1466, publicada en mayo de 1993, y su tabla titulada “Network Number Statistics (May 1992)”.

Se excluyen los rangos reservados y no asignados, los números de sistema autónomo, el espacio multicast y las clases experimentales. Los valores numéricos representados se calculan multiplicando cada recuento de fuente por (2^{24}), (2^{16}) o (2^8). El cálculo no resta las reservas de host, subred o difusión porque los destinatarios podían estructurar sus campos locales de manera diferente y porque el propósito es medir la capacidad numérica abarcada por cada asignación classful.

Para enero de 1983:

[(31 \times 16.777.216) + (24 \times 65.536) + (1.042 \times 256) = 521.933.312]

Para julio de 1990:

[(34 \times 16.777.216) + (2.533 \times 65.536) + (16.214 \times 256) = 740.578.816]

Para las estadísticas de mayo de 1992:

[(49 \times 16.777.216) + (7.354 \times 65.536) + (44.014 \times 256) = 1.315.302.912]

Las redes de Clase C dominaron el recuento de unidades de número de red en las tres instantáneas seleccionadas. No dominaron la capacidad representada. En enero de 1983, 31 asignaciones de Clase A abarcaban el 99,648% de los valores de dirección numéricos en los totales publicados. Las 1.042 unidades de Clase C abarcaban el 0,051%.

La primera fila contiene una concentración importante. RFC 820 asoció el rango de192.1.xxxa192.4.xxxcon “BBN local networks”. Cada valor completo del segundo octeto cubría 256 números de red de Clase C. Por tanto, cuatro de esos valores cubrían:

[4 \times 256 = 1.024]

Esas 1.024 unidades representaban el:

[1.024 / 1.042 = 98,272553%]

del recuento de Clase C en el total de enero de 1983. Su capacidad numérica combinada era:

[1.024 \times 256 = 262.144]

Eso era igual a cuatro redes de Clase B en capacidad numérica bruta:

[4 \times 65.536 = 262.144]

El rango muestra por qué los recuentos de unidades de red no pueden leerse como recuentos de beneficiarios. También muestra que la clase seleccionada no era una función mecánica de la capacidad numérica agregada. Una organización prominente podía aparecer como una gran colección de pequeñas unidades classful en lugar de como un único bloque grueso.

La tabla publicada no dice por qué. No muestra si las redes BBN estaban enrutadas por separado, se usaban para pruebas, estaban reservadas para diferentes entornos locales o se organizaban bajo algún otro plan técnico. Sustituir cuatro Clases B en un contrafactual preserva la capacidad bruta pero no necesariamente la topología, experimentación, comportamiento de enrutamiento o la estructura administrativa prevista. El rango es, por tanto, evidencia contra una lectura simplista de una-organización/una-clase, no evidencia del razonamiento del administrador original.

RFC 820 también contiene aparentes irregularidades de publicación. Varias líneas de Clase C de defensa repiten un valor numérico mientras los totales cuentan unidades distintas. Números temporales, redes renombradas y entradas de transición aparecen en otros lugares. Por consiguiente, los totales propios de la fuente son más seguros para la medición agregada que un recuento ingenuo de líneas visibles. Siguen dependiendo de las definiciones de la fuente.

La instantánea de 1990 introduce un denominador diferente. RFC 1166 informó por separado de 4.210 redes asignadas para ARPA-Internet y DDN-Internet y 18.781 asignadas para Internet y usos independientes. El subconjunto conectado incluía 29 Clases A, 1.209 Clases B y 2.972 Clases C. El total de asignación más amplio contenía 34 Clases A, 2.533 Clases B y 16.214 Clases C.

El total más amplio es apropiado para medir la capacidad classful globalmente única puesta en uso asignado o adjudicado, incluyendo redes independientes. El subconjunto conectado está más cerca de un recuento de redes dentro de los entornos de Internet especificados. Ningún total es un recuento de solicitantes. Ninguno revela cuántas solicitudes fueron denegadas o revisadas.

Las fuentes de 1992 advierten contra forzar las instantáneas en una serie continua falsamente precisa. RFC 1338 informó que un análisis del archivonetwork-contacts.txtdel DDN-NIC encontró 46 números de Clase A asignados y 5.467 de Clase B asignados el 25 de febrero de 1992. RFC 1466 reprodujo más tarde totales de mayo de 1992 de 49 y 7.354. Los documentos también usaban diferentes denominadores del pool de Clase B: 16.256 en RFC 1338 y 16.383 en RFC 1466.

Sería inseguro interpretar toda la diferencia como un aumento súbito de asignación en tres meses. Los archivos, filtros, tratamiento de rangos reservados o significados de “asignado” pueden haber diferido. Sin los archivos subyacentes fechados y sus reglas de transformación, la discrepancia no puede resolverse solo con los dos totales. Los autores contemporáneos claramente percibían un rápido crecimiento, pero esa percepción no hace que mediciones diferentes sean intercambiables.

Los nombres de los destinatarios no reparan el denominador faltante

Asignar geografía es más difícil que multiplicar recuentos de clase. Los primeros registros no proporcionaban un campo de país estándar junto a cada red. Algunos nombres identificaban explícitamente un lugar o institución. Otros describían un proyecto, sistema experimental, contratista o red transnacional. Una dirección de contacto podía identificar dónde ocurría la administración sin identificar cada país en el que operaba la red.

Las entradas de Clase A de RFC 1166 incluían casos claramente no estadounidenses, entre ellos RSRE en el Reino Unido, CAN-INET en Canadá y JAPAN-A con un contacto de la Universidad de Tokio. Los registros anteriores incluían el University College London y redes transatlánticas de paquetes o satélite. Esto es suficiente para rechazar la afirmación de que las asignaciones de clase grande eran exclusivamente estadounidenses. No es suficiente para producir un porcentaje de país fiable.

Una red de satélite transatlántica se resiste a ser asignada a un solo país. Una corporación puede operar en varias jurisdicciones. Un nombre de proyecto puede sobrevivir a su ubicación institucional original. Los registros posteriores de los registros pueden reflejar fusiones, transferencias, reorganizaciones o contactos cambiados. La geografía actual no puede proyectarse hacia atrás como geografía del destinatario original sin una cadena documentada.

Los nombres también cambian la unidad de observación. Varias entradas pueden pertenecer a una organización; una entrada puede dar soporte a varias organizaciones o sitios operativos. El rango de Clase C de BBN es el ejemplo más claro de muchas unidades de número de red bajo un nombre. El uso posterior de la red 35 por Merit a través de varios sistemas autónomos ilustra el problema inverso: una red classful podía participar en un arreglo de enrutamiento distribuido.

La ausencia de demanda no exitosa es más grave. Los registros publicados muestran predominantemente asignaciones completadas. No revelan la población completa de solicitantes. Las observaciones faltantes pueden incluir:

• solicitudes devueltas para información adicional;
• solicitudes concedidas con una clase más pequeña que la solicitada originalmente;
• solicitudes retrasadas o abandonadas;
• organizaciones dirigidas a un proveedor u otro registro;
• redes que usaban numeración privada o no única;
• organizaciones que no conocían el procedimiento relevante;
• solicitantes disuadidos por requisitos de gateway, conectividad o equipo;
• destinatarios exitosos cuyos formularios originales ya no sobreviven.

Sin este denominador, las instantáneas no pueden medir tasas de aprobación, retrasos, acceso desigual o ventaja del primero en moverse a nivel de solicitante. No pueden mostrar si solicitantes técnicamente similares recibieron clases diferentes. No pueden establecer que la capacidad de ingeniería de una organización hiciera más probable el éxito.

Los datos pueden establecer imprecisión, concentración y la distribución cambiante de unidades classful. Pueden identificar un mecanismo por el cual las asignaciones tempranas duraderas podrían preservar opciones posteriores. No pueden convertir ese mecanismo en un efecto social medido sin solicitudes y resultados emparejados.

Este límite cambia el lenguaje de la conclusión. “Los primeros receptores tenían mejor acceso” requeriría evidencia sobre solicitantes comparables. “Los administradores favorecían a los titulares capaces” requeriría evidencia sobre decisiones y alternativas. La afirmación defendible es condicional: si una organización recibió y desplegó una asignación grande antes de que se publicaran criterios más estrictos, el coste de la renumeración podía permitirle retener un conjunto de opciones que un solicitante posterior podría no recibir en los mismos términos.

Eso es dependencia de la trayectoria plausible. No es un dividendo cuantificado del primero en moverse.

Los criterios públicos emergieron a medida que la presión se acumulaba

La interfaz temprana incompleta no debe confundirse con una ausencia de todo criterio. El registro muestra algunas reglas de elegibilidad tempranas y una guía de asignación mucho más explícita posteriormente.

El criterio de investigación de RFC 820 vinculaba la asignación de números con la preparación del gateway. También recomendaba continuidad cuando una red experimental se volvía operativa: si la renumeración causaba dificultades, la red podía retener su identificador mientras su categoría administrativa cambiaba. Esto era un reconocimiento explícito de que el despliegue creaba costes de cambio. No muestra que los administradores anticiparan un valor de mercado futuro. Muestra que la continuidad ya importaba operativamente.

Para 1990, RFC 1174 usaba directamente lenguaje de escasez. El rápido crecimiento y la internacionalización hacían oportuna una mayor delegación, y los identificadores de Clase A y B se describían como recursos cada vez más escasos que requerían una asignación cuidadosa. El documento unía una preocupación de capacidad con una administrativa. Una población global de solicitantes dependía de funciones aún centradas en instituciones estadounidenses, mientras que el número de redes y registros aumentaba.

La respuesta propuesta era la distribución controlada en lugar del abandono inmediato de la autoridad central. El Internet Registry seguiría siendo el registro principal y el predeterminado donde no existiera autoridad delegada. Las organizaciones aprobadas podían recibir bloques y responsabilidad delegada. Se distribuirían copias de los datos de registro agregados, mientras que las actualizaciones permanecerían centralizadas.

RFC 1366, publicada en octubre de 1992, convirtió la dirección en reglas más específicas. Se esperaba que los registros regionales candidatos fueran reconocidos en sus áreas geográficas, estables, adecuadamente dotados de recursos y comprometidos con las directrices comunes de IANA e Internet Registry. Las funciones centrales retenían la responsabilidad sobre el espacio de Clase B, con los registros regionales ayudando en la evaluación.

Para la Clase B, RFC 1366 establecía dos criterios: un plan de subnetting que documentara más de 32 subredes y más de 4.096 hosts. Permitía consideración caso por caso cuando un bloque de Clases C fuera técnicamente inadecuado. Para la Clase C, proponía bloques contiguos a nivel de bits dimensionados según la necesidad y una proyección de 24 meses.

Los criterios hacían públicos algunos factores mientras dejaban espacio para el juicio. “Más de 32 subredes” dependía de una topología propuesta. “Más de 4.096 hosts” dependía de lo que contara como host y de si el número describía el despliegue actual o un crecimiento creíble. La inadecuación técnica requería explicación en lugar de un cálculo automático.

La fuente canónica de la épocaRIPE-048, publicada el 1 de agosto de 1992, muestra la interfaz europea en desarrollo. Decía que el RIPE NCC manejaba las solicitudes de organizaciones europeas y que los solicitantes normalmente devolverían el material suministrado a través de un proveedor de servicios IP o el RIPE NCC. Conectaba la asignación con las relaciones de proveedor y la conectividad externa prospectiva.

RIPE-048 establecía que los números de Clase A y B eran escasos y requerían justificación en términos del tamaño y estructura de red esperados. Una solicitud de Clase A requería una justificación técnica detallada y una revisión global que podía llevar varios meses. Aconsejaba usar un conjunto razonable de Clases C en lugar de una Clase B cuando la red pudiera ser diseñada de esa manera, señalando explícitamente que esto revertía el consejo anterior motivado por las restricciones de la tabla de enrutamiento.

El documento se refería a una hoja informativa de Clase B de una página separada, pero el texto inspeccionado de RIPE-048 no reproduce esa hoja. Por tanto, sería inapropiado atribuir una lista detallada de campos de hosts proyectados, subredes y utilización al propio RIPE-048. El soporte directo es más limitado: tamaño y estructura esperados, contexto de proveedor o conectividad, idoneidad de Clase C, justificación detallada para Clase A y la posibilidad de una revisión global prolongada.

RFC 1466, publicada en mayo de 1993, proporciona los campos detallados directamente. Se esperaba que un solicitante de Clase B documentara más de 32 subredes y más de 4.096 hosts. El plan de ingeniería debía explicar por qué un bloque de Clases C no era razonable e incluir el número de hosts esperados en 24 meses y el número de hosts por subred dentro de ese periodo. Los planes debían permanecer confidenciales y usarse para juzgar si la solicitud estaba justificada. Un solicitante que no superara la prueba recibiría un bloque de Clase C, mientras que las excepciones seguían siendo posibles.

Para la Clase C, RFC 1466 establecía una escalera de asignación contigua basada en la proyección de 24 meses del suscriptor:

Estos umbrales usaban requisitos de direcciones, no la capacidad práctica de 254 hosts usada en el ejemplo inicial. Esa distinción refleja la propia escalera de asignación del documento y no debe ser “corregida” silenciosamente a una convención diferente.

La política permitía ajustes por topología. Una organización con 600 hosts distribuidos equitativamente en diez Ethernets podía recibir diez Clases C, una por LAN, si respaldaba la desviación con un plan de ingeniería. Los registros también podían solicitar una explicación cuando la falta de subnetting de redes de Clase C consumiera espacio excesivo.

La interfaz de decisión del periodo tardío era, por tanto, más visible que la temprana. Los solicitantes sabían que los totales de hosts, los planes de subredes, un horizonte de 24 meses y la idoneidad de la Clase C importaban. También sabían que las excepciones y el juicio del registro permanecían. El cambio no fue de discreción a no discreción. Fue de criterios públicos escasos hacia una discreción estructurada.

Los casos límite impiden una fábula moral

Las mediciones agregadas pueden respaldar varias historias simplistas si se ignoran sus limitaciones. Los casos nombrados son valiosos porque debilitan esas historias sin pretender revelar motivos no documentados.

El rango de BBN desafía la proposición de que los titulares prominentes recibían invariablemente una clase gruesa. En enero de 1983, “BBN local networks” representaba 1.024 de las 1.042 unidades de Clase C en el total de la fuente. Cuatro Clases B habrían proporcionado la misma capacidad numérica bruta con cuatro unidades classful. Sin embargo, el registro mostraba la clase fina en bloque.

Esto no prueba que los administradores prefirieran la asignación de grano fino para BBN. La razón original está ausente. El rango puede haber respaldado pruebas, redes locales separadas, experimentación o propósitos administrativos internos. Sus miembros pueden no haber aparecido todos como rutas globales independientes. El hallazgo defendible es simplemente que la prominencia institucional no se mapeaba mecánicamente a una asignación de clase grande.

Bristol desafía una afirmación diferente. Una universidad europea recibió una Clase B el 8 de marzo de 1991, después de que el crecimiento del enrutamiento fuera evidente y antes de que se publicaran los criterios detallados de 1992–1993. La confirmación descarta una proposición absoluta de que las clases de legado de tamaño medio estaban cerradas a las universidades no estadounidenses.

No establece un trato igualitario. La solicitud falta, y no hay un grupo emparejado de universidades no exitosas. El caso prueba que tal resultado ocurrió, no con qué frecuencia o por qué.

La red 35 de Merit proporciona un caso límite operativo. RFC 1166 listaba la red 35 entre las asignaciones de Clase A.RFC 1482, publicada en julio de 1993, la mostraba configurada en el backbone T3 de NSFNET de manera que se podían esperar anuncios de enrutamiento de hasta seis sistemas autónomos.

Esa configuración de 1993 no establece la razón de la asignación original. Muestra que un único número de red classful podía desempeñar más tarde un rol operativo similar a la agregación en un entorno enrutado considerable. Una prueba de utilización retrospectiva basada únicamente en el recuento de hosts activos omitiría esa función de enrutamiento.

Estos casos restringen, más que prueban, la tesis. Las asignaciones grandes no eran necesariamente irracionales. Las colecciones de redes pequeñas no estaban confinadas a solicitantes marginales. Las universidades no estadounidenses no estaban categóricamente excluidas de la Clase B. Un número de red grande podía tener un rol de enrutamiento más allá del número de hosts visibles en un momento dado.

La falsación aquí funciona eliminando afirmaciones universales. No suministra los archivos de decisión faltantes. BBN, Bristol y Merit deben ser tratados como casos límite contra explicaciones simplistas, no como ventanas al razonamiento original del administrador.

Cuatro presiones aparecieron en relojes diferentes

La palabra escasez puede oscurecer más de lo que explica a menos que se nombre el recurso restringido.

La escasez de espacio de direcciones finito concernía al espacio acotado de 32 bits y, más inmediatamente, a los inventarios limitados de números de red de Clase A y Clase B. Una Clase A abarcaba (2^{24}) valores numéricos de dirección local y consumía uno de aproximadamente 126 espacios de número de red ordinarios reconocidos en las tablas de la época. RFC 1466 informó que solo unos 11 números de Clase A estaban sin asignar o sin reservar bajo sus definiciones de política y reservó la mitad superior del espacio de Clase A indefinidamente.

La escasez de estado de enrutamiento concernía a la memoria, procesamiento, actualizaciones de protocolo y estabilidad operativa. Podía volverse aguda mientras grandes porciones del espacio de direcciones numérico permanecían sin asignar. Cada Clase C visible por separado podía añadir un destino a la tabla de un router. La advertencia de RFC 1118 sobre nodos limitados a aproximadamente 700 redes y la serie de enrutamiento de RFC 1338 muestran por qué una Clase B subnetteada podía parecer operativamente más barata que varias redes más pequeñas.

La necesidad a nivel de solicitante era diferente otra vez. La organización de 300 hosts no experimentaba el pool IPv4 completo como abundante. Experimentaba una clase disponible como 46 direcciones de host ordinarias demasiado pequeña y la siguiente como enormemente mayor de lo requerido. Dos Clases C resolvían la capacidad pero introducían posibles costes de enrutamiento y coordinación. La escasez del solicitante era la falta de una unidad de asignación que encajara bien.

La atención administrativa concernía a la capacidad de recibir formularios, hacer preguntas, evaluar planes, conciliar registros, coordinar delegaciones y devolver decisiones. RFC 1174 vinculaba una mayor delegación con el rápido crecimiento y la internacionalización. RFC 1466 decía que la demanda había aumentado significativamente en dos años y que la asignación necesitaba un enfoque más sistemático. RIPE-048 advertía que la revisión global de una solicitud de Clase A podía llevar varios meses.

Estas presiones no se movían juntas. Las tablas de enrutamiento podían crecer rápidamente aunque millones de números de red de Clase C permanecieran teóricamente disponibles. Un pequeño solicitante podía encontrarse con un límite de clase severo mientras el agotamiento numérico total permanecía distante. Un registro central podía enfrentar una carga de trabajo creciente incluso si cada formulario individual era fácil. Una política diseñada para conservar números de Clase B podía imponer deliberadamente más costes de equipo o enrutamiento a los solicitantes.

La separación también impide atajos causales. La existencia de un espacio finito de 32 bits no dictaba un régimen administrativo particular. El diseño de clases determinaba las unidades disponibles. Las restricciones de enrutamiento alteraban sus costes operativos relativos. Las instituciones administrativas decidían cómo distribuir la autoridad y evaluar las excepciones. Los solicitantes suministraban previsiones incompletas y elegían qué solicitudes hacer.

La escasez no fue un evento. Fue un conjunto de restricciones desacopladas.

Las alternativas factibles todas conllevaban costes

Un contrafactual de la época debe preguntar qué podría haberse hecho razonablemente con los protocolos, equipos e instituciones entonces disponibles. No debe asumir que un administrador en 1981 podía resolver el problema escribiendo un prefijo arbitrario moderno en un registro.

Considérese una organización que esperaba 1.000 hosts ordinarios. Cuatro Clases C ofrecían:

[4 \times 254 = 1.016]

direcciones de host ordinarias. Una Clase B ofrecía 65.534. En términos de conservación de direcciones, cuatro Clases C eran dramáticamente mejores. En un sistema de enrutamiento classful, podían requerir cuatro entradas de red visibles externamente. El consejo de RFC 1118 de que un campus no anunciara más de dos redes discretas hacía ese coste material para 1989.

La primera alternativa factible era asignar múltiples Clases C y aceptar los números de red adicionales. Esto no requería un nuevo formato de dirección. Conservaba la capacidad numérica y podía acomodar equipos que no hicieran subnetting. Sus costes incluían registro adicional, configuración y potencialmente rutas globales. El crecimiento futuro podía desencadenar otra solicitud o renumeración.

La segunda alternativa era asignar una Clase B y requerir subnetting interno. Esto conservaba el estado de enrutamiento externo y daba a la organización un margen considerable para el crecimiento. Sus costes eran una reserva mucho mayor de valores de dirección numéricos y la dependencia de hosts y gateways capaces de subnetting. Durante un periodo de implementaciones mixtas de 4.2BSD, 4.3BSD y otras, la compatibilidad era una preocupación operativa más que una ficción administrativa.

Una tercera opción era asignar Clases C contiguas en preparación para una agregación posterior. La contigüidad ayudaba a preservar la posibilidad de representar varias redes como un prefijo una vez que los protocolos y routers de enrutamiento soportaran información arbitraria de red y máscara. Antes de tal soporte, el sistema classful aún interpretaba los componentes como redes de Clase C individuales. La contigüidad por sí sola no hacía desaparecer las entradas de enrutamiento.

RFC 1338 hizo explícita esta dependencia. Su plan de asignación propuesto podía dar bloques de Clase C de tamaño apropiado a organizaciones medianas, pero el beneficio de enrutamiento requería que los protocolos entre dominios representaran destinos arbitrarios de red más máscara. Las organizaciones multihomed podían aún requerir anuncios más específicos. El despliegue demandaba cambios de software, coordinación operativa y acuerdo entre el NIC, IANA y los proveedores de servicios.

Un subnetting más temprano era otra respuesta factible, pero resolvía la topología interna dentro de una clase asignada. No reducía el tamaño de la clase concedida. Una Clase B subnetteada aún ponía 65.536 valores numéricos bajo una asignación. Dividir una Clase A entre organizaciones no relacionadas habría requerido una capa compartida de enrutamiento y administración o un soporte externo sin clases que la arquitectura original de dos niveles no proporcionaba.

El bridging transparente podía hacer que varias LAN parecieran una red, pero trasladaba la complejidad a un dominio de capa de enlace más grande. No eliminaba los costes de fallo, rendimiento o coordinación. No era un sustituto universal para las subredes enrutadas.

La delegación regional o basada en proveedores podía distribuir la atención administrativa sin cambiar el formato de dirección. Se podían delegar bloques de números de Clase C a organizaciones más cercanas a los solicitantes. Esto podía acortar las rutas de comunicación, mejorar el servicio en el idioma local y trasladar la revisión rutinaria fuera del registro central.

La delegación también creaba costes. Los organismos centrales y regionales necesitaban registros consistentes, criterios comunes y procedimientos de actualización fiables. Alguien debía decidir qué institución regional poseía legitimidad, recursos y neutralidad. RFC 1366 y RFC 1466 dedicaron una atención sustancial a esas cualificaciones porque la delegación transfería autoridad consecuente en lugar de meramente trabajo postal.

Otra posibilidad era requerir renumeración o recuperación más frecuentes. Eso podría haber recuperado capacidad no utilizada, pero habría impuesto costes en hosts, gateways, controles de acceso, documentación, redes corresponsales y personal operativo. La recomendación de continuidad de RFC 820 muestra que la dificultad de la renumeración ya era reconocida. Una regla que ignorara esos costes conservaría valores de dirección exportando perturbaciones a los operadores.

Cada alternativa, por tanto, valoraba la escasez de manera diferente:

• Múltiples Clases C conservaban valores de dirección pero podían consumir rutas y transacciones administrativas.
• Una Clase B subnetteada conservaba estado externo pero consumía una unidad de dirección gruesa y requería equipos compatibles.
• Clases C contiguas preservaban opciones de agregación futura pero no proporcionaban enrutamiento sin clases inmediato.
• La delegación regional distribuía la revisión pero requería coordinación, legitimidad y consistencia de registros.
• La renumeración recuperaba capacidad a costa de la continuidad operativa.

El sistema observado no era el único sistema técnicamente posible. Era una respuesta a costes que no podían minimizarse todos a la vez.

Qué cambió, qué persistió y qué no puede inferirse

La evidencia respalda una asignación dividida de la causalidad.

El diseño classful creó las discontinuidades. La dirección de 32 bits podría haberse dividido de otras maneras, pero la arquitectura desplegada ofrecía límites fijos A, B y C. Para un requisito justo por encima de 254 hosts ordinarios, no había una clase nativa que ofreciera un aumento modesto. Eso era una propiedad del protocolo.

El enrutamiento y el hardware hicieron que las discontinuidades fueran significativas económica y operativamente. Varias Clases C podían conservar valores de dirección mientras aumentaban las cargas de números de red y enrutamiento. Una Clase B subnetteada podía conservar estado externo mientras requería software adecuado y consumía una asignación mucho mayor. Estas eran restricciones visibles para los ingenieros contemporáneos.

La política administrativa determinó cómo respondía el sistema. El material publicado temprano contenía criterios de elegibilidad y preparación de gateway pero no reconstruye una interfaz completa de selección de clase. Para 1990–1993, el registro público discutía explícitamente la escasez, la delegación, los umbrales de hosts y subredes, las proyecciones de 24 meses, los planes de ingeniería y las excepciones. El juicio se volvió más estructurado sin desaparecer.

Los resultados a nivel de solicitante permanecen subdeterminados. Las instantáneas disponibles carecen de solicitudes completas, rechazos, alternativas, registros de utilización y explicaciones de decisión. No pueden establecer que los solicitantes técnicamente capaces disfrutaran de un acceso generalmente superior o que los administradores favorecieran sistemáticamente a los titulares. Tampoco pueden establecer que las asignaciones grandes tempranas estuvieran justificadas en todos los casos.

Las instantáneas sí muestran un mecanismo plausible de dependencia de la trayectoria. Una vez que un destinatario desplegaba una asignación, la renumeración imponía costes. RFC 820 reconocía explícitamente la dificultad como razón para preservar un número cuando una red experimental se volvía operativa. Una asignación grande temprana podía, por tanto, permanecer en su lugar después de que los criterios para nuevas asignaciones comparables se endurecieran.

El beneficio debe describirse como una opción, no como un dividendo medido. El destinatario podía expandirse internamente, continuar presentando un destino classful, renumerar con menos frecuencia o retener capacidad cuya adquisición posterior se volvió difícil. Si un destinatario particular usó esas opciones, las merecía o anticipó su importancia posterior es una cuestión empírica separada.

La evidencia moderna confirma la persistencia sin resolver los motivos tempranos. Un estudio de 2017 sobre transferencias de IPv4 informadas encontró que el espacio de legado representaba el 63,82% del espacio de direcciones en su muestra de transferencias informadas. La misma investigación mostró por qué los registros posteriores deben interpretarse con cautela: los cambios de enrutamiento pueden reflejar cambios de proveedor, reasignación, reestructuración organizativa o gestión compleja de direcciones en lugar de una venta.

Ese resultado es relevante solo como una comprobación limitada. Muestra que las asignaciones de la era pre-registro persistieron lo suficiente como para participar materialmente en la redistribución posterior. No muestra por qué se seleccionó una clase en 1983, si el solicitante original suministró una previsión precisa, si la asignación fue justa o qué pretendía un administrador temprano.

El valor monetario actual está aún más alejado de la decisión temprana. Un precio actual aplicado a todas las direcciones dentro de un bloque de legado ignoraría el espacio no enrutado, las restricciones de política, los costes de transacción, la fragmentación, las dependencias operativas y la distinción entre registro y control. Más importante aún, sustituiría la escasez posterior por el motivo contemporáneo.

La conclusión histórica es, por tanto, acotada pero consecuente. El IPv4 classful convirtió la granularidad técnica en una frontera de decisión administrativa. Los límites de enrutamiento a veces hacían defendible la unidad más grande. Los límites de los equipos a veces hacían costoso el subnetting. Los primeros solicitantes y administradores operaban con previsiones que ahora no pueden reconstruirse a partir de los registros completados. Las políticas posteriores hicieron los criterios de equilibrio más explícitos y trasladaron el trabajo hacia instituciones regionales y basadas en proveedores.

La escasez administrativa nació en el hueco entre 254 y 65.534, pero no porque el hueco dictara una respuesta. Nació porque cada respuesta disponible imponía costes a una parte o sistema diferente, y alguien debía decidir qué coste aceptar.

Fuentes

• RFC 790,Assigned Numbers
• RFC 791,Internet Protocol
• RFC 820,Assigned Numbers
• RFC 950,Internet Standard Subnetting Procedure
• RFC 1118,The Hitchhikers Guide to the Internet
• RFC 1122,Requirements for Internet Hosts—Communication Layers
• RFC 1166,Internet Numbers
• RFC 1174,IAB Recommended Policy on Distributing Internet Identifier Assignment
• RFC 1338,Supernetting: an Address Assignment and Aggregation Strategy
• RFC 1366,Guidelines for Management of IP Address Space
• RFC 1466,Guidelines for Management of IP Address Space
• RFC 1482,Aggregation Support in the NSFNET Policy-Based Routing Database
• RIPE-048,RIPE Internet Network Numbers Template
• Computer History Museum,Guide to the SRI ARC/NIC Records
• University of Bristol,25 Years of Internet at University of Bristol
• On IPv4 Transfer Markets: Analyzing Reported Transfers and Inferring Transfers in the Wild