¿Qué historia hay detrás de las famosas máscaras de red?
22/01/2025
Por Alejandro Acosta, Coordinador I+D en LACNIC
Introducción
¿Recuerdas cuando estabas aprendiendo de máscaras de red? Seguro llegaste a pensar: “no sirven para nada”, “no las voy a necesitar”, “¿por qué inventaron esta locura?”. Además de sacarte una sonrisa espero convencerte de la enorme importancia que tienen en el gigantesco ecosistema de Internet.
Objetivo
Este blog post resume la historia y los hitos relacionados detrás de los conceptos de máscara de red en el mundo de IPv4. Comenzamos la historia en un mundo donde no existían las clases (plano-flat), pasamos por un mundo classful y finalizamos en un Internet totalmente classless (CIDR). La información se basa en extractos de los RFC 790, 1338 y 1519, junto con hilos de correo electrónico de la lista de correo ‘Internet-history’.
¿Sabes lo que es la máscara de red?
Asumo que si llegaste a este documento si lo sabes :-) pero aquí va un mini concepto: una máscara de red se utiliza para ubicar y dividir un espacio de dirección de red y una dirección de host, en otras palabras, indica al sistema cuál es el esquema de particionamiento de subred.
¿Cuál es el propósito de la máscara de red?
Enrutamiento: Los enrutadores utilizan la máscara de red para determinar la porción de red y encaminar correctamente los paquetes.
Subnetting: Las máscaras de red se utilizan para crear redes más chicas.
Aggregation: Las máscaras de red permiten la creación de prefijos más grandes.
¿Siempre han existido las máscaras de red?
No, muy interesantemente no siempre existió la máscara de red, al comienzo las redes IP eran planas (flat) y siempre asumían 8 bits para la red y 24 bits para el host. En otras palabras, el primer octeto era la red, y los 3 octetos restantes corresponden al host. Otro aspecto llamativo es que hace muchos años también recibía el nombre de bitmask o solo mask (aún utilizado ampliamente).
Lo anterior conlleva a que no siempre existieron las clases (A, B, C, D)
Las clases no existieron hasta la aparición del RFC (septiembre 1981) de Jon Postel, es decir, incluso era una época antes de classless y classful.
La introducción del sistema classful fue impulsada por la necesidad de acomodar diferentes tamaños de red, ya que el ID de red original de 8 bits era insuficiente (256 redes). El sistema classful fue un intento de abordar las limitaciones de un espacio de direcciones plano, aunque este también tenía limitaciones de escalabilidad. En el mundo de las clases la máscara de red era implícita.
Las clases tampoco solucionaron todo
Si bien el sistema classful fue una mejora sobre el diseño original (plano), no era eficiente. Los tamaños fijos de los espacios de red y hosts de las direcciones IP llevaron al agotamiento del espacio de direcciones, especialmente con el creciente número de redes que eran más grandes que una Clase C, pero más pequeñas que una Clase B. Lo anterior llevó al desarrollo del enrutamiento Inter-Dominio Sin Clases (Classless Interdomain Routing – CIDR), que utiliza máscaras de subred de longitud variable (Variable Length Subnet Mask – VLSM).
Extracto del RFC 790
¿Sabías que no siempre la máscara se escribió con bits continuos encendidos de izquierda a derecha?
Al comienzo en la máscara de red no debía “encenderse” bit a bit de izquierda a derecha, es decir, mascaradas como: 255.255.192.128 era completamente válidas. Esta configuración era aceptada por routers (IMPs -los primeros routers-) y diferentes sistemas operativos, entre ellos los BSDs y SunOSs antiguos. Es decir, hasta comienzos de los 90’s aún era posible tener máscaras de red de bits no continuos.
¿Por qué se decidió que los bits luego fueran obligatoriamente encendidos de izquierda a derecha?
Existieron varias razones, la principal tiene que ver con enrutamiento y el famoso concepto “longest match” que conocemos donde el router selecciona la ruta cuya máscara de subred sea la más larga que coincida con la dirección de destino del paquete. Es decir, si los bits no son continuos se crea una complejidad computacional muy alta. En resumen: eficiencia.
Desde esa época ya se agotaban direcciones IPv4
El agotamiento de recursos IPv4 no es algo nuevo, incluso en la primera sección del RFC 1338 en su numeral uno hace referencia al agotamiento de la Clase B indicando que la Clase C es demasiado pequeña para muchas organizaciones, y la Clase B es demasiado grande. Esto ocasionó una presión sobre el espacio de direcciones Clase B, agotando la misma. Y no solo eso, el mismo RFC en el numeral 3 cita textualmente: “Eventual exhaustion of the 32-bit IP address space” (1992).
CIDR aborda las soluciones de ayer, que se convirtieron en los problemas de ese momento
Al momento de crear las clases se crearon más redes lo que conlleva a más prefijos y a su vez mayor consumo de memoria y CPU. Por ello en septiembre de 1993 en el RFC 1519 apareció el concepto de CIDR, trayendo consigo soluciones a algunas situaciones, entre ellas, poder hacer supernetting (es decir, poder apagar bits de derecha a izquierda) e intentar reducir la cantidad de prefijos de red. Es importante destacar que el RFC 1338 también mantuvo conceptos similares.
Finalmente, la notación de prefijo (/nn) también aparece gracias a CIDR lo que se hace posible una vez más gracias a la continuidad de los bits encendidos y apagados de la máscara de red.
En resumen, el objetivo de CIDR era enlentecer el crecimiento de las tablas de enrutamiento y buscar ser más eficientes en la utilización del espacio de direcciones IP.
Timeline
Conclusiones
El concepto de máscara de red ha evolucionado notablemente desde su origen, desde su no-existencia en un esquema plano (flat), luego rígido a un modelo flexible con CIDR. Inicialmente, las redes classful y las máscaras discontinuas generaban ineficiencia y problemas de escalabilidad a medida que Internet crecía.
Un cambio clave fue la exigencia de continuidad en los bits encendidos, lo que simplificó el proceso de selección de rutas y permitió a los routers operar más eficientemente.
Este documento informativo resalta los hitos clave y las motivaciones detrás de la evolución del direccionamiento IP y enfatiza la importancia de comprender el contexto histórico para apreciar plenamente la arquitectura actual de Internet.
Referencias
- RFC https://datatracker.ietf.org/doc/html/rfc1338
- RFC https://datatracker.ietf.org/doc/html/rfc1380
- RFC https://datatracker.ietf.org/doc/html/rfc1519
- RFC https://datatracker.ietf.org/doc/html/rfc790
- Hilo de la lista de correo de ISOC “Internet History” llamado “The netmask”: https://elists.isoc.org/pipermail/internet-history/2025-January/010060.html
Las opiniones expresadas por los autores de este blog son propias y no necesariamente reflejan las opiniones de LACNIC.