我们的内部networking和内部服务都支持IPv6，我们正在考虑在面向公众的SMTP，DNS和Web服务器上启用IPv6。 我所读过的关于这个主题的所有指南/白皮书都只是讲讲好处，但我相信也有一些不足之处。 例如：
考虑到只有极less数用户在使用IPv6，而那些用户通常是双栈，所以我倾向于认为，当你不控制通信渠道的双方时启用IPv6在2011年实际上是一个坏主意。
有没有关于这个问题的研究/论文/文章？
这篇文章是一个真实的实验的概述。 他们声称只有小问题。
也许这可能会有助于configuration您的DNS服务器仅在IPv6接口上发送IPv6答案 – 它将排除根本没有IPv6的ISP。 并不是所有的客户端都使用ISP提供的DNSparsing器，但大部分都可以。 另外，具有IPv6的ISP并不意味着它是具有IPv6的客户 。 但是这是一些改进。
顺便说一句，如果有人聪明地build立隧道，他可能知道他做了什么，应该责怪别人，但他自己。 🙂
编辑：
BIND9手册：
filter-aaaa-on-v4此选项仅当在“configure”命令行上使用–enable-filter- aaaa选项编译BIND 9时才可用。 它旨在通过不向DNS客户端提供IPv6地址来帮助从IPv4过渡到IPv6，除非它们连接到IPv6 Internet。 除非绝对必要，否则不build议这样做。
这种机制适用于权威性和非权威性的logging。 …
今年早些时候的世界IPv6日是对此的一个考验 。 结果 好坏参半 ，但结果好于恐惧 。 由于v6岛屿的IPv6客户端无法访问v6站点，因此担心是大规模的崩溃，但最后几乎没有像理论上那样频繁发生。
一个很大的收获是，现代浏览器处理v4 / v6 jiggery-pokery的方式不会像两年前那样勾起用户。
实际上，v6的更大优势之一是一些v6客户端拥有v6隧道，而不是v6本地连接到互联网，可能会导致他们的stream量比在本地v4上获得更长/更慢的path。 它仍然可以工作，只会加载较慢。
世界IPv6日的结果表明，这不是一个大问题。 有人对IPv6隧道有意识地select了隧道，所以如果隧道比IPv4慢得多，那么这是由用户/系统pipe理员的select。 目前的浏览器（Firefox，Chrome，Safari，甚至IE在不久的将来）都会使用一个叫做Happy Eyeballs的系统，或者类似的东西。 对此非常粗略的描述：当打开一个IPv6连接有一个短计时器设置（我认为Chrome使用300毫秒）。 如果该定时器在IPv6连接build立之前到期，则它将尝试build立一个IPv4连接。 用户不会注意到IPv6的任何潜在问题。