¿Por qué el IETF eligió específicamente 192.168 / 16 para ser una clase de dirección IP privada?

Por qué el Grupo de Trabajo de Ingeniería de Internet (IETF) elige 192.168/16 ¿Ser una clase de dirección IP privada y no otra cosa?

¿Por qué específicamente 192.168/16 y 10/8 y 172.16/12 y no 145.243/16 ¿por ejemplo?

¿Hay alguna razón por la que esas direcciones IP hayan sido elegidas para ser el estándar para las direcciones IP privadas sobre todas las demás posibilidades?

Sé quién eligió estos rangos de direcciones. Desafortunadamente, él está muerto, así que no puedo preguntarle exactamente por qué Él los eligió, pero puedo hacer algunas suposiciones bien informadas.

No hay muchas citas en línea antes de mediados de los 90, cuando Internet comenzó a despegar. ¿Qué historia de Internet existe es principalmente en el RFCs que lo definen, que se remontan a 1969 , al inicio de la ARPANET. A través de ellos, puede ver el progreso de Internet desde una red incipiente de unos cuantos mainframes primitivos, diseñados por algunas de las mentes más brillantes de la época, hasta la red en la que difícilmente podemos imaginar vivir sin el presente.

Esta respuesta se basa casi en su totalidad en esos RFC, y en pequeña parte de mi experiencia personal como lo estaba en Internet en esta era.

Primero, el IETF no seleccionó estos rangos de direcciones IP, ni ningún otro. Asignación de direcciones de uso especial. es actualmente y siempre ha sido el trabajo del Autoridad de asignación de números de Internet .

La IANA siempre ha sido una papel , en lugar de una organización específica, y ese rol ha cambiado de manos exactamente una vez. Actualmente está en manos de la ICANN, pero desde 1972 hasta su muerte en 1998 cuando esa organización fue creada para reemplazarlo, la IANA era esencialmente un solo hombre, Jon Postel . Por supuesto, primero llamó al papel. zar de números de socket , una tarea necesaria que se hizo a sí mismo porque era necesario hacerlo. Acabó con el zar de prácticamente todos los números que podían asignarse: direcciones, números de protocolo, puertos, nombre, en gran parte porque estaba dispuesto a hacerlo, y en el momento en que Internet abierto al comercio público Lo había estado haciendo durante más de 20 años. Asignó los números, y la Registro de internet (entonces SRI-NIC, esto era expandido a un colección distribuida de registros En todo el mundo) los publicaron.

El último RFC de SRI que muestra una lista de asignaciones de direcciones de Internet fue RFC 1166 desde 1990. Es una lista muy larga, por lo que no debe sorprender que estos datos se hayan trasladado a bases de datos en línea. Comparándolo con su antecesor 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 entender los rangos de direcciones en RFC 1918 un poco mejor. Esta es en realidad la segunda revisión de la RFC; el primero fue RFC 1597 , publicado casi dos años antes en marzo de 1994. En su poco conocida refutación, RFC 1627 Se expusieron los argumentos contemporáneos contra los espacios de direcciones privadas. 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 la queja en RFC 1627 es creíble, lo hizo a través de canales de retorno en lugar de los procesos abiertos habituales. Puede ver que el propio RFC 1597 pasó directamente al estado RFC sin el usual anterior Damas de Internet , por lo que también fue aprobado a través de canales posteriores, de nuevo por Postel, que también era editor de RFC en ese momento . Por lo tanto, tal vez nunca sea posible responder esta pregunta de manera concluyente.

Ahora, por qué eligió estos tres rangos de direcciones, permítame devolverle su atención a los RFC 1166 y 1117 de SRI, que tenían las asignaciones de rango de direcciones IP actuales en ese momento. En ambos notarán que la red 10 todavía estaba asignada a la difunto ARPANET, que tenía cerrado en 1990 . Postel, en su papel de IANA, sabría que este rango ya no estaba en uso y podría ser reasignado. Yo postulo que Postel escogió 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 hizo la elección, era la siguiente red disponible, o casi la siguiente disponible, que se asignaría desde el espacio de Clase C anterior. Es probable que esto no se pueda probar de una manera u otra, pero el ritmo de las asignaciones de direcciones que se muestran en las RFC sugiere fuertemente que habrían estado en esta vecindad general alrededor de 1993-1994 cuando se realizaron las asignaciones. (Se estaban asignando direcciones en 192.159 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 a 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 alcanzado ese nivel, por lo que puedo descubrir. Solo puedo especular que la IANA arrojó un dardo a un tablero de dardos, lanzó un dado o sacó el número de sus regiones inferiores.

Finalmente, una nota sobre Jon Postel. A pesar de la forma aparente en que se realizó este RFC completamente formado sin aportes (iniciales) de la comunidad, no quiero dar a entender que, y esto no debe interpretarse como, Jon Postel de alguna manera ejecutó el papel de la IANA de manera deficiente o injusta. Fue una de las influencias más fuertes en la Internet temprana, y aún sientes esa influencia hoy en día cada vez que vislumbras la maquinaria detrás de escena de Internet, pero siempre le preocupó hacer el trabajo correctamente. Para citar de un recuerdo :

No hay gloria en hacer administración y operaciones. Todo lo contrario. Las personas notan cuando se hace mal, pero rara vez elogian cuando se hace bien. Las personas en puestos administrativos a menudo se convierten en burócratas de poca monta. Ya que hay tan poca recompensa en el trabajo, lo convierten artificialmente en una base de poder. Así que ha confundido a algunos que escucharon a Jon referirse como los números de Internet "zar". No se dieron cuenta de que la comunidad impartió el título a Jon por afecto y profunda apreciación por haber ordenado servicios de infraestructura esenciales. En particular, la comunidad utilizó ese término con pleno conocimiento de que Jon tomó su posición como un fideicomiso, en lugar de una oportunidad para el poder personal. Siempre supimos que sus opiniones provenían de creencias legítimas y nunca tuvimos que preocuparnos de que de alguna manera considerara una ventaja política o personal. Puede que no estemos de acuerdo con él, pero siempre supimos que fue motivado primero por la preocupación de que se debe hacer lo correcto.

¿Porque tenía sentido en ese momento? :-RE

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 la misma capacidad de CPU y almacenamiento de RAM que las calculadoras gráficas de bolsillo de hoy, y de los que hoy todavía funcionan en círculos alrededor de los enrutadores de años anteriores (recuerdo cuando la velocidad de la CPU se medía en kilohertz y el almacenamiento de RAM se medía en kilobytes, ¡no los giga * como son hoy!). El Internet estaba creciendo rápidamente, el IPv4 el espacio de direcciones era limitado, y parecía que se iba a agotar para el año 2000 o algo así, etcétera. Por lo tanto, muchos rangos de direcciones IP ya estaban asignados, y no querían tener que pedir a las compañías que devolvieran los rangos de direcciones IP solo para poder reasignarlos a rangos privados. También querían intentar que las compañías trabajen con los rangos privados de la forma más fácil posible; pocas compañías habrían cooperado si hubieran tenido que invertir mucho dinero para hacer que sus redes funcionen con una o dos docenas de rangos / IP Direcciones aquí y allá.

Esta parte es ciertamente una conjetura por mi parte, pero se basa en gran medida tanto en la lógica como en la experiencia en la configuració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 fueron Clase A), 16 Clase B (números de red 10xxxxxx binario) y 256 direcciones de Clase C (números de red 110xxxx binario). Las direcciones de Clase B y C deben ser todas consecutivo , también. (La elección para 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 se pudo encontrar. disponible por reserva.)

De esto, probablemente seleccionaron los rangos finales de aquellas 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 / soltar el paquete. También hay algunas propiedades de los patrones de bits que puedo ver para ayudar a construir tablas NAT compactas. La dirección 10.x.y.z es obvia, ya que solo tiene que coincidir con un número de red. El 172.16.yz al 172.32.yz tiene el patrón de que si se construye una tabla con los cuatro bits de orden inferior que se refieren a los cuatro bits de orden superior, el rango completo 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.y.z, el binario para 168 es 10101000, es decir, los tres bits más bajos siempre son 0, y los 5 bits más altos alternan 1 y 0.

Si bien esto puede parecer arbitrario, si alguna vez ha realizado alguna programación en lenguaje de máquina o descodificación de microcódigo, este tipo de patrones le permite probar solo unos pocos bits para hacer una determinación privada / pública sin tener que descodificar 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 empujar un paquete de red privada a la red privada sin descodificarlo primero, reduciendo los preciados ciclos de la velocidad del enrutador y la red.

Si tiene curiosidad, mire 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 tiempo tratar de calcular cosas como la paridad en un byte completo a la vez, así 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 "hacer el trabajo al mismo tiempo que estás haciendo otra cosa", en el caso de un chip en serie, se calcula la paridad al mismo tiempo que se envía / recibe. Para un enrutador / conmutador, puede obtener un mayor rendimiento si ya está decodificando la dirección IP a medida que cada bit de la dirección proviene del cable, y posiblemente ya sepa dónde enviar el paquete antes de que haya terminado de leerse desde la red. ¡cable!

Además, esto ES solo lógica / conjetura de mi parte, basada 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 documento / RFC / etc. siempre dando la razó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 el Internet primordial , la red ahora denotada 10.0.0.0/8 fue asignada a la ARPANET . En el momento en que el IETF y la IANA comenzaron a asignar rangos de direcciones privadas, ARPANET estaba inactivo y su espacio de direcciones anterior 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 mencionada anteriormente.

Porque 192 comienza con 11xxxxxx en binario, lo que indica un clase C red. Es el número más bajo que comienza con dos 1 consecutivos. La clase A tiene 0 como su (s) bit (s) de orden más alto, y la clase B tiene 10.

RFC 1918 que define los rangos de IP privados, no aclara este punto, por lo que no hay una respuesta definitiva sobre por qué eligieron .168 para el bloque de 16 bits, pero creo que esto se debió a que el RFC no se lanzó hasta 1996, después de una gran número de registros ya se han llevado a cabo. Debido a que 192 es el primer bloque de 8 bits en las asignaciones de clase C, es probable que ya se hayan tomado muchas de las direcciones. 168 puede haber sido el primero disponible.

También tenga en cuenta que algunas de estas opciones son arbitrarias. Tenga en cuenta que el rango rfc1918 clase B es 172.16 - 172.31? No puedo pensar en la razón de 172, pero estoy bastante seguro de que eligieron usar 16 clases B, por lo que tenían un bloque de 1 millón de direcciones contiguas (1048576).

A veces los protocolos son así. alguien tenía que hacer una elección, y lo hicieron. por un tiempo, el kernel de Linux se limitó a un máximo de 1024 CPU por sistema, y ​​finalmente tuvieron que emitir un parche, después de que algunos supercomputadores tuvieran problemas. quien haya decidido usar 1024 probablemente no tenía una buena razón para hacerlo, aparte de que necesitaba un valor, y 1024 es agradable y redondo.

Este es un remanente de Redes de clase , donde el rango de direcciones IPv4 fue subdividido en clases:

• Clase A: 0.0.0.0 - 127.255.255.255 / 255.0.0.0
• Clase B: 128.0.0.0 - 191.255.255.255 / 255.255.0.0
• Clase C: 192.0.0.0 - 223.255.255.255 / 255.255.255.0
• Clase D: 224.0.0.0 - 239.255.255.255 (multidifusión)
• Clase E: 240.0.0.0 - 255.255.255.255 (reservado)

Desde entonces hemos pasado (en 1993) a itinerario entre recesos , sin embargo, las clases todavía tienen su legado en varios lugares (la red 127 es "home / loopback" - 127.0.0.1 ¿alguien?). y la multidifusión sigue siendo multidifusión.

El RFC explica la razón por la que elegimos tres rangos de "Clase A, B & amp; C "respectivamente: CIDR había sido especificado pero no había sido ampliamente implementado. Había una cantidad significativa de equipo por ahí que Todavía estaba "classful".

Por lo que recuerdo la elección de los rangos en particular fue la siguiente:

8/10: el ARPANET acababa de ser apagado. Uno de nosotros lo sugirió y Jon consideró esto como una buena reutilización de este bloque de direcciones "histórico". Nosotros También sospeché que "net 10" podría haber sido codificado en algunos lugares, reutilizándolo para el espacio de direcciones privado en lugar de en el enrutamiento inter-AS Podría tener la ligera ventaja de mantener tal tontería local.

172.16 / 12: el menor sin asignar / 12 en el espacio de clase B.

192.168 / 16: el más bajo sin asignar / 16 en el bloque de clase C 192/8.

En resumen: la IANA asignó este espacio como lo haría para cualquier otro propósito Como la IANA, Jon era muy consistente a menos que hubiera una Muy buena razón para ser creativo.

Daniel (coautor de RFC1918)