1. El colapso de la arquitectura con clases de 1981: por qué los octetos fijos casi rompen Internet

En septiembre de 1981, cuando Jon Postel y los pioneros de DARPA publicaron el RFC 791, conectar cuatro mil millones de dispositivos parecía una fantasía lejana. Para simplificar el enrutamiento primitivo de ARPANET, el espacio IPv4 de 32 bits se dividió a lo largo de los límites de octeto en rígidas «clases» administrativas. La frontera entre red y host quedó fijada en bytes completos: la Clase A (/8) asignaba a solo 126 entidades la colosal cifra de 16,777,214 hosts; la Clase B (/16) entregaba 65,534 hosts; y la modesta Clase C (/24) ofrecía apenas 254 hosts utilizables.

Esta taxonomía chocó frontalmente con el auge comercial de Internet a finales de los ochenta. Cualquier universidad o ISP superaba los 254 ordenadores de una Clase C, por lo que todos exigían bloques de Clase B. Para 1992, el espacio global de Clase B estaba agotado en más del 70%. Al mismo tiempo, grandes corporaciones tenían asignadas Clases A enteras usando apenas unas miles de máquinas, secuestrando millones de valiosas IPs. Peor aún: las tablas de enrutamiento global BGP crecían exponencialmente, amenazando con desbordar la memoria de los routers centrales y provocar el colapso del sistema.

2. La revolución CIDR de 1993: cómo las máscaras de bits salvaron el enrutamiento global

Al borde del colapso, el IETF introdujo en septiembre de 1993 el estándar RFC 1519: el Enrutamiento entre Dominios sin Clases (CIDR). CIDR rompió las barreras de las clases al introducir máscaras de longitud arbitraria a nivel de bits, representadas en la notación de barra diagonal (como /24, /27 o /19).

CIDR transformó las redes mediante dos mecanismos clave:

  • Superredes y agregación de rutas (Supernetting): En lugar de anunciar 256 rutas contiguas de Clase C en BGP, los routers centrales pudieron resumirlas en una sola ruta agregada /16, conteniendo drásticamente el crecimiento de las tablas globales.
  • Asignación milimétrica: Las organizaciones ya no debían elegir entre 254 o 65,534 IPs. Un proveedor podía asignar con exactitud un prefijo /20 (4,094 hosts), un /22 (1,022 hosts) o un /29 (6 hosts) para enlaces de infraestructura.

CIDR prolongó la vida útil de IPv4 durante décadas, dando tiempo al despliegue de NAT y a la maduración de IPv6.

3. Álgebra booleana en subredes: AND a nivel de bits, máscaras y reglas Wildcard invertidas

Aunque el cálculo de subredes suele intimidar, en el hardware de red (ASIC) no hay conjeturas: es puro cálculo booleano. Un router no interpreta texto como 192.168.1.1; trabaja con registros atómicos de 32 bits. Para saber si un paquete pertenece a una red local, ejecuta una operación lógica AND entre la IP destino y la máscara:

Fórmula de red: IP_Red = IP_Paquete & Máscara_Subred

Cada bit en 1 de la máscara copia el bit de la IP al identificador de red. Cuando la máscara pasa a 0, los bits de red concluyen. En contraste, la dirección de difusión (broadcast) se obtiene invirtiendo la máscara con un operador NOT y combinándola con la red mediante OR:

Fórmula de broadcast: IP_Broadcast = IP_Red | (~Máscara_Subred)

Esta máscara invertida es lo que Cisco denomina máscara Wildcard. En las ACL y en OSPF, una wildcard de 0.0.0.255 indica: «Los bits cero deben coincidir estrictamente con la red; los bits uno son comodines irrelevantes». Comprender que la wildcard es simplemente la máscara invertida desmitifica de inmediato las reglas de seguridad perimetral.

4. La realidad de las subredes Cloud VPC: por qué AWS y Azure «roban» 5 IPs en cada subred

Los libros de texto enseñan la fórmula clásica de capacidad: Hosts_Útiles = 2^(32 - N) - 2, restando red (.0) y broadcast (.255). No obstante, en nubes públicas como AWS VPC, Azure VNet y GCP, esta regla falla por completo.

En las redes virtuales en la nube, los proveedores reservan exactamente 5 direcciones IP en cada subred:

  1. .0: Dirección de red lógica (reservada según estándar RFC).
  2. .1: Router virtual de la VPC (Default Gateway del hipervisor).
  3. .2: Servidor DNS interno (ej., AmazonProvidedDNS o Azure DNS).
  4. .3: Reservada por el proveedor para expansiones y orquestación.
  5. .last (ej., .255 en /24): Dirección de broadcast reservada para protocolo.

Esto genera problemas frecuentes en Kubernetes gestionado (EKS o AKS). Un equipo que configura una subred /28 esperando 14 IPs para pods descubre que la nube ofrece solo 11 hosts utilizables (16 − 5). Un escalado horizontal de pods agota el bloque rápidamente, provocando fallos de despliegue inesperados.

5. VLSM e higiene de prefijos: prevención del agotamiento de direcciones en microservicios

El uso de máscaras de subred de longitud variable (VLSM) representa el estándar de disciplina en ingeniería de redes. Desplegar sistemáticamente subredes /24 para todos los entornos es una mala práctica técnica. Un microservicio aislado requiere pocas IPs, mientras que una capa pública de balanceadores exige grupos holgados.

Una segmentación arquitectónica profesional se estructura jerárquicamente:

  • /28 o /29: Clústeres de microservicios, servidores bastion e interfaces de gestión (11 a 14 hosts útiles).
  • /26 o /27: Nodos de bases de datos con replicación, clústeres de caché (Redis) y pasarelas API (27 a 59 hosts).
  • /24: Nodos de Kubernetes, conexiones de clientes VPN y redes de oficinas por DHCP (251 a 254 hosts).
  • /30 o /31 (RFC 3021): Enlaces punto a punto entre routers e interconexiones dedicadas (Direct Connect), sin desperdiciar direcciones.

El dominio riguroso del cálculo binario y CIDR convierte el direccionamiento IP en una ventaja arquitectónica robusta y escalable.