El problema de las claves de API que nunca caducan
Una clave emitida hace años, que nunca se ha rotado y que hoy sigue siendo válida, no es una comodidad. Es un riesgo que nadie ha revisado de verdad en años.
En qué sigue fallando este sector con la adopción de IPv6
IPv6 lleva disponible el tiempo suficiente como para que tratarlo como algo secundario ya no sea un atajo de ingeniería razonable, y aun así muchas herramientas relacionadas con IP se siguen comportando como si IPv4 fuera el tráfico real e IPv6 la excepción que se gestiona si sobra tiempo. Esto se nota en detalles pequeños: una lógica de límite de frecuencia escrita en torno a bloques de direcciones al estilo IPv4 sin un concepto equivalente y bien pensado para IPv6, o una documentación que da por hecho sin decirlo un formato de dirección IPv4 en sus ejemplos y deja la gestión de IPv6 como un añadido implícito.
Diseñamos deliberadamente el control de cuotas a nivel de red en torno a ambas familias de direcciones, no como un parche de IPv6 añadido a una lógica pensada primero para IPv4. Cada red recibe una cuota gratuita compartida, un bloque /24 para las direcciones IPv4 y un bloque /48 para las direcciones IPv6, y ambos se tratan como agrupaciones de primera clase, en lugar de que uno sea el diseño principal y el otro una adaptación. La diferencia entre un /24 y un /48 no es arbitraria. Refleja cómo asignan realmente cada familia de direcciones los registros regionales de internet responsables de repartir los bloques, de modo que la agrupación significa lo mismo en la práctica, una red de tamaño razonable, en ambos casos.
Equivocarse en esto importa especialmente en una API de datos de ubicación e IP, porque toda la categoría de consultas a nivel de red y basadas en IP depende de analizar, cotejar y limitar la frecuencia correctamente en ambos formatos de dirección. Una API que trata IPv6 discretamente como un caso límite tiene más probabilidades de producir un comportamiento de cuota incoherente, agrupaciones de red incorrectas o directamente fallos de análisis con el tráfico IPv6, justo cuando la adopción de IPv6 sigue creciendo y una parte significativa de las solicitudes reales llega por IPv6 en lugar de por IPv4.
Parte de la razón por la que el sector en su conjunto invierte poco en esto es que el tráfico IPv4 sigue representando una gran parte del volumen total de muchos servicios, lo que hace que los casos límite de IPv6 parezcan poco prioritarios en relación con el esfuerzo de resolverlos bien de verdad. Creemos que ese razonamiento subestima demasiado la tendencia. Una parte del tráfico que no deja de crecer no queda bien atendida por una infraestructura que la trata como una minoría permanente, y el coste de arreglar correctamente la gestión de IPv6 no hace más que crecer cuanto más tiempo se construye la lógica central de un sistema dando por hecho que IPv4 es lo predeterminado.
Nada de esto es una afirmación dramática. Es una petición para tomarse IPv6 tan en serio como IPv4 en el diseño real del límite de frecuencia, el control de cuotas y la lógica de consulta, no solo en una casilla de cumplimiento que dice que una API técnicamente acepta direcciones IPv6 sin un error de sintaxis. Aceptar un formato de dirección y gestionarlo con el mismo cuidado que el más común son logros distintos, y gran parte de la infraestructura de este sector solo ha conseguido realmente el primero.