En el campo de la implementación de IPv6 , la interrupción de IPv6 era un mal comportamiento observado en las primeras implementaciones de IPv6 en túnel o de doble pila , en las que se elegía una conectividad IPv6 poco fiable o falsa en lugar de una conectividad IPv4 que funcionara. Esto a menudo provocaba grandes retrasos en la carga de la página web , en la que el usuario tenía que esperar a que se agotara el tiempo de espera de cada intento de conexión IPv6 antes de intentar la conexión IPv4. [1] Estos tiempos de espera iban desde casi instantáneos en los mejores casos hasta demorarse entre cuatro segundos y tres minutos. [2]
La falla de IPv6 ahora se considera generalmente como un problema resuelto para casi todos los propósitos prácticos, gracias a las mejoras en las capas de transporte y aplicación. [3]
En mayo de 2011, la vulnerabilidad de IPv6, medida mediante la instrumentación de un conjunto de sitios web noruegos, se redujo a aproximadamente el 0,015 %, [4] la mayor parte de la cual se debía a versiones anteriores de Mac OS X que a menudo preferían una conectividad IPv6 que no funcionaba cuando no estaba justificada. [5] Este comportamiento se solucionó en Mac OS X 10.6.5 y es probable que disminuya aún más a medida que Mac OS X 10.6.5 y las versiones posteriores se implementen para un público más amplio. Sin embargo, no había una ruta de actualización para los Mac basados en PowerPC . [6]
El principal problema restante para Mac OS X era la presencia de enrutadores no autorizados, como dispositivos de Conexión compartida a Internet de Windows configurados incorrectamente que simulaban tener conectividad IPv6, mientras que el tráfico IPv6 tunelizado 6to4 estaba bloqueado en un firewall. [ cita requerida ] Otro problema eran las versiones anteriores a la 10.50 de Opera. [ cita requerida ]
Tras el Día Mundial de IPv6 en julio de 2011, hubo informes de una reducción sustancial en la vulnerabilidad de IPv6 como resultado de ese experimento. [7] En el año posterior a la prueba, pero antes de la fecha de lanzamiento mundial de IPv6 , se informó que los niveles de vulnerabilidad habían vuelto a aumentar lentamente hasta llegar al 0,03%. [8]
Google , un importante proveedor de servicios en Internet, experimentó con el uso de un tipo de lista de permitidos de DNS por ISP para evitar esto [9] [10] hasta el lanzamiento mundial de IPv6. En el enfoque de lista de permitidos de DNS, los ISP se determinan a partir de las direcciones IP de origen de la búsqueda de DNS correlacionándolas con prefijos de red derivados de las tablas de enrutamiento . Hay un borrador de IETF titulado "IPv6 AAAA DNS Allowlisting Implications" que describe los problemas relacionados con la lista de permitidos. Los registros AAAA solo se envían a los ISP que pueden demostrar que están proporcionando IPv6 confiable a sus clientes. A otros ISP solo se les envían registros A, lo que evita que los usuarios intenten conectarse a través de IPv6 cuando se usan nombres de host en lugar de direcciones IPv6.
Se plantearon numerosas preocupaciones sobre la viabilidad de la inclusión en listas de permitidos de DNS como una solución a gran escala a largo plazo, como problemas de escalabilidad y mantenimiento relacionados con el mantenimiento de un gran número de acuerdos bilaterales. [11] En 2010, varios de los principales proveedores de servicios web se reunieron para discutir la puesta en común de su información de inclusión en listas de permitidos de DNS en un intento de evitar estos problemas de escalabilidad. [12]
Parece que ningún proveedor de contenido importante terminó utilizando el enfoque de lista blanca, dado que todos los que habían declarado previamente un interés comenzaron a ofrecer registros AAAA a consultas DNS genéricas después del Día del Lanzamiento Mundial de IPv6 . Google ahora proporciona registros AAAA a todos los servidores DNS, excepto a aquellos en una lista limitada de subredes que Google excluye del servicio de registros AAAA. [13] [14]
A partir de 2017, la falla de IPv6 ya no se considera un problema. Esto se debe a dos factores: en primer lugar, el transporte de IPv6 ha mejorado mucho, por lo que la tasa de error subyacente se ha reducido mucho, y en segundo lugar, las aplicaciones comunes, como los navegadores web, ahora utilizan métodos de respaldo rápido, como el algoritmo " Happy Eyeballs ", para seleccionar el protocolo que funcione mejor. [3] Algunos proveedores de sistemas operativos han incorporado algoritmos de respaldo rápido en sus API de pila de red de nivel superior , lo que hace que la solución esté disponible para todos los programas que utilizan esas API para realizar conexiones. [15]