Ahora que HTTPS está casi en todas partes, ¿qué pasa con IPv6?
Let's Encrypt se lanzó el 12 de abril de 2016 con la intención de apoyar y alentar a los sitios a habilitar HTTPS en todas partes (a veces denominado SSL en todas partes, aunque la web se está moviendo constantemente hacia TLS como el protocolo preferido). A finales de febrero de 2017, la EFF (que inició la iniciativa) estimó que la mitad de la web estaba ahora encriptada . Ciertamente no todo esto es atribuible a EFF y Let's Encrypt. Después de todo, tengo datos de mucho antes de esa fecha que indican que la mayoría de los clientes de F5 habilitaron HTTPS en los servicios orientados al cliente, en un rango del 70%. Está claro que la gente apoyaba el protocolo HTTPS antes de que la EFF lanzara sus iniciativas, pero dada la cantidad significativa de certificados* que ha emitido, la iniciativa no ha carecido de éxito mensurable.
El 11 de septiembre de 2006, la ICANN “ratificó una política global para la asignación de direcciones IPv6 por parte de la Autoridad de Números Asignados en Internet (IANA)”. Si bien el estándar en sí fue ratificado muchos años (como una década) antes, sin una política que regule la asignación de esas direcciones realmente no fue tan significativo. Pero a partir de 2006 tomamos en serio el avance hacia IPv6. Después de todo, la web estaba creciendo, la telefonía móvil estaba en pleno auge y las direcciones IPv4 disponibles estaban disminuyendo hasta convertirse en nada.
Necesitábamos IPv6 no solo por su seguridad mejorada, sino también por su espacio de direcciones ampliado que nos permitiría soportar miles de millones de dispositivos y cosas conectadas.
Y, sin embargo, la tasa de adopción es pésima. Consideremos que “la nube” nació en una época en la que IPv6 estaba disponible. Sin embargo, hubo que esperar hasta finales de 2016 para que Amazon AWS y Microsoft Azure activaran IPv6 en sus ofertas de nube para instancias de cómputo.
Esto ha llevado a algunos a lamentarse de que si podemos conseguir HTTPS casi en todas partes en tan poco tiempo, ¿por qué seguimos viendo un porcentaje tan pequeño de sitios que admiten IPv6? Google estima que el 16,06% de los usuarios tienen habilitado IPv6 (lo cual es interesante si lo comparamos con el soporte de los proveedores de servicios según el World IPv6 Launch ), pero solo el 10% de los sitios web ( según W3C Techs ) lo admiten.
Para ser justos, HTTPS no era nuevo. La EFF simplemente estaba alentando y empoderando a la gente para que posibilitaran lo que ya estaba a su alcance. El protocolo HTTPS cuenta con un buen soporte, se entiende bien y está completamente desarrollado. Quizás sería más justo compararlo con un estándar más nuevo, uno con inconvenientes similares, como la incompatibilidad con estándares anteriores, como HTTP/2.
En mayo de 2015, se ratificó una nueva versión de un estándar web incondicional: HTTP/2 . Al igual que IPv6, es incompatible con versiones anteriores. A diferencia de “SSL Everywhere”, soportar IPv6 o HTTP/2 no es simplemente una cuestión de adquirir un certificado y habilitar HTTPS en sus servidores web o infraestructura. Si bien es cierto que pasar de HTTP a HTTPS puede generar interrupciones (puede afectar la infraestructura de red) , no es el mismo nivel de interrupción que generan IPv6 o HTTP/2.
Para pasar a nuevos protocolos fundamentales se necesita un enfoque transicional que requiera apoyar tanto los antiguos como los nuevos simultáneamente hasta cierto punto en el futuro. Esto significa “pilas duales” para cada dispositivo a través del cual pueda fluir el tráfico. Este es un esfuerzo hercúleo para algunas organizaciones y una pesadilla arquitectónica para otras. Así como el software incurre en deuda técnica, las redes incurren en deuda arquitectónica, y es probable que los “pagos de intereses” sobre esa deuda arquitectónica dificulten la construcción de un caso válido para la adopción de IPv6. Después de todo, no es un requisito ni nada por el estilo. Los negocios continuarán si no soportas IPv6
¿O lo hará?
Recordemos que originalmente, HTTP/2 iba a requerir TLS/SSL. Hubo algunas quejas y al final se hizo opcional. Los desarrolladores de navegadores ignoraron esto alegremente y solo brindaron soporte para HTTP/2 sobre TLS/SSL, imponiendo efectivamente el requisito a todos. A finales de 2015, Google comenzó a priorizar los sitios con HTTPS habilitado en las clasificaciones de búsqueda. Y en 2016, Apple tomó medidas similares que exigieron que todas las aplicaciones nativas usaran App Transport Security, forzando nuevamente la transición a HTTPS.
Básicamente, los del lado del cliente han obligado a soportar HTTPS.
Para IPv6 actualmente no existe un requisito similar. Todos vimos cómo desaparecieron las direcciones IPv4, pero tuvo relativamente poco o ningún impacto. Así que nadie siente un impulso real (aún) para hacer un movimiento que potencialmente va a ser disruptivo y costoso. Pero a medida que surjan más cosas , es totalmente posible que eventualmente salgan al mercado admitiendo únicamente IPv6. Las cosas tienen factores de forma pequeños y su poder de procesamiento es limitado. Menos es más en la Internet de las cosas. Esa es una de las razones por las que muchos dispositivos IoT evitan HTTP en favor de MQTT: es más pequeño, más rápido y más eficiente que su primo web más pesado. El soporte para IPv4 e IPv6 es similar. Debido a que son incompatibles, la mayoría de los dispositivos admiten uno u otro. Y eventualmente elegirán uno y todos lucharán por apoyarlo.
Incluso si no lo hicieran, las direcciones IPv4 disponibles hoy en día podrían acomodar menos del 20% de los 20 mil millones de dispositivos que se proyecta que estarán en uso en 2020 (Gartner). IPv6 admite mucho más que las predicciones más agresivas de Cisco de 50 mil millones de dispositivos. Y eso es sólo el IoT.
La nube también es problemática porque no puede comprar suficientes direcciones IPv4 para sustentar su creciente base de clientes. Si IaaS va a crecer como se predice, los proveedores de nube deben migrar a IPv6. Lo cual sin duda está en parte detrás de la decisión de Amazon y Microsoft de tomar esa decisión.
Todo esto significa que, en algún momento, aparecerá una función forzada que requerirá compatibilidad con IPv6. Podría ser IoT o la nube misma. Podría ser la fuerza combinada explosiva y disruptiva de ambos en su negocio. De cualquier manera, vamos a tener que hacer una transición en algún momento, y siempre es mejor no apresurarse. Hemos tenido mucho tiempo para resolver los problemas con IPv6, y hoy en día hay soluciones más que suficientes en el mercado para respaldar el enfoque de doble pila para iniciar la transición. Entonces, si aún no lo ha hecho, es hora de considerar seriamente habilitar IPv6, antes de que se vea obligado a hacerlo por las necesidades de su negocio para seguir creciendo.
* Sí, podríamos analizar en profundidad la cantidad de certificados aparentemente fraudulentos y el hecho de que distribuirlos a ciegas como si fueran caramelos conlleva riesgos, pero ese es otro tema para otro día.