Resumen

  • Spiro Stathakis creó la plataforma de pedidos de isp6 sobre EKS con ipFamily: ipv6, pero conservó subredes IPv4 /28 para la parte que aún las necesitaba.
  • Las interfaces principales de los nodos y las de los puntos de conexión de doble pila consumieron la pequeña reserva. El equipo pasó a /27 en las subredes públicas y /26 en las privadas.

El nombre del clúster sugería que IPv4 ya podía retirarse al cuarto de los trastos. Spiro Stathakis cuenta en RIPE Labs cómo isp6 llevó su plataforma de pedidos a EKS con pods IPv6 y direcciones de su propia asignación. Reservó para IPv4 subredes /28, el mínimo admitido por AWS. La infraestructura de soporte llenó ese espacio antes de que el proyecto pudiera tratarlo como un detalle residual.

Las cuentas no perdonan el entusiasmo. Un /28 contiene 16 direcciones y AWS aparta cinco en cada subred IPv4: las cuatro primeras y la última. Quedan 11 utilizables. Según Stathakis, las interfaces principales de los nodos y las de los puntos de conexión de doble pila acabaron con ese margen. El ajuste fue concreto: /27 para la parte pública y /26 para la privada. No publicó un inventario fechado de interfaces, de modo que su relato identifica el mecanismo y los nuevos tamaños, pero no el consumo exacto de cada subred hoy.

EKS documenta el límite de su propia etiqueta IPv6. Pods y servicios usan IPv6; un pod que necesita llegar a un destino solo IPv4 obtiene además una dirección IPv4 local al nodo y sale mediante la IPv4 principal de este. Esa compatibilidad evita que una dependencia antigua rompa la aplicación. También permite que el tráfico siga usando la vía heredada sin que el nombre del clúster lo delate. La familia de direcciones se elige al crear EKS y después no se puede cambiar.

Stathakis mantuvo una pasarela NAT para destinos IPv4. Para ciertos puntos de conexión AWS de doble pila, su equipo permitió únicamente IPv6 en el puerto 443, de forma que una aplicación que eligiera un registro A fallase en vez de tomar IPv4 a escondidas. Los registros de flujo NAT mostraron qué dependencias seguían pasando por allí. Una muestra fechada de esos registros junto con la lista de interfaces diría cuánto IPv4 continúa haciendo trabajo real.

La anécdota no es una derrota de IPv6. Es un balance de quién decide dónde termina la transición. isp6 eligió IPv6 para los pods; el proveedor de nube y las dependencias conservaron sus propias necesidades de IPv4. El /28 era la intención. Las interfaces llevaron la contabilidad.