Quels sont les inconvénients de l'activation d'IPv6 dans les services accessibles au public?

Notre réseau interne et nos services internes sont compatibles IPv6, et nous envisageons d'activer IPv6 sur des serveurs SMTP, DNS et Web accessibles au public. Tous les guides / livres blancs que j'ai lus sur le sujet ne parlent que des avantages, mais je suis sûr qu'il y a aussi des inconvénients. Par exemple:

1. Les clients avec IPv6 via des tunnels auront un accès plus lent à nos services si nous activons IPv6.
2. Les clients avec IPv6 cassé ne pourront pas y accéder du tout.

Étant donné que seul un très petit pourcentage d'utilisateurs utilise IPv6, et ceux qui le font sont généralement à double pile, je suis enclin à penser qu'activer IPv6 lorsque vous ne contrôlez pas les deux côtés du canal de communication est en fait une mauvaise idée en 2011 .

Existe-t-il des recherches / articles / articles sur ce sujet?

Cet article est un aperçu d'une expérience réelle. Ils affirment n'avoir que des problèmes mineurs.

Peut-être que cela peut aider un peu à configurer vos serveurs DNS pour envoyer des réponses IPv6 uniquement sur les interfaces IPv6 - cela exclura les FAI qui n'ont pas du tout IPv6. Tous les clients n'utilisent pas les résolveurs DNS fournis par leur FAI, mais la plupart le font. De plus, le FAI ayant IPv6 ne signifie pas que ses clients ont IPv6. C'est pourtant une amélioration.

BTW, si quelqu'un est assez intelligent pour configurer un tunnel, il sait probablement ce qu'il fait et ne devrait blâmer personne d'autre que lui-même. :)

Éditer:

Manuel BIND9:

filter-aaaa-on-v4 Cette option n'est disponible que lorsque BIND 9 est compilé avec l'option --enable-filter- aaaa sur la ligne de commande ”configure”. Il est destiné à faciliter la transition d'IPv4 à IPv6 en ne donnant pas d'adresses IPv6 aux clients DNS à moins qu'ils ne soient connectés à Internet IPv6. Ceci n'est pas recommandé sauf en cas d'absolue nécessité.

... Ce mécanisme s'applique aussi bien aux enregistrements faisant autorité qu'à ceux qui ne font pas autorité. ...

La journée mondiale IPv6 plus tôt cette année a été un test de tout cela. Les résultats ont été mitigés , mais se sont révélés meilleurs que prévu . La crainte était une rupture massive car les clients compatibles IPv6 dans les îles v6 ne pouvaient pas accéder aux sites v6, mais cela n'a finalement pas eu lieu aussi souvent que prévu.

Un gros point à retenir est que les navigateurs modernes gèrent le jiggery-pokery v4 / v6 d'une manière qui ne décourage pas les utilisateurs presque autant qu'il y a deux ans.

Pratiquement, l'un des plus gros succès pour la version 6 est que certains clients v6 qui ont des tunnels v6 plutôt que des connexions natives v6 à Internet peuvent finir par voir leur trafic emprunter un chemin plus long / plus lent vers votre site qu'ils ne le feraient avec la v4 native. Cela fonctionnera toujours, il ne fera que charger plus lentement.

Les résultats de la Journée mondiale IPv6 ont montré que ce n'est pas un problème majeur. Quelqu'un avec un tunnel IPv6 a consciemment choisi ce tunnel, donc si le tunnel est beaucoup plus lent que IPv4, alors c'est par choix de l'utilisateur / administrateur système. Les navigateurs actuels (Firefox, Chrome, Safari et même IE dans un proche avenir) utiliseront un système appelé Happy Eyeballs, ou quelque chose comme ça. Description très approximative de ceci: Lors de l'ouverture d'une connexion IPv6, il y a un ensemble de minuteries courtes (je pense que Chrome utilise 300 ms). Si ce temporisateur expire avant que la connexion IPv6 ne soit établie, il essaiera de configurer une connexion IPv4. L'utilisateur ne remarquera aucun problème potentiel avec IPv6.