La restricción de 32 bits fue técnica; el régimen de racionamiento fue político

Resumen

• RFC 791fijó cada dirección IPv4 de origen y destino en 32 bits e inicialmente interpretó las direcciones unicast ordinarias a través de tres clases; no prescribió registros regionales, previsiones de demanda, pruebas de utilización, dependencia del proveedor, auditorías, sanciones o apelaciones.
• Los (2\^{32}) valores nominales, o 4.294.967.296, posibles de 32 bits nunca fueron un único conjunto de direcciones de host públicas asignables. La estructura de clases, los valores especiales, las reservas, las tenencias de asignación, la visibilidad de enrutamiento y el uso real crearon diferentes denominadores que no se pueden combinar.
• Desde 1993 hasta 1996, las directrices publicadas seleccionaron reglas consecuentes: previsiones de 24 meses y umbrales de Clase B en RFC 1466; agregación basada en topología en RFC 1519; y asignaciones de inicio lento, jerarquía de proveedores, pruebas de utilización, auditorías, devolución de direcciones y apelaciones al registro principal en RFC 2050.
• La conservación y la agregación respondieron a peligros de ingeniería genuinos, especialmente el desperdicio con clase y el crecimiento de la tabla de enrutamiento. El elemento político no residió en inventar la escasez, sino en que instituciones identificables eligieron entre formas viables de distribuir sus costes, autoridad, excepciones y remedios.
• Los registros de asignación pública muestran resultados exitosos, no las solicitudes, rechazos, revisiones, retrasos o directrices informales que los produjeron. El texto del régimen y su justificación técnica se pueden reconstruir con más confianza que su efecto distributivo completo.

La arquitectura estableció el límite; la administración seleccionó la prueba

Dos registros fechados establecen la distinción esencial.

En septiembre de 1981, RFC 791 especificó un campo de Dirección de Origen y un campo de Dirección de Destino, cada uno de 32 bits de ancho. Definió una dirección de Internet como cuatro octetos y dividió su interpretación unicast ordinaria inicial entre los formatos Clase A, Clase B y Clase C. Una dirección de Clase A utilizaba un bit de identificación de clase, siete bits de número de red y 24 bits de dirección local. La Clase B usaba dos bits de clase, 14 bits de número de red y 16 bits de dirección local. La Clase C usaba tres bits de clase, 21 bits de número de red y ocho bits de dirección local. Esas eran características del protocolo, indicadas en la discusión de direccionamiento y la especificación de la cabecera.RFC 791, septiembre de 1981, secciones 2.3 y 3.1, páginas 7 y 11-12

En mayo de 1993, RFC 1466 recomendó que un registro dimensionara las concesiones contiguas de Clase C a partir de la proyección del suscriptor de las direcciones de sistema final necesarias durante los siguientes 24 meses. Una proyección por debajo de 256 direcciones se asignaba a un número de red de Clase C; por debajo de 512 a dos; por debajo de 1.024 a cuatro; y así sucesivamente, hasta 64 números de red de Clase C contiguos para una proyección por debajo de 16.384. Para una Clase B, el documento decía que un solicitante debía demostrar más de 32 subredesymás de 4.096 hosts, respaldado por un plan de ingeniería que cubriera los siguientes 24 meses.RFC 1466, mayo de 1993, secciones 4.2.1 y 4.3, páginas 6-8

RFC 1466 era Informacional. Su aviso de estado decía expresamente que no especificaba un estándar de Internet. Elise Gerich lo redactó; el resumen registraba el apoyo general a sus recomendaciones del Grupo de Planificación de Ingeniería Federal en nombre del Consejo Federal de Redes, los copresidentes del Grupo de Planificación de Ingeniería Intercontinental y RIPE. Esa combinación es evidencia de una recomendación elaborada con apoyo institucional. No es evidencia de que cada registro implementara inmediatamente cada umbral, de que una acción de estándares del IETF obligara a la política, o de que cada red afectada estuviera de acuerdo con ella.RFC 1466, estado, resumen y agradecimientos, páginas 1 y 9

El protocolo y la directriz respondían a preguntas diferentes. Un campo de 32 bits definía el espacio matemático exterior. No seleccionaba un horizonte de previsión, una jerarquía de asignación, una fórmula de utilización, una región geográfica, una facultad de auditoría o una vía de apelación. Las reglas pudieron ser respuestas prudentes a limitaciones genuinas, pero no se derivaban de la cabecera.

Ese es el significado acotado depolíticoaquí. Identifica una decisión de una institución autora o implementadora nombrada entre arreglos técnica y administrativamente plausibles, donde la selección desplazó la autoridad o impuso diferentes costes de documentación, retraso, dependencia del proveedor, enrutamiento, renumeración o revisión. No significa que la escasez fuera fabricada, que los actores fueran partidistas o que sus elecciones fueran corruptas. Pregunta quién seleccionó la regla, qué parámetro alternativo podría haberse seleccionado bajo las condiciones de la época, y dónde recayó la carga o autoridad resultante.

Un espacio de direcciones produjo varios denominadores incompatibles

La aritmética familiar es exacta:

[\n2\^{32}=4.294.967.296\n]

Su unidad son valores binarios nominales por campo de dirección de origen o destino de 32 bits. No es un recuento de hosts públicos asignables, organizaciones, conexiones de clientes, concesiones de registros, prefijos enrutados o solicitudes de espacio.

Los bits de clase dividieron inmediatamente ese espacio matemático. El campo bruto de número de red de Clase A contenía (2^7=128) patrones de bits; la Clase B contenía (2\^{14}=16.384); y la Clase C contenía (2\^{21}=2.097.152). La contabilidad administrativa no trataba cada patrón bruto como un número de red ordinario. En cambio, la tabla de mayo de 1992 de RFC 1466 contaba 126 Clase A, 16.383 Clase B y 2.097.151 números de red de Clase C. Esas cifras son poblaciones de números de red con clase, no valores de dirección ni organizaciones.

La tabla también registraba 49 números de red de Clase A asignados, 7.354 de Clase B asignados y 44.014 de Clase C asignados en mayo de 1992. Estas son entradas exitosas en una tabla administrativa particular. No revelan el número de solicitantes ni miden cuántas direcciones estaban ocupadas, anunciadas, accesibles o solicitadas.RFC 1466, sección 3, Tabla 1, página 3

Las distinciones no son minuciosidad semántica. Cada fila responde a una pregunta diferente. Una asignación de nivel superior reduce un fondo administrativo sin mostrar que el espacio asignado esté anunciado. Una ruta puede cubrir un bloque grande con pocos extremos ocupados. Varias rutas pueden representar una asignación. Una asignación puede permanecer sin uso, mientras que un host puede tener varias direcciones o interfaces. La propia RFC 791 contemplaba hosts con múltiples interfaces físicas y múltiples direcciones lógicas de Internet. Un libro mayor de registro y una tabla de enrutamiento no se pueden fusionar simplemente porque ambos contienen prefijos.

La convención ordinaria de identificador de host de la época creó otra población más. RFC 1519 describió una red de Clase C como capaz de soportar como máximo (2^8-2=254) identificadores de host ordinarios y una Clase B como capaz de soportar como máximo (2\^{16}-2=65.534), después de excluir los valores locales todo-ceros y todo-unos utilizados bajo la convención citada. Estos son identificadores ordinarios potenciales dentro de una red, no recuentos de hosts conectados.RFC 1519, Estándar Propuesto, septiembre de 1993, sección 1, páginas 1-2

Supóngase, solo a efectos de escala, que se requiriera un identificador para cada uno de 600 hosts conectados. Los 65.534 identificadores ordinarios de una Clase B proporcionarían (65.534/600=109,223) veces el requisito indicado, dejando (65.534-600=64.934) identificadores ordinarios fuera de ese requisito inmediato. El cálculo demuestra la granularidad con clase; no prueba que un solicitante real de 600 hosts no necesitara reserva, tuviera una topología plana o pudiera operar un bloque arbitrario sin clase.

RFC 1466 ofrecía un ejemplo diferente de 600 hosts. Si los 600 hosts se dividían equitativamente entre diez Ethernets y la topología dificultaba un bloque de Clase C compartido, el suscriptor podría recibir diez números de red de Clase C, uno por Ethernet, sujeto a una justificación de ingeniería para desviarse de la tabla predeterminada de potencias de dos. La unidad allí eran números de red de Clase C, no 600 direcciones extraídas de un fondo libre.RFC 1466, sección 4.3, página 8

La evidencia posterior requiere igual cuidado. El estudio de consumo de IPv4 de CAIDA se construyó a partir de un archivo de IANA recopilado el 14 de septiembre de 2005 y de instantáneas WHOIS tomadas el 31 de agosto de 2005 para ARIN, APNIC, LACNIC y RIPE. Carecía de una instantánea de AfriNIC. CAIDA eliminó las diferencias de formato para crear una representación compartida y restringió las filas de cada RIR al espacio asociado con ese registro en el archivo de IANA, reduciendo las apariciones duplicadas causadas por migración y referencias cruzadas. Combinó el material heredado migrado en un conjunto separado "varios".CAIDA, “IPv4 Consumption Rates,” Metodología y Advertencias

Sus cifras utilizaban volumen de direcciones, comúnmente expresado como cantidades equivalentes/8. Distinguían las asignaciones de IANA, la primera ocurrencia de registro aguas abajo y la asignación más específica encontrada en los datos. CAIDA dijo expresamente que los gráficos mostraban asignaciones, no anuncios o alcanzabilidad. También explicó que una limpieza de IANA asignó agosto de 1993 a muchos registros heredados para los cuales no se disponía de fechas históricas precisas. Esas son fechas administrativas rellenadas, no fechas de transacción recuperadas.CAIDA, Metodología, Advertencias y Figuras 1-7

La reconstrucción es útil para mostrar por qué los niveles administrativos deben separarse. No es evidencia contemporánea de la experiencia de los solicitantes en 1993. No mide solicitudes, rechazos, revisiones, rutas, anuncios, hosts accesibles, interfaces ocupadas, motivos o causalidad de políticas.

A Primer on IPv4 Scarcityde Richter, Allman, Bush y Paxson es aún posterior. El artículo se envió el 10 de noviembre de 2014, se revisó el 27 de febrero de 2015 y se publicó como contribución editorial enACM Computer Communication Review45(2) en abril de 2015. Es una valiosa síntesis retrospectiva y una fuente principal para desarrollos técnicos, institucionales y de la era de agotamiento. No puede establecer lo que un actor sabía en 1981-1998, cómo un solicitante de la época experimentó un registro, si se desplegó un mecanismo, o si los contemporáneos sostenían una doctrina posterior de mercado o propiedad.Richter et al., “A Primer on IPv4 Scarcity,” registro de publicación

El límite matemático exterior era singular. La escasez operativa no. Aparecía en recuentos de números de red con clase, rangos reservados, tenencias de registros, unidades de asignación y estado del enrutador, cada uno con su propia fecha y denominador.

El desperdicio con clase y la presión de enrutamiento eran genuinos

La primera presión inmediata provino de la granularidad. Una organización que requería más de 254 identificadores de host ordinarios no tenía una unidad de asignación con clase nativa proporcional a un requisito de 300, 600 o 4.000. Una Clase B podía ser demasiado grande. Una colección de Clase C podía estar más cerca en volumen de direcciones pero ser más difícil de gestionar y, antes de la agregación efectiva, más costosa para el sistema de enrutamiento global.

La subred ayudó dentro de una red con clase existente. RFC 950, una especificación en vía de estándar de agosto de 1985, definió una máscara de dirección que dividía el campo de dirección local en porciones de subred y host. Una organización podía usar un número de red reconocido externamente a través de múltiples subredes internas en lugar de anunciar cada cable interno como una red independiente. Por sí sola, no permitía que un registro emitiera longitudes de prefijo arbitrarias enrutadas globalmente a una Internet cuya maquinaria entre dominios aún dependía de la interpretación de clase.RFC 950, agosto de 1985, sección 2.1, páginas 4-6

La segunda presión fue la tabla de reenvío. Reemplazar una antigua concesión de Clase B con 16 redes de Clase C anunciadas por separado podía preservar un número de red de Clase B mientras añadía 16 entradas de enrutamiento donde la agregación no estaba disponible. La conservación de direcciones y la conservación de enrutamiento podían, por tanto, apuntar en direcciones opuestas.

RFC 1519, publicada como Estándar Propuesto en septiembre de 1993, describió tres problemas: el agotamiento rápido de los números de red de Clase B, el crecimiento de la tabla de enrutamiento más allá de la capacidad del software y los enrutadores disponibles, y el eventual agotamiento del espacio de 32 bits. Su estrategia inmediata fue CIDR: emitir bloques contiguos de tamaño más apropiado, alinear la distribución con la topología y anunciar agregados cuando el soporte del protocolo y la conectividad lo permitían.RFC 1519, estado y secciones 1-3, páginas 1-9

Su argumento cuantitativo necesita tanto la tabla exacta como la prosa redondeada.

La Tabla I, proveniente de MERIT, registró 4.526 rutas anunciadas en enero de 1992 y 8.561 en diciembre de 1992. La sección 3.3.2, en cambio, describió la base de datos de enrutamiento de NSFNET de enero como conteniendo “aproximadamente 4700” entradas y la tabla de diciembre como conteniendo 8.500. Dijo que la tabla histórica se había duplicado en promedio cada diez meses entre 1988 y 1991 y publicó una proyección de aproximadamente 30.000 entradas dos años después de la línea base de enero de 1992.RFC 1519, Tabla I y sección 3.3.2, páginas 7-9

Esa proyección no se sigue de las entradas redondeadas indicadas:

[\n4.700\times 2\^{24/10}=24.806,75\n]

Usando la observación exacta de enero de la Tabla I se obtiene:

[\n4.526\times 2\^{24/10}=23.888,37\n]

Ninguno de los resultados es aproximadamente 30.000 bajo redondeo ordinario. El artículo solo puede conservar 30.000 como la proyección publicada y no reconciliada de los autores del RFC. La fuente no explica la diferencia de aproximadamente 5.193 entradas entre 30.000 y el resultado de la entrada redondeada. Sería inapropiado inventar una línea base, intervalo de crecimiento o ajuste oculto diferente para cerrar la brecha.

La comparación de diciembre es más directa. La unidad observada de la Tabla I fue de 8.561 rutas anunciadas en diciembre de 1992. La sección 3.3.2 redondeó eso a 8.500 y lo comparó con más de 9.400 predichos por una curva anterior. Los autores dijeron que no podían decir si la observación más baja representaba un cambio significativo en el crecimiento. Estas eran observaciones y previsiones del contexto MERIT/NSFNET, no un censo de cada enrutador o un límite físico en el que Internet fallaría.

El RFC también consideró el efecto de emitir de cuatro a 16 rutas de Clase C donde anteriormente se podría haber usado una Clase B. Proyectó condicionalmente que la tabla de enrutamiento podría superar las 10.000 entradas en seis meses y las 20.000 en un año. Esos fueron resultados de escenarios basados en redes de Clase C anunciadas por separado, no resultados observados. La agregación pretendía evitar precisamente esa multiplicación.

La lógica de ingeniería era sólida. Si los clientes conectados a través de un proveedor recibían subconjuntos contiguos del bloque del proveedor, el proveedor podía anunciar una ruta menos específica. Diez bloques de clientes enrutados independientemente podrían requerir diez entradas visibles globalmente; diez bloques de clientes alineados topológicamente podrían, sujeto a excepciones y operación correcta, estar detrás de un agregado. El ahorro exacto dependía de la multihoming, la política de enrutamiento, los fallos, los filtros y si las rutas más específicas aún debían propagarse.

La transición no fue automática. RFC 1338, una propuesta Informacional publicada en junio de 1992 y posteriormente obsoleta por RFC 1519, advirtió que se requerían tanto el nuevo plan de direccionamiento como cambios en los protocolos de enrutamiento entre dominios. Afirmó que las tablas de enrutamiento podían crecer muy rápidamente en el intervalo entre el despliegue de asignaciones orientadas a la topología y el despliegue de protocolos compatibles.RFC 1338, junio de 1992, sección 2.1, página 4

BGP-4 proporcionó una especificación para transportar prefijos sin clase y agregar rutas, pero el estado de publicación no debe confundirse con el despliegue. RFC 1654 fue una especificación de BGP-4 en vía de estándar en julio de 1994. RFC 1771, también en vía de estándar, la reemplazó en marzo de 1995 y describió el soporte para prefijos IP, la eliminación del concepto de clase de red dentro de BGP y la agregación de rutas y AS-path.RFC 1654, julio de 1994, estado y secciones 1-2, páginas 1-2;RFC 1771, marzo de 1995, estado y secciones 1-2, páginas 1-2

Esas publicaciones establecen el estado de la especificación y la capacidad documentada. No establecen cuántos enrutadores ejecutaban BGP-4 en una fecha determinada, qué redes intercambiaban rutas sin clase, cuánto de la tabla estaba agregado o si la adopción era universal para 1998. Sin una serie de instantáneas de enrutamiento nombrada, fecha de observación, población y punto de observación, no se justifica ninguna tasa de despliegue numérica ni afirmación de "establecido para 1998".

La regla de previsión asignó incertidumbre

La regla de Clase B de RFC 1466 expone la elección institucional con mayor claridad. Sus criterios establecidos pedían más de 32 subredesymás de 4.096 hosts. El solicitante también debía mostrar por qué un bloque de Clase C no era razonable y proporcionar recuentos esperados de hosts y subredes para los siguientes 24 meses. Si el plan no justificaba una Clase B, el resultado establecido era un bloque de Clase C. Un solicitante que no cumplía los criterios numéricos pero no podía usar Clase C podía presentar un caso de ingeniería. El documento llamaba a los umbrales criterios sugeridos en lugar de un invariante de protocolo.RFC 1466, sección 4.2.1, páginas 6-7

El objetivo técnico inmediato era la conservación de los números de red de Clase B. Bajo la convención de la época, una Clase B exponía 65.534 identificadores de host ordinarios. Conceder esa unidad a una red con un requisito mucho menor podía dejar varada una gran parte de su capacidad. El plan de subredes comprobaba si el solicitante necesitaba la topología que una Clase B podía acomodar en lugar de simplemente preferir su conveniencia.

RFC 1466 reconoció la carga. Dijo que las restricciones en las asignaciones de Clase B podían requerir que algunas organizaciones gastaran recursos adicionales usando múltiples números de red de Clase C. El documento consideró ese coste como desafortunado pero necesario para perseguir la conservación. Esta es una evidencia inusualmente directa de la incidencia del coste: la recomendación autora seleccionó una regla de conservación e identificó un gasto extra de ingeniería por parte de los solicitantes afectados como consecuencia.RFC 1466, sección 4.2, página 6

El horizonte de 24 meses era, no obstante, un parámetro. El RFC Informacional documentó por qué se requerían previsiones, pero no demostró que 24 meses minimizaran de forma única el desperdicio total de direcciones, el coste de procesamiento, el retraso o el error de previsión. Una prueba de 12, 18 o 36 meses sería una variación construida por un analista a menos que se produjera una propuesta directa de la época. Tales variaciones son administrativamente concebibles porque el mismo solicitante podría presentar las mismas categorías de evidencia de ingeniería en un horizonte diferente. Su desempeño práctico sigue siendo desconocido: un horizonte más corto reduciría la exposición a un crecimiento optimista pero aumentaría las solicitudes repetidas, mientras que un horizonte más largo podría reducir la frecuencia de transacciones a costa de un mayor error de previsión.

La asignación sin clase era una alternativa técnicamente más fundamentada para 1993, pero solo dentro de ciertos límites. RFC 1338 había propuesto bloques de proveedor contiguos en junio de 1992, y RFC 1519 especificó la estrategia de asignación y agregación CIDR en septiembre de 1993. Sus propias advertencias muestran las suposiciones requeridas: los registros tenían que asignar en límites adecuados, los proveedores tenían que mantener bloques alineados con la topología y los protocolos y enrutadores entre dominios tenían que soportar pares arbitrarios de red y máscara. Antes de que esas condiciones se implementaran suficientemente, emitir bloques más finos podría multiplicar las rutas en lugar de reducirlas.

RFC 2050 cambió el diseño de previsión en noviembre de 1996. Separó las asignaciones de ISP de las asignaciones de empresa final. La sección 2.1 decía que los nuevos ISP recibirían una asignación mínima basada en requisitos inmediatos. Las asignaciones posteriores podrían aumentar después de que el ISP proporcionara verificación de utilización, y el espacio adicional estaba destinado a soportar aproximadamente tres meses de asignaciones aguas abajo. Se decía que la base de clientes proyectada tenía poco efecto; los requisitos demostrados gobernaban.RFC 2050, BCP 12, noviembre de 1996, sección 2.1, páginas 4-5

Las famosas cifras del 25 y 50 por ciento pertenecían a otro lugar. Aparecían en la sección 3.1, dentro del marco de asignación para empresas finales: una tasa de utilización inmediata del 25 por ciento y una tasa de utilización del 50 por ciento dentro de un año. La sección 3.6 definía el numerador como el número de hosts conectados a la red y el denominador como el total de hosts posibles en esa red. El criterio de un año significaba, por tanto, que se esperaba que los hosts conectados alcanzaran al menos el 50 por ciento de la población de hosts posible de la red dentro de ese horizonte. No era una relación de clientes a direcciones, direcciones asignadas a tamaño de asignación, interfaces a direcciones o asignaciones aguas abajo a una asignación de ISP.RFC 2050, secciones 3.1 y 3.6, páginas 7 y 9

La distinción cambia el análisis institucional. Las empresas finales enfrentaban una prueba de utilización de hosts conectados contra los hosts posibles en su red propuesta. Los ISP enfrentaban inicio lento, uso verificado aguas abajo y una cantidad de reposición destinada a cubrir aproximadamente tres meses de asignaciones adicionales. Combinarlos crearía una métrica común ficticia.

Ambos diseños colocaban la incertidumbre de la previsión en algún lugar. Una concesión inicial más larga exponía el fondo común si la demanda no se materializaba. Una concesión inicial más pequeña aumentaba la importancia de la capacidad de respuesta del registro y la capacidad del solicitante para documentar el crecimiento repetido. Los RFC establecen las reglas seleccionadas y sus objetivos declarados. No proporcionan distribuciones de tiempo de procesamiento, cantidades solicitadas inicialmente, historiales de revisión o evidencia de que una clase de solicitante soportara sistemáticamente más retraso.

La jerarquía convirtió la topología en dependencia

RFC 1466 propuso dividir porciones del espacio de números de clase C en grandes bloques geográficos y delegar la responsabilidad de asignación primaria a registros regionales calificados. Describió la división como "principalmente una división administrativa" destinada a apoyar el registro distribuido. Favorecía un único registro regional a ese nivel, esperaba que la organización fuera reconocida y tuviera recursos adecuados, y requería compromiso con las directrices de IANA y el registro central de Internet. El registro central permanecía disponible para atender a un suscriptor si era necesario, aunque podía remitir al suscriptor al organismo regional.RFC 1466, secciones 2, 3 y 4.3, páginas 2-4 y 7

El plan circundante vinculaba la administración distribuida con la agregación potencial. Los bloques geográficos podían reducir la carga de trabajo central y podían apoyar resúmenes gruesos donde la geografía y la topología se alinearan. Ninguna relación estaba garantizada. Un continente no estaba codificado en la cabecera IPv4, y la topología física o del proveedor no seguía necesariamente un límite regional.

La elección de un único registro regional reconocido concentró la autoridad interpretativa sobre las asignaciones locales, la evidencia y las excepciones. Una base de datos compartida con registros superpuestos, o una elección general del solicitante entre decisores centrales y regionales, sería una alternativa analítica en lugar de una propuesta documentada de la época en las fuentes utilizadas aquí. Su viabilidad asumiría coordinación oportuna de base de datos, comprobaciones de unicidad fiables, reglas de asignación comunes y una forma de prevenir concesiones competidoras. Esas suposiciones eran administrativamente exigentes en 1993. La alternativa es útil para ubicar la autoridad, no para afirmar que los registros superpuestos habrían funcionado mejor.

RFC 1519 desplazó la jerarquía hacia la topología del proveedor. Recomendó que la mayoría, si no todos, los números de red se distribuyeran a través de proveedores de servicios. Su justificación de ingeniería era directa: las direcciones tomadas del bloque de un proveedor podían ser representadas por el agregado del proveedor, mientras que los bloques ubicados independientemente a menudo requerían rutas más específicas. El documento también argumentó que la asignación distribuida reducía la carga burocrática sobre las autoridades centrales de numeración.RFC 1519, secciones 2.2 y 3, páginas 5-8

RFC 2050 describió un sistema de registro de tres niveles: IANA, registros regionales de Internet y registros locales de Internet. Dentro del marco de ISP, un ISP que intercambiara rutas en múltiples ubicaciones sin enrutamiento por defecto podía solicitar espacio directamente de su registro regional. A otros ISP se les dijo que solicitaran espacio a un proveedor aguas arriba. El acceso regional directo estaba asociado con el multihoming o la conexión a un intercambio neutral importante, que el RFC definió como aquel que conectaba a cuatro o más ISP no relacionados.RFC 2050, secciones 1.1 y 2.1, páginas 3-4

La misma sección alentaba a los proveedores a tratar las asignaciones de clientes como préstamos por la duración de la conectividad. Cuando un cliente cambiaba de proveedor, recomendaba la devolución de las direcciones antiguas y la renumeración en el espacio del nuevo proveedor, con un tiempo de transición suficiente antes de la reutilización. Esta era una estrategia de enrutamiento con una consecuencia de coste de cambio. El espacio derivado del proveedor mejoraba la oportunidad de agregación; la continuidad de las direcciones del cliente pasaba a depender de la relación con el proveedor.

Los costes ya estaban reconocidos. RFC 1900, una declaración Informacional del Internet Architecture Board en febrero de 1996, decía que las organizaciones que no renumeraran después de cambiar de proveedor podían enfrentar conectividad limitada, coste extra para soportar la sobrecarga de enrutamiento resultante, o ambos. Su título,Renumbering Needs Work(La renumeración necesita trabajo), capturaba el estado de la técnica. Llamaba al desarrollo y despliegue de mecanismos para facilitar los cambios; no informaba que la renumeración se hubiera vuelto barata o rutinaria.RFC 1900, febrero de 1996, sección 1, páginas 2-3

Los responsables nombrados de decisiones e implementación fueron los autores de los RFC, las autoridades de IANA y de registros, los registros regionales y locales, los proveedores que asignaban espacio y las redes de tránsito que aceptaban o filtraban rutas. La alternativa factible de la época no era el direccionamiento portátil ilimitado. Era un equilibrio diferente: más asignaciones directas reducirían parte de la dependencia de renumeración del cliente pero, en ausencia de una agregación fiable o coordinación de aceptación de rutas, podrían añadir prefijos visibles globalmente. El registro superviviente prueba la dirección del intercambio. No cuantifica cuántos clientes renumeraron, cuántos retuvieron rutas antiguas, lo que pagaron o con qué consistencia los proveedores hicieron cumplir la devolución.

El poder de auditoría existió en papel; su práctica sigue sin medirse

La tercera elección institucional concernía a la verificación y las consecuencias.

RFC 1466 permitía al registro central de Internet recibir planes contables y de ingeniería de las asignaciones regionales delegadas y auditar esos planes para verificar su consistencia con las directrices. Las excepciones a los criterios de dimensionamiento de Clase C debían decidirse caso por caso. El documento no proporcionaba un registro de excepciones, un período de respuesta estándar, una carga de prueba publicada o un revisor independiente.RFC 1466, secciones 4.2.2 y 4.3, páginas 7-8

RFC 2050 describió un cuerpo de evidencia más extenso. Un registro podía requerir máscaras de subred, recuentos de hosts, topología, planes de enrutamiento, calendarios de despliegue, asignaciones previas y corroboración. El espacio anterior mantenido por divisiones o subsidiarias bajo un mismo padre podía considerarse a nivel de empresa. Las solicitudes se manejaban caso por caso, con la eficiencia de enrutamiento entre las consideraciones relevantes.RFC 2050, secciones 3.2-3.5, páginas 8-9

La sección 4 establecía que todas las solicitudes de direcciones estaban sujetas a auditoría y verificación por cualquier medio que el registro regional considerara apropiado. Si se descubría que una asignación se basaba en información falsa, el registro podía invalidar la solicitud y devolver las direcciones asignadas al fondo libre. La sección 3.1 establecía por separado que una dirección seguía siendo válida mientras se continuaran cumpliendo los criterios de calificación y reservaba una facultad de invalidación cuando la necesidad ya no existiera. La recomendación de devolución de la sección 2.1 se aplicaba a las direcciones de clientes derivadas de proveedores cuando terminaba la conectividad. Estas eran autoridades relacionadas pero distintas: invalidación por información falsa, revisión de necesidad continua y devolución por cambio de proveedor.RFC 2050, secciones 2.1, 3.1 y 4, páginas 4-5, 7 y 10

El texto también proporcionaba revisión jerárquica. La sección 6 permitía a una organización insatisfecha con un registro asignador apelar al registro principal. La documentación relevante debía ponerse a disposición, y una apelación adicional podía subir en la cadena hasta IANA. Se esperaba que cada registro documentara su proceso de apelación. El revisor permanecía dentro de la misma jerarquía de registros; el RFC no creó un tribunal externo.RFC 2050, sección 6, página 11

Estas disposiciones autorizaban la aplicación y la revisión. No demuestran la práctica. Ningún archivo citado establece con qué frecuencia ocurrió una auditoría, qué métodos se utilizaron, si los solicitantes recibieron notificación o una oportunidad de subsanación, cómo se distinguió el error de previsión de la tergiversación, con qué frecuencia se devolvieron las direcciones o si una apelación alteró un resultado. El texto no puede mostrar consistencia entre registros o casos individuales.

Varias variaciones de procedimiento son concebibles bajo la tecnología de 1996 porque cambian la administración en lugar de los formatos de paquete: razones escritas para excepciones, un protocolo de auditoría definido, un período de notificación y subsanación, estadísticas anonimizadas o revisión por funcionarios fuera de la cadena de decisión original. Son parámetros construidos por analistas a menos que se produzca una propuesta fechada. Requerirían personal, mantenimiento de registros, controles de confidencialidad y autoridad acordada. Sus costes y efectos no se pueden estimar solo con el RFC.

La elección institucional fue, por tanto, real pero acotada. RFC 2050 otorgó a los registros regionales discreción sobre la verificación y las consecuencias declaradas, al tiempo que situó la revisión en la cadena principal. Ese diseño podía disuadir reclamaciones falsas y preservar los registros de direcciones. También concentraba la autoridad de investigación de hechos, excepciones y aplicación. La evidencia de que la autoridad existía es sólida; la evidencia sobre su invocación y efectos distributivos está ausente.

El registro de RIPE prueba menos de lo que lo haría un archivo de concesión

El episodio de RIPE proporciona evidencia de operación delegada, pero no una decisión de asignación completa.

RIPE-062,RIPE NCC Internet Numbers Registration Procedures, versión 0.5 fechada en julio de 1992, apareció como Apéndice A del primer informe trimestral del RIPE NCC. Decía que el RIPE NCC había actuado desde el 1 de mayo de 1992 como registro delegado para números de red de Internet europeos. Su procedimiento era proporcionar números a proveedores de servicios y organismos de coordinación nacionales o locales en lugar de directamente a organizaciones individuales. Permitía a los proveedores de servicios solicitar números de red de Clase B de uno en uno y requería justificación basada en el tamaño de la organización, la red existente, el crecimiento esperado y la incapacidad de usar un bloque de Clase C.RIPE-062, versión 0.5, julio de 1992, página 25 y siguientes

RFC 1466 sección 3 registró más tarde dos hechos más concretos. El RIPE NCC ya había recibido el intervalo de números de red de Clase C de 193.0.0 a 193.255.255 antes de la adopción de la propuesta del RFC, y había acordado asignar dentro de ese intervalo bajo las directrices de RFC 1466.RFC 1466, sección 3, página 3

El intervalo contiene (2\^{16}=65.536) números de red de Clase C de tamaño/24. Expresado como el intervalo CIDR posterior 193.0.0.0/8, cubre (2\^{32-8}=16.777.216) valores de dirección nominales. El primer número cuenta unidades de número de red de Clase C; el segundo cuenta valores binarios cubiertos por el intervalo. Ninguno mide hosts conectados, concesiones aguas abajo, anuncios, uso o la cantidad que solicitó el RIPE NCC.

Los registros supervivientes no proporcionan la solicitud subyacente, un instrumento de concesión formal, un memorando de decisión, tamaños de bloque alternativos considerados, condiciones negociadas o una fecha de concesión exacta. RIPE-062 prueba un procedimiento delegado. RFC 1466 prueba la posesión previa del bloque 193.* y el acuerdo de usar las nuevas directrices. La administración distribuida y la agregación potencial eran objetivos del plan de políticas circundante; no se pueden afirmar como el motivo documentado o la condición negociada de esta concesión particular.

El registro tampoco contiene ningún archivo de apelación o revisión relativo a la delegación. Apoya un hallazgo a nivel de registro de que la delegación estaba operando para 1992. No puede apoyar una conclusión a nivel de solicitante sobre rechazo, trato desigual, retraso o la incidencia de un umbral.

Las respuestas técnicas llegaron por etapas

La época no ofreció un sustituto completamente formado para el racionamiento. Ofreció respuestas parciales con diferentes estados, prerrequisitos y transferencias de costes.

El espacio privado ilustra la diferencia entre especificación y sustitución. RFC 1918, BCP 5 en febrero de 1996, reservó tres bloques para redes privadas. Requería que una empresa decidiera qué hosts no necesitaban conectividad de capa de red externa. Mover un host entre el estado privado y público implicaba cambiar su dirección IP, las entradas DNS relevantes y los archivos de configuración en otros hosts que hicieran referencia a la dirección. La información de enrutamiento privada no debía propagarse a través de los límites de la empresa, y las referencias DNS privadas requerían contención.RFC 1918, febrero de 1996, secciones 2-5, páginas 3-7

NAT era más que un concepto para mayo de 1994 pero menos que una solución universal probada. RFC 1631 era Informacional y describía un diseño preliminar. La sección 3 explicaba que las aplicaciones que transportaban una dirección IP en sus datos podían fallar a menos que el traductor reconociera y reescribiera el contenido; el cifrado podía hacer eso imposible. La sección 4 identificó implementaciones experimentales en el software KA9Q y un enrutador Cray Communications, probadas con Telnet y FTP, y dijo que los prototipos demostraban transparencia solo dentro de las limitaciones declaradas del artículo.RFC 1631, mayo de 1994, secciones 3 y 4, páginas 6-9

IPv6 cambió el denominador arquitectónico. RFC 1883, una especificación en vía de estándar publicada en diciembre de 1995, aumentó el tamaño de la dirección IP de 32 a 128 bits. No reemplazó a los hosts IPv4 instalados, enrutadores, aplicaciones o procedimientos operativos en el momento de la publicación. Para un registro que manejaba una solicitud IPv4 en 1996, IPv6 era un sucesor especificado, no evidencia de que el problema inmediato de asignación IPv4 hubiera desaparecido.RFC 1883, diciembre de 1995, estado y sección 1, páginas 1 y 3

La recuperación también tuvo etapas. RFC 2050 recomendaba la devolución de direcciones derivadas del proveedor después de terminar la conectividad y autorizaba la invalidación en circunstancias específicas. No contenía un conjunto de datos de bloques recuperados ni establecía con qué facilidad las redes operativas podían cederlos. La recuperación era un mecanismo autorizado, no una respuesta de oferta medida.

La mejora del hardware siguió siendo una posibilidad condicional. RFC 2050 afirmó que las restricciones de direccionamiento reflejaban la tecnología de enrutadores, la práctica de asignación y la historia arquitectónica. El documento informó de una conclusión de sus autores, el grupo de trabajo del IETF revisor y el IESG de que ninguna otra tecnología desplegable en ese momento superaba esas limitaciones, al tiempo que permitía una revisión si más tarde los enrutadores manejaban tablas más grandes y dinámicas o la agregación se volvía posible por otros medios. Esa es una evaluación institucional contemporánea de la tecnología, no un punto de referencia de cada enrutador y no una prueba de que los parámetros de previsión, auditoría y apelación acompañantes fueran institucionalmente únicos.RFC 2050, Introducción, página 2

RFC 2050 representó la práctica sin recibir un respaldo de política

El rol institucional importa porque “el IETF decidió” colapsaría varios actos diferentes.

RFC 2050 fue BCP 12, publicado en noviembre de 1996, y redactado por Kim Hubbard, Mark Kosters, David Conrad, Daniel Karrenberg y Jon Postel. Su resumen describía las políticas entonces utilizadas por los registros regionales para implementar las directrices desarrolladas por IANA y decía que las reglas seguían sujetas a revisión.RFC 2050, portada, resumen e Introducción, páginas 1-2

La nota del IESG fue deliberadamente más limitada que un respaldo. Al aprobar el documento como Mejor Práctica Actual, el IESG dijo que creía que la política representaba con precisión la práctica actual de los registros. Retuvo expresamente el respaldo o recomendación de la política y programó una reconsideración a la luz de discusiones adicionales del grupo de trabajo. La aprobación de la precisión descriptiva, la redacción del texto, el desarrollo de directrices de registro, la implementación por los registros y el asesoramiento de un grupo de trabajo fueron roles institucionales separados.

El RFC presentaba la conservación, la enrutabilidad y el registro como tres objetivos. También reconocía el conflicto entre esos objetivos y con los intereses de los usuarios finales y los proveedores. La conservación favorecía un ajuste estrecho de la oferta a la necesidad demostrada. La enrutabilidad favorecía una distribución jerárquica y sensible a la topología. El registro favorecía registros precisos de las asignaciones. Una concesión optimizada para un objetivo podía funcionar mal contra otro: una pequeña asignación directa podía conservar volumen de direcciones pero añadir una ruta; un bloque de proveedor podía agregar bien pero imponer la renumeración; una verificación extensa podía mejorar los registros pero aumentar el coste de transacción.

Este reconocimiento es la contraevidencia interna más fuerte contra una explicación simplista de burocracia arbitraria. Los autores reconocieron un problema de ingeniería multiobjetivo y pidieron un juicio cuidadoso. El registro apoya tomar ese problema en serio. No convierte cada umbral o remedio institucional en una consecuencia necesaria de la cabecera.

La defensa de ingeniería más sólida sobrevive a la auditoría

Un juicio justo comienza con el peligro de una sobreasignación irreversible. Una vez que las direcciones entraban en las configuraciones de enrutadores, DNS, reglas de acceso, configuraciones de aplicaciones, sistemas de clientes y documentación, la recuperación se volvía costosa. No se podía asumir que una concesión grande y optimista volviera limpiamente después de que las previsiones fallaran. Las asignaciones iniciales más pequeñas limitaban esa exposición.

El inicio lento abordó la asimetría de información. Un nuevo proveedor conocía su plan de negocio mejor que un registro, pero ninguna de las partes podía observar la demanda futura de clientes. El proceso de RFC 2050 utilizaba requisitos inmediatos, asignaciones aguas abajo verificadas y solicitudes repetidas para reemplazar parte de la incertidumbre de la previsión con un historial administrativo observado. Eso podía conservar el fondo y mejorar la precisión del registro.

La asignación sin clase corrigió un desajuste de tamaño grave. La elección entre 254 y 65.534 identificadores ordinarios se adaptaba mal a redes de tamaño medio. Los prefijos contiguos podían aproximarse más a la necesidad que una Clase B nativa, evitando una colección arbitraria de Clase C no relacionadas.

La agregación abordó un recurso compartido separado. Las observaciones de rutas de enero y diciembre de 1992, a pesar de la previsión a dos años no reconciliada del RFC, mostraron un rápido crecimiento en una tabla concreta proveniente de MERIT. Los agregados de proveedor podían reducir el número de destinos que los enrutadores sin defecto transportaban. La ganancia dependía de la topología, el software y la cooperación, pero era técnicamente sustantiva.

La jerarquía de proveedores se derivó de esa lógica de agregación. Si un cliente usaba direcciones extraídas del bloque de su proveedor, el resto de Internet a menudo podía confiar en el agregado del proveedor. El espacio portátil reducía la dependencia de un proveedor pero podía requerir una ruta global distinta. La red más amplia, no solo el cliente y el registro, soportaba el estado asociado a esa ruta.

La documentación también servía para más que la conservación. Los registros de asignación apoyaban la contactabilidad, el DNS inverso, la evitación de concesiones duplicadas y la verificación del uso aguas abajo. Un solicitante que solicitaba capacidad adicional poseía información que el registro no tenía. Por tanto, cierta revisión era racional incluso si cada detalle de procedimiento era cuestionable.

La autoridad de excepción podía evitar que una regla numérica derrotara su propósito de ingeniería. El multihoming, una topología inusual, limitaciones de equipo o un gran requisito directo podían hacer que un bloque por defecto fuera inadecuado. El tratamiento caso por caso permitía al registro acomodar circunstancias que un solo porcentaje de hosts no podía capturar.

Estas consideraciones establecen un caso de ingeniería serio para la conservación, la agregación, el registro, el inicio lento y el juicio cuidadoso. Un sistema plano de grandes concesiones incondicionales podría haber consumido más rápido las escasas unidades con clase. Un sistema plano de pequeñas concesiones enrutadas independientemente podría haber expandido las tablas sin defecto. Un sistema sin reglas habría dificultado la asignación duplicada y la evaluación de necesidades comparables.

La defensa no establece la unicidad institucional. No muestra que 24 meses fuera el horizonte de previsión óptimo, que el período de reposición del ISP de RFC 2050 minimizara el coste combinado de registro y solicitante, que un solo registro regional fuera la única estructura viable, o que la apelación jerárquica fuera superior a una revisión parcialmente independiente. La evidencia de ingeniería apoya los objetivos y algunos mecanismos. Se requerirían datos de solicitantes, enrutamiento, personal y resultados para clasificar los diseños completos.

Una comparación limitada de 1996 ubica la autoridad, no los resultados

Un contrafactual útil puede situarse en noviembre de 1996, cuando se publicó RFC 2050. Mantener constantes los campos de 32 bits de IPv4, los remanentes con clase y sin clase instalados de la época, las especificaciones BGP-4 entonces disponibles, los recursos limitados de los enrutadores, la demanda incierta, la renumeración costosa y la ausencia de una conversión universal inmediata a IPv6. No asumir el despliegue universal de BGP-4, NAT o direcciones privadas, porque las especificaciones citadas no miden la adopción.

Comenzar con la línea base documentada: asignación orientada al proveedor, inicio lento para nuevos ISP, capacidad adicional destinada a cubrir aproximadamente tres meses de asignaciones, pruebas de utilización para empresas finales, excepciones caso por caso, autoridad de auditoría del registro y apelación al registro principal.

Ahora variar analíticamente tres parámetros institucionales.

La primera variación cambia el intervalo de reposición. Un ISP podría recibir suficiente para seis meses en lugar de aproximadamente tres. Esta no es una propuesta histórica documentada. Es administrativamente plausible solo bajo la suposición de que el registro principal podría dimensionar un bloque contiguo más grande sin cambiar los formatos de paquete y que las previsiones del proveedor eran suficientemente creíbles. El efecto probable sobre la autoridad es menos transacciones de registro y menor dependencia de la reposición rápida. El riesgo de conservación probable es más capacidad no utilizada cuando el crecimiento falla. Sin historiales de solicitudes, errores de previsión y datos de asignación, no se puede estimar ninguna de las magnitudes.

La segunda variación mantiene el inicio lento de tres meses pero publica bandas de asignación y un calendario de evidencia estándar por adelantado. Esta también es construida por el analista. Asume que los registros poseían el personal y los sistemas de registro para mantener reglas públicas mientras protegían el material sensible del cliente. Podría reducir la incertidumbre sobre la documentación y facilitar la comparación de casos similares, pero podría invitar a una presentación estratégica en torno a los umbrales publicados y reducir la flexibilidad para redes inusuales.

La tercera variación mantiene la jerarquía técnica pero cambia la revisión. Las decisiones iniciales de asignación y auditoría permanecen con el registro; un panel no responsable de la decisión original revisa las excepciones e invalidaciones por escrito. Ninguna fuente directa muestra que tal panel se propusiera en 1996. La variación es administrativamente concebible solo si el sistema de registro pudiera nombrar revisores, compartir evidencia confidencial bajo salvaguardas y financiar un proceso adicional. Reubica parte de la autoridad de revisión sin añadir bits de dirección o cambiar la agregación de rutas.

También se puede describir una variación más amplia de asignación directa, pero sus suposiciones son más pesadas. Las organizaciones más pequeñas con un solo proveedor podrían recibir bloques regionales directos y retenerlos al cambiar de proveedor, sujeto a un prefijo mínimo acordado aceptado globalmente. Ese mínimo, el acuerdo de aceptación de rutas y la capacidad administrativa son todos parámetros analíticos, no reglas históricas recuperadas. El diseño podría reducir la renumeración del cliente pero aumentar las rutas visibles independientemente. El registro citado no prueba que los proveedores de tránsito hubieran aceptado esas rutas o que los enrutadores de la época pudieran absorber la tabla resultante.

La comparación revela dónde se sitúan los costes y la discreción. La reposición corta coloca más riesgo de transacción y calendario en el ISP mientras limita la exposición del fondo a previsiones fallidas. Las concesiones iniciales más grandes invierten parte de esa incidencia. Las bandas publicadas intercambian discreción por visibilidad de las reglas. Un revisor separado desplaza parte de la autoridad correctiva fuera de la cadena de decisión original. Una portabilidad más amplia transfiere la continuidad hacia el cliente y el coste de estado de enrutamiento hacia la red más amplia.

No puede mostrar qué variación era factible a escala, cuántas direcciones consumiría cada una, cuántas rutas generaría cada una, o cuál mejoraría el bienestar. La calibración requeriría solicitudes de solicitantes, cantidades concedidas y rechazadas, tiempos de procesamiento, errores de previsión, políticas de enrutamiento de proveedores, capacidad de enrutadores, costes de personal, resultados de renumeración, archivos de auditoría y observaciones de utilización comparables. Esos datos de entrada están ausentes.

La conclusión limitada por la evidencia es, por tanto, más estrecha: RFC 2050 no demostró por sí misma la unicidad institucional de su diseño. Documentó la práctica de registro de entonces, declaró un juicio tecnológico contemporáneo y describió reglas destinadas a reconciliar objetivos en competencia. Las variaciones analíticas identifican decisiones incrustadas en esas reglas. No prueban un desempeño superior.

Cuatro conclusiones, con diferentes niveles de confianza

El hecho arquitectónico es el más sólido. RFC 791 fijó cada campo de origen y destino IPv4 en 32 bits. El resultado fueron (2\^{32}) valores nominales por campo, no un espacio de nombres ilimitado y no 4.294.967.296 hosts públicos asignables.

Las consecuencias con clase y de enrutamiento también están bien respaldadas. Las grandes brechas entre la capacidad de hosts de Clase C y Clase B ordinarias hacían ineficientes las concesiones de tamaño medio. Múltiples Clase C podían conservar un número de red de Clase B mientras añadían rutas. La tabla MERIT de RFC 1519 documentó 4.526 rutas anunciadas en enero de 1992 y 8.561 en diciembre de 1992. Su proyección a dos años de aproximadamente 30.000 no se puede reproducir a partir de la fórmula de duplicación declarada, pero la preocupación subyacente sobre el crecimiento de rutas y la granularidad con clase no dependía solo de ese error aritmético.

Las elecciones administrativas son identificables. El RFC Informacional de Gerich recomendó previsiones de 24 meses, umbrales, divisiones geográficas, auditorías y excepciones caso por caso. Los autores de CIDR conectaron la asignación con la topología del proveedor y la agregación sin clase. Hubbard, Kosters, Conrad, Karrenberg y Postel documentaron el inicio lento, la jerarquía, las pruebas de utilización de hosts conectados, la autoridad de auditoría, la invalidación, la devolución y la apelación jerárquica de BCP 12. IANA, los registros regionales y locales, los proveedores y las redes de tránsito ocuparon diferentes roles de implementación. El IESG aceptó RFC 2050 como una representación precisa de la práctica actual, pero retuvo el respaldo de la política.

Los resultados completos siguen sin resolverse. Los registros de asignación no contienen el denominador de solicitudes. Las fuentes citadas no revelan todos los rechazos, reducciones, retiradas, orientación informal, retrasos, subsanaciones de auditoría, devoluciones, excepciones o resultados de apelación. Los datos de registro posteriores contienen fechas heredadas y rellenadas. Ningún conjunto de datos citado de la época mide el despliegue universal de BGP-4, la ocupación completa de direcciones, la carga comparable del solicitante o la contribución causal de un solo umbral a la conservación.

El titular puede soportar esas distinciones. El campo finito era técnico. La asignación con clase y el estado del enrutador crearon una presión de ingeniería real. El régimen de racionamiento fue político en el sentido limitado y guiado por la evidencia de que instituciones identificables eligieron horizontes de previsión, niveles de asignación, jerarquías, pruebas de evidencia, autoridad de excepción y remedios bajo restricciones que no dictaban una constitución administrativa completa única.

La necesidad técnica justificó la acción colectiva. No determinó, por sí misma, quién definiría la necesidad, retendría evidencia confidencial, concedería excepciones, impondría consecuencias o decidiría la apelación final.