Каковы недостатки включения IPv6 в общедоступных службах?

Наша внутренняя сеть и внутренние службы поддерживают IPv6, и мы рассматриваем возможность включения IPv6 на общедоступных SMTP, DNS и веб-серверах. Все руководства / технические документы, которые я прочитал по этому вопросу, говорят только о преимуществах, но я уверен, что есть и некоторые недостатки. Например:

1. Клиенты с IPv6 через туннели будут иметь более медленный доступ к нашим услугам, если мы включим IPv6.
2. Клиенты со сломанным IPv6 вообще не смогут получить к ним доступ.

Учитывая, что только очень небольшой процент пользователей имеют работающий IPv6, а те, которые обычно используют двойной стек, я склонен думать, что включение IPv6, когда вы не контролируете обе стороны канала связи, на самом деле является плохой идеей в 2011 году ,

Есть ли какие-либо исследования / статьи / статьи на эту тему?

Эта статья представляет собой обзор реального эксперимента. Они утверждают, что имеют только незначительные проблемы.

Может быть, это немного поможет настроить DNS-серверы для отправки ответов IPv6 только через интерфейсы IPv6 - это исключит интернет-провайдеров, у которых вообще нет IPv6. Не все клиенты используют преобразователи DNS, предоставленные их провайдером, но большинство используют . Также провайдер , имеющий IPv6 не означает , что это клиенты , имеющие IPv6. Все же это некоторое улучшение.

Кстати, если кто-то достаточно умен, чтобы настроить туннель, он, вероятно, знает, что он делает, и не должен винить никого, кроме себя. :)

Редактировать:

Руководство BIND9:

filter-aaaa-on-v4 Этот параметр доступен, только если BIND 9 скомпилирован с параметром --enable-filter-aaaa в командной строке «configure». Он предназначен для облегчения перехода от IPv4 к IPv6, не давая IPv6-адреса DNS-клиентам, если у них нет подключений к Интернету IPv6. Это не рекомендуется без крайней необходимости.

... Этот механизм применяется как к авторитетным, так и к неавторизованным записям. ...

Всемирный день IPv6 ранее в этом году стал испытанием именно для этого. Результаты были смешанными , но в итоге оказались лучше, чем опасались . Опасение было массовым крахом, поскольку клиенты с поддержкой IPv6 на островах v6 не могли получить доступ к сайтам v6, но в итоге это происходило не так часто, как теоретизировалось.

Большим отличием является то, что современные браузеры обрабатывают jiggery-pokery v4 / v6 таким образом, чтобы не замечать пользователей почти так же, как это было даже два года назад.

Практически, один из самых больших успехов в переходе на v6 заключается в том, что некоторые клиенты v6, имеющие туннели v6, а не собственные соединения v6 с Интернетом, могут в конечном итоге сделать так, чтобы их трафик занимал более длинный / медленный путь к вашему сайту, чем в родной версии v4. Он все еще будет работать, он будет загружаться медленнее.

Результаты Всемирного дня IPv6 показали, что это не главная проблема. Кто-то с туннелем IPv6 сознательно выбрал для этого туннеля, поэтому, если туннель намного медленнее, чем IPv4, то это по выбору пользователя / sysadmin. Современные браузеры (Firefox, Chrome, Safari и даже IE в ближайшем будущем) будут использовать систему под названием Happy Eyeballs или что-то подобное. Очень грубое описание этого: при открытии соединения IPv6 устанавливается короткий таймер (я думаю, что Chrome использует 300 мс). Если этот таймер истекает до установления соединения IPv6, он попытается установить соединение IPv4. Пользователь не заметит никаких потенциальных проблем с IPv6.