¿Cuáles son las desventajas de habilitar IPv6 en los servicios públicos?

Nuestra red interna y servicios internos están habilitados para IPv6, y estamos considerando habilitar IPv6 en SMTP, DNS y servidores web públicos. Todas las guías / libros blancos que he leído sobre el tema solo hablan sobre los beneficios, pero estoy seguro de que también hay algunos inconvenientes. Por ejemplo:

1. Los clientes con IPv6 a través de túneles tendrán un acceso más lento a nuestros servicios si habilitamos IPv6.
2. Los clientes con IPv6 roto no podrán acceder a ellos en absoluto.

Dado que solo un porcentaje muy pequeño de usuarios tiene IPv6 en funcionamiento, y aquellos que lo hacen son generalmente de doble pila, me inclino a pensar que habilitar IPv6 cuando no controlas ambos lados del canal de comunicación es realmente una mala idea en 2011 .

¿Hay alguna investigación / artículos / artículos sobre este tema?

Este artículo es una descripción general de un experimento de la vida real. Afirman tener solo problemas menores.

Tal vez pueda ayudar un poco configurar sus servidores DNS para enviar respuestas IPv6 solo en las interfaces IPv6; descartará a los ISP que no tienen IPv6 en absoluto. No todos los clientes usan resolvers DNS proporcionados por su ISP, pero la mayoría lo hace. Además, el ISP que tiene IPv6 no significa que sus clientes tengan IPv6. Sin embargo, es una mejora.

Por cierto, si alguien es lo suficientemente inteligente como para configurar el túnel, probablemente sepa lo que hace y no debería culpar a nadie más que a sí mismo. :)

Editar:

Manual de BIND9:

filter-aaaa-on-v4 Esta opción solo está disponible cuando BIND 9 se compila con la opción --enable-filter- aaaa en la línea de comando "configure". Su objetivo es ayudar a la transición de IPv4 a IPv6 al no dar direcciones IPv6 a clientes DNS a menos que tengan conexiones a Internet IPv6. Esto no se recomienda a menos que sea absolutamente necesario.

... Este mecanismo se aplica tanto a los registros autorizados como a los no autorizados. ...

El día mundial de IPv6 a principios de este año fue una prueba de esto. Los resultados fueron mixtos , pero terminaron mejor de lo que se temía . El temor era la ruptura masiva, ya que los clientes habilitados para IPv6 en las islas v6 no podían acceder a los sitios v6, pero eso no sucedió tan a menudo como se había teorizado.

Una gran conclusión es que los navegadores modernos manejan la jiggery-pokery v4 / v6 de una manera que no molesta a los usuarios tanto como lo hizo hace dos años.

Prácticamente, uno de los mayores éxitos para ir a v6 es que algunos clientes v6 que tienen túneles v6 en lugar de conexiones nativas v6 a Internet pueden terminar haciendo que su tráfico tome una ruta más larga / lenta a su sitio de lo que lo harían en v4 nativo. Todavía funcionará, solo se cargará más lentamente.

Los resultados del Día Mundial de IPv6 han demostrado que este no es un problema importante. Alguien con un túnel IPv6 ha elegido conscientemente ese túnel, por lo que si el túnel es mucho más lento que IPv4, esto es por elección del usuario / administrador del sistema. Los navegadores actuales (Firefox, Chrome, Safari e incluso IE en el futuro cercano) usarán un sistema llamado Happy Eyeballs, o algo así. Descripción muy aproximada de esto: al abrir una conexión IPv6 hay un conjunto de temporizador corto (creo que Chrome usa 300 ms). Si ese temporizador caduca antes de que se realice la conexión IPv6, intentará configurar una conexión IPv4. El usuario no notará ningún problema potencial con IPv6.