Комментарии 8
Первый – приглушить IPv6 вовсе или, наоборот, создать хаб для работы только через него.
Выключайте его — он нормально используется в основном только в каких то изолированных системах. Если честно считаю IPv6 каким то безумием, потому как полное отсутствие обратной совместимости делает все его реализации экономически и технически нецелеобразными. Посмотрите опрос — более чем в 50% попыток даже не получилось IPv6 запустить. Это уже не вспоминая, что 99% провайдеров не дают IPv6 и даже не планируют. То зачем вам решать ловить баги и создавать кучу проблем у пользователей?
в форуме про разширение по указанной ссылке:
Fredrik Ullner (ullner) on 2013-11-30
tags: added: core
removed: ipv6 support
IPv6 надо осваивать. Сидеть за NAT это не дело. Протоколы верхнего уровня нужно адаптировать под работу с двумя типами адресов. Естественно что до сих пор идёт медленная адаптация к IPv6 поскольку им мало пользуются.
IPv6 надо осваивать.
Кому надо? Проблема в том — что с ipv6 все обязаны раздваивать сетевые настройки на всех участках сети, причем логика настроек сильно отличается, а ничего кроме лишнего головняка, это не принесет. Сам лично три раза пробовал в разных организациях — и обязательно на каком либо этапе просто тупое отсутствие поддержки ipv6. Поэтому для себя сделал вывод выключать его нафиг, чтоб потом не искать — что же за новый глюк прилетел. Ipv6 ради ipv6 — сомнительное удовольствие, к тому же как указано выше в более чем 50% попыток внедрения невозможно реализовать. Тогда зачем городить огород, если более 50% потенциальных пользователей не смогут пользоваться, а остальные будут ловить глюки в работе приложения из-за полной несовместимости протоколов ipv4 и ipv6?
Есть замечательный протокол [6to4](https://ru.wikipedia.org/wiki/6to4) который оборачивает IPv6 пакеты в IPv4 пакеты позволяет организовывать связь с удалёнными IPv6 узлами по IPv4 сети. Прелесть его в том что у него есть дефолтный IPv4 anycast шлюз(192.88.99.1) который может организовать провайдер на границе с IPv6 сетью. А а если не организует то пакет полетит дальше к ближайшему шлюзу. А то что IPv6 адрес содержит в себе IPv4 адрес позволяет в теории пустить IPv6 пакет в обратную сторону напрямую по этому адресу по IPv4 сети в обход шлюза.
Через NAT провайдера 6to4 работает в обе стороны. Я проверял несколько провайдеров и у всех NAT справился с переправкой 6to4 пакета входящего соединения на мой роутер. За которым я организовал свою маленькую IPv6 сеть используя внешний IPv4 провайдера и немного рандома.
медленная адаптация к IPv6 поскольку им мало пользуются
Подозреваю что если за 10 лет не взлетел, то и в следующие 10 лет не взлетит, а потом устареет и появится более разумная альтернатива, которых уже несколько или придумают ipv4plus. То что штаты и Индия насильно внедряют клиентам — ничего не значит(особенно учитывая, что указан не процент использования — 46% и 49%, а процент доступности), потому как много критических компонентов не поддерживают ipv6 и судя по всему ситуация не изменится, так как жестко подходить к пользователям — оставлять только ipv6 — экономически будет не выгодно, потому что с появлением 4g/5g конкуренция на рынке провайдеров значительно усилилилась. Я не против ipv6 — но на собственном опыте убедился, что лучше не тратить на него свое время и нервы — много глюков(а много вообще не работает, например скайп) и особо бесит громадная задержка(1-3сек) при переключении протокола — если ipv6(который работает по умолчанию) на некоторых ресурсах недоступен.
У себя просто удалил AAAA-запись с основного адреса хаба и приклеил только её одну на другой. Кто захочет – пусть пользуется, но не более.
Полагаю, несовместимостей решил избежать и тов. ullner. Хотя непосредственно перед публикацией этой статьи мне подогнали для теста ADCH++ с интегрированным HRBI.
А вы рассматривали mldonkey — он держит оба протокола и несколько типов сетей.
V6 перспективен, особенно в связи с блокировками.
Использование IPv6 в Advanced Direct Connect