Solución:
Sé quién eligió estos rangos de direcciones. Desafortunadamente, está muerto, así que no puedo preguntarle exactamente. por qué los eligió, pero puedo hacer algunas conjeturas bien informadas.
No hay muchas citas en línea antes de mediados de la década de 1990, cuando Internet realmente comenzó a despegar. La historia de Internet que existe se encuentra principalmente en las RFC que la definen, que se remontan a 1969, al comienzo de ARPANET. A través de ellos, puede ver el progreso de Internet desde una red incipiente de unos pocos mainframes primitivos, diseñada por algunas de las mentes más brillantes de la época, a la red sin la que difícilmente podemos imaginar vivir hoy.
Esta respuesta se basa casi en su totalidad en esos RFC, y en una pequeña parte de mi experiencia personal mientras navegaba por Internet en esta era.
Primero, el IETF no seleccionó estos rangos de direcciones IP ni ningún otro. La asignación de direcciones de uso especial es actualmente y siempre ha sido el trabajo de la Autoridad de Números Asignados de Internet.
La IANA siempre ha sido un papel, en lugar de una organización específica, y ese rol ha cambiado de manos exactamente una vez. Actualmente está en manos de ICANN, pero desde 1972 hasta su muerte en 1998, cuando se creó esa organización para reemplazarlo, IANA fue esencialmente un hombre, Jon Postel. Por supuesto, primero llamó al papel zar de los números de socket, una tarea necesaria que asumió él mismo porque necesitaba hacerse. Terminó siendo el zar de prácticamente todos los números que se podían asignar: direcciones, números de protocolo, puertos, lo que sea, en gran parte porque estaba dispuesto a hacerlo, y cuando Internet se abrió al comercio público, lo había estado haciendo durante más de 20 años. Asignó los números y el Registro de Internet (entonces SRI-NIC, que se expandió a una colección distribuida de registros en todo el mundo) los publicó.
El último RFC de SRI que muestra una lista de asignaciones de direcciones de Internet fue el RFC 1166 de 1990. Es una lista muy larga, por lo que no debería sorprender que estos datos se hayan trasladado a bases de datos en línea. Comparándolo con su predecesor, el RFC 1117 muestra la tasa de expansión de Internet incluso entonces, años antes de que se abriera al público.
Entonces, ahora estamos en condiciones de comprender un poco mejor los rangos de direcciones en RFC 1918. Esta es en realidad la segunda revisión del RFC; el primero fue RFC 1597, publicado casi dos años antes en marzo de 1994. En su refutación poco conocida, RFC 1627, se expusieron los argumentos contemporáneos contra los espacios de direcciones privados. El RFC 1627 también menciona quién asignó los tres espacios de direcciones.
Fueron asignados por IANA, es decir, Jon Postel, a solicitud de los autores de RFC 1597, y si se debe creer en la denuncia en RFC 1627, lo hizo a través de canales secundarios en lugar de los habituales procesos abiertos. Puede ver que RFC 1597 pasó directamente al estado RFC sin los borradores de Internet anteriores habituales, por lo que también fue aprobado a través de canales secundarios, nuevamente por Postel, que también era editor de RFC en ese momento. Por lo tanto, es posible que nunca sea posible responder a esta pregunta de manera concluyente.
Ahora, en cuanto a por qué eligió estos tres rangos de direcciones, permítanme devolver su atención a los RFC 1166 y 1117 de SRI, que tenían las asignaciones de rango de direcciones IP vigentes en ese momento. En ambos observará que la red 10 todavía estaba asignada a la desaparecida ARPANET, que se había cerrado en 1990. Postel, en su papel de IANA, sabría que este rango ya no estaba en uso y podría reasignarse. Postulo que Postel eligió la red 10 porque sabía que estaba disponible y no estaba en uso.
De manera similar, espero que Postel eligió 192.168 porque, en el momento en que tomó la decisión, era la siguiente red disponible, o casi la siguiente disponible, que se asignará desde el antiguo espacio de Clase C. Esto probablemente no se pueda probar de una forma u otra, pero el ritmo de las asignaciones de direcciones que se muestra en las RFC sugiere fuertemente que habrían estado en esta vecindad general alrededor de 1993-1994 cuando se hicieron las asignaciones. (Las direcciones en 192.159 se asignaron en 1992. No hay fechas disponibles para las asignaciones en 192.160-192.167 ya que en algún momento se reasignaron a RIPE).
Responder esta pregunta para 172.16-172.31 es más difícil. Nada de lo que pude encontrar sugiere por qué se seleccionó este rango. Las asignaciones en el antiguo espacio de Clase B aún no habían llegado tan alto, por lo que puedo descubrir. Solo puedo especular que IANA lanzó un dardo a un tablero de dardos, lanzó dados o sacó el número de sus regiones inferiores.
Finalmente, una nota sobre Jon Postel. A pesar de la forma aparente en la que este RFC se llevó a cabo por completo sin el aporte (inicial) de la comunidad, no quiero dar a entender eso, y esto no debe interpretarse como que Jon Postel de alguna manera ejecutó el papel de la IANA de manera deficiente o injusta. Él fue una de las influencias más fuertes en los inicios de Internet, y todavía se siente esa influencia cada vez que se vislumbra la maquinaria detrás de escena de Internet, pero él siempre se preocupó por hacer bien el trabajo. Para citar un recuerdo:
No hay gloria en hacer administración y operaciones. Todo lo contrario. La gente nota cuando se hace mal, pero rara vez elogia cuando se hace bien. Las personas que ocupan puestos administrativos a menudo se convierten en pequeños burócratas. Dado que hay tan poca recompensa en el trabajo, artificialmente lo convierten en una base de poder. Así que ha confundido a algunos que escucharon a Jon referirse como el “zar” de los números de Internet. No se dieron cuenta de que la comunidad le otorgó el título a Jon por afecto y profundo agradecimiento por haber puesto orden en los servicios esenciales de infraestructura. En particular, la comunidad usó ese término con pleno conocimiento de que Jon tomó su posición como un fideicomiso, más que como una oportunidad de poder personal. Siempre supimos que sus puntos de vista provenían de creencias legítimas y nunca tuvimos que preocuparnos de que de alguna manera estuviera considerando una ventaja política o personal. Puede que no estemos de acuerdo con él, pero siempre supimos que lo primero que nos impulsaba era la preocupación de que se hiciera lo correcto.
¿Porque tenía sentido en ese momento? 😀
Recuerde, cuando se asignaron los rangos de direcciones IP privadas, hubo varios problemas con los que los ingenieros de red tuvieron que lidiar: algunos de los enrutadores más poderosos en ese momento tenían tanta potencia de CPU y almacenamiento de RAM como las calculadoras gráficas de bolsillo de hoy en día, y algunos de los que hoy en día todavía corren círculos alrededor de los enrutadores de antaño (recuerdo cuando la velocidad de la CPU se medía en kilohercios y el almacenamiento de RAM se medía en kilobytes, ¡no los giga * como son hoy!). Internet estaba creciendo rápidamente, el espacio de direcciones IPv4 era limitado y parecía que se iba a acabar en el año 2000, etcétera. Por lo tanto, ya se habían asignado muchos rangos de direcciones IP y no querían tener que pedir a las empresas que devolvieran los rangos de direcciones IP solo para poder reasignarlos a rangos privados. También querían intentar facilitar al máximo el trabajo de las empresas con los rangos privados; pocas empresas habrían cooperado si tuvieran que invertir una gran cantidad de dinero para hacer que sus redes hicieran frente a una o dos docenas de rangos / IP. direcciones aquí y allá.
Esta parte es ciertamente una conjetura de mi parte, pero se basa en gran medida tanto en la lógica como en la experiencia en la creación de redes. Probablemente reunieron una lista de todos los números de red no asignados y buscaron un patrón distintivo que cumpliera con los criterios deseados: Una sola clase A (los números de red que tienen un bit alto de 0xxxxxxx binario en el número de red eran de Clase A), 16 de Clase B (números de red 10xxxxxx binarios) y 256 direcciones de Clase C (números de red 110xxxx binarios). Todas las direcciones de Clase B y C deben consecutivo, así como. (La elección de 16 y 256 fue probablemente parcialmente arbitraria – después de hacer esto por un tiempo, tiendes a empezar a pensar en potencias de 2 – y probablemente en parte porque fue lo que pudo encontrar lo que fue disponible para reserva.)
A partir de esto, probablemente seleccionaron los rangos finales de las direcciones disponibles que permitirían a los fabricantes de enrutadores hacer una prueba simple de bits en la dirección para determinar si enrutar / reenviar / descartar el paquete. También hay algunas propiedades de los patrones de bits que puedo ver que ayudan a construir tablas NAT compactas. La dirección 10.xyz es obvia, ya que solo tiene que coincidir con un número de red. El 172.16.yz a 172.32.yz tiene el patrón de que si crea una tabla con los cuatro bits de orden inferior que hacen referencia cruzada a los cuatro bits de orden superior, todo el rango se llena en una sola fila de la tabla, sin dividirse en dos filas. – es decir, el segundo octeto es siempre 0001xxxx (binario). En 192.168.yz, el binario de 168 es 10101000, es decir, los tres bits inferiores siempre son 0 y los 5 bits superiores alternan entre 1 y 0.
Si bien estos pueden parecer arbitrarios, si alguna vez ha realizado alguna programación en lenguaje de máquina o decodificación de microcódigo, este tipo de patrones le permiten probar solo unos pocos bits para tomar una determinación privada / pública sin tener que decodificar primero la dirección IP completa. Esto permitiría a los enrutadores procesar dichas direcciones rápidamente sin tener que mantener extensas tablas de búsqueda en la memoria. Por lo tanto, el enrutador podría enviar un paquete de red privada a la red privada sin decodificarlo completamente primero, reduciendo preciosos ciclos de reloj de la velocidad del enrutador y la red.
Si tiene curiosidad, observe cómo la transmisión de datos en serie (como un UART) maneja cada byte de datos: solo puede enviar / recibir un solo bit a la vez, a la velocidad del reloj de control, y generalmente enmarca los datos en bits adicionales como paridad y bits de “sincronización”. Sería demasiado lento intentar calcular cosas como la paridad en un byte completo a la vez, por lo que, en cambio, mantiene un bit especial en cada ciclo de reloj. Ese bit se modifica por el siguiente bit que se desplaza dentro / fuera del registro de envío / recepción. Tan pronto como se envía / recibe el byte completo, el valor que queda en el bit de paridad ya es correcto sin tener que recalcularlo. El concepto es más o menos “haz el trabajo al mismo tiempo que estás haciendo otra cosa”, en el caso de un chip en serie, calcula la paridad al mismo tiempo que envía / recibe. Para un enrutador / conmutador, puede obtener un mayor rendimiento si ya está decodificando la dirección IP ya que cada bit de la dirección proviene del cable, y posiblemente ya sepa dónde enviar el paquete a continuación antes incluso de que termine de leerse desde la red. ¡cable!
Además, esto es solo lógica / conjeturas de mi parte, basado en 25 años de hacer este tipo de trabajo. No sé si alguna vez sabremos las razones exactas detrás de los números finales elegidos, ya que no recuerdo ningún artículo / RFC / etc. dando siempre la justificación completa. Lo más cercano que he visto son solo algunos comentarios que sugieren que los rangos elegidos deberían hacer que sea relativamente fácil y eficiente para las empresas usarlos con un mínimo esfuerzo / inversión / reingeniería.
En la Internet primordial, la red ahora denominada 10.0.0.0/8 se asignó a ARPANET. Para cuando IETF e IANA empezaron a asignar rangos de direcciones privadas, ARPANET ya no existía y su antiguo espacio de direcciones estaba disponible para uso privado.
Los otros dos rangos hicieron que las redes Clase B y Clase C estuvieran disponibles para IP privadas, además de la Clase A antes mencionada.