Использование IPv6 в Advanced Direct Connect

Наблюдать за развитием файлообменной сети интересно, но ещё интереснее участвовать в нём.

На сегодняшний день, устанавливая и запуская современный NMDC хаб, новоиспечённый администратор получает доступ практически ко всем наработкам и накопленному в этой области опыту его предшественников. Он имеет систему, готовую к расширению и кастомизации в том числе с помощью многочисленных скриптов.

С ADC хабами иначе. Структура этого протокола предполагает расширяемость. Хочешь новую фичу? Ну что ж – предлагай, продвигай, реализуй, внедряй, пользуйся.

Translate to English

Как следствие, «из коробки» можно, конечно, получить готовый хаб, но просто запустить и забыть о нём будет нехорошо. Расширяемость в историческом контексте предполагает в том числе и наличие разного количества разных функций клиентского и серверного софта в зависимости от версии. И то, что будет работать без проблем у одного пользователя, может оказаться несовместимым с клиентом другого, и это нужно учитывать.

Так случилось и с IPv6. Старичок NMDC не умеет его в принципе, а вот ADC сам по себе к нему готов. Однако, не всё так просто.

Совсем немного теории


«Активный» пользователь может принимать входящие соединения. Собственно, исходящий от него запрос на соединение на самом деле является приглашением.

«Пассивный» пользователь в общем случае может использовать только исходящие запросы. Посредством хаба он просит активного пользователя отослать приглашение – и соединение получается.



И да, этот механизм не зависит от версии используемого протокола IP.

Лебедь, рак и щука


Поговорим о клиентском софте.

Поддержка IPv6 в DC++ носит экспериментальный характер. Отдельных настроек для него нет, и тем удивительнее для меня было увидеть разные режимы работы для разных версий IP, причём пассивный как раз для шестой, но это неточно.

Получить активный режим при ручной настройке не удалось даже при явном использовании в качестве WAN IP домена с AAAA-записью, а вот в автоматическом режиме с использованием UPnP всё заработало как до́лжно.

AirDC++ также имеет поддержку IPv6-соединений, и реализована она вовсе отдельно от IPv4. Более того, этот клиент модифицирует тэги пользователей таким образом, чтобы отображать режимы работы для обоих IP протоколов одновременно. Сами хабы делать этого (пока) не умеют, а жаль.

Сразу должен оговориться: AirDC++ делает так один и для себя. В дальнейшем для удобства я буду использовать сочетания вроде AP или AA как указание на активный или пассивный режимы работы для IPv4 и IPv6 соответственно, а не их отображение в тэге реального клиента на реальном хабе. Это важно.

В нашем эксперименте мы будем использовать FlylinkDC++ в качестве клиента, вовсе не знакомого с IPv6.

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

Начало


Первым делом мы рассмотрим заведомо невозможные соединения между пользователями разных версий протокола IP. Для теста будет использоваться IPv6 ready хаб с ресурсными A- и AAAA-записями для доменного имени, выступающего в качестве его адреса.



Обратите внимание, при (фактической) попытке обращения к пользователю с IP-адресом шестой версии выводится ошибка.

Hub:	[Outgoing][IPv4:412]	 	DRCM AACX AACU ADCS/0.10 337151563
Hub:	[Incoming][IPv4:412]	 	DCTM AACU AACX ADCS/0.10 1988 337151563
Hub:	[Outgoing][IPv4:412]	 	DSTA AACX AACU 240 IP\sunknown

В переводе на человеческий это звучит как

P4: – Можно я к тебе прицеплюсь?
A6: – Цепляйся!
P4: – Жизнь боль 0_0

Краткий словарик, если что, здесь.

А если наоборот, и соединение иницирует A4, то ошибка не выводится, и соединение просто «зависает».

Hub:	[Outgoing][IPv4:412]	 	DCTM AACX AACU ADCS/0.10 1993 3871342713

Быть, а не казаться


Что важно, так это отображаемый на хабе режим соединения.

Клиенты без поддержки IPv6 должны будут видеть подключенных через него пользователей как однозначно пассивных просто потому, что для них хаб не заполняет I4 или I6 поле соответственно.


FlylinkDC++ vs. IPv6

На деле же ситуация проще и сложнее одновременно.


AirDC++ vs. IPv6

Проще, потому что IPv6 имеет приоритет над IPv4, и это понятно. Именно через него (хотя с помощью соответствующей опции доступно переопределение) будет установлено соединение с хабом, и его же активный клиент будет предлагать для соединения пассивному.

Сложнее, потому что если на хабе присутствуют пользователи с поддержкой IPv6, но подсоединены они строго через IPv4-адрес, то…



… то с ними можно соединиться (наобум) вообще не имея IPv4.

Обратите внимание, удалённый клиент обозначил себя как актива, но обрабатывается как пассив. Почему?

Туды его в качель


Теперь попробуем соединять друг с другом клиенты с различными, но общими в части IPv4 наборами поддержки протокола IP.



Да, жаль, что пассивным пользователям приходится курить в сторонке. Но помочь этому нельзя, так как их видимый IP-адрес не имеет особого значения – на то они и пассивы.



Ба! Активный клиент отправляет пассивную команду?.. Логично было бы ожидать «зависшего» соединения, но нет, оно получается на условиях A4.

Почему так? Обращаемся к разработчику и получаем ответ:
CTM isn't good if the other user doesn't support IPv6

И ведь не поспоришь! Но это требует уже внутренней, независимой от хаба логики (см. код здесь и здесь). Пассивам же по-прежнему помочь нельзя, потому что
Active mode = TCPx + IPx

Попытки же соединения между клиентами с общими в части IPv6 наборами поддержки протокола IP выглядят следующим образом. Напомню, добиться PA для DC++ мне не удалось.



И снова сюрприз. Получается, пассивный режим для IPv6, который демонстрирует DC++, есть или намеренный фейк, или баг.

Что дальше?


В настоящее время существует ровно два способа решения всех возможных проблем соединения пользователей в разных режимах и с разными наборами поддержки протокола IP.

Первый – приглушить IPv6 вовсе или, наоборот, создать хаб для работы только через него.

Второй – вот это расширение, которое только-только подходит к стадии тестирования.

Ну и, ленясь настраивать активный режим для работы в DC, помните:

Кто имеет, тому дано будет, а кто не имеет, у того отнимется и то, что он думает иметь. Лк. 8:18

Комментарии 8

    0
    Первый – приглушить IPv6 вовсе или, наоборот, создать хаб для работы только через него.

    Выключайте его — он нормально используется в основном только в каких то изолированных системах. Если честно считаю IPv6 каким то безумием, потому как полное отсутствие обратной совместимости делает все его реализации экономически и технически нецелеобразными. Посмотрите опрос — более чем в 50% попыток даже не получилось IPv6 запустить. Это уже не вспоминая, что 99% провайдеров не дают IPv6 и даже не планируют. То зачем вам решать ловить баги и создавать кучу проблем у пользователей?
    в форуме про разширение по указанной ссылке:


    Fredrik Ullner (ullner) on 2013-11-30
    tags: added: core
    removed: ipv6 support
      +1

      IPv6 надо осваивать. Сидеть за NAT это не дело. Протоколы верхнего уровня нужно адаптировать под работу с двумя типами адресов. Естественно что до сих пор идёт медленная адаптация к IPv6 поскольку им мало пользуются.

        0
        IPv6 надо осваивать.

        Кому надо? Проблема в том — что с ipv6 все обязаны раздваивать сетевые настройки на всех участках сети, причем логика настроек сильно отличается, а ничего кроме лишнего головняка, это не принесет. Сам лично три раза пробовал в разных организациях — и обязательно на каком либо этапе просто тупое отсутствие поддержки ipv6. Поэтому для себя сделал вывод выключать его нафиг, чтоб потом не искать — что же за новый глюк прилетел. Ipv6 ради ipv6 — сомнительное удовольствие, к тому же как указано выше в более чем 50% попыток внедрения невозможно реализовать. Тогда зачем городить огород, если более 50% потенциальных пользователей не смогут пользоваться, а остальные будут ловить глюки в работе приложения из-за полной несовместимости протоколов ipv4 и ipv6?

          0
          IPv6 нужен для того чтобы вернуть то что мы потеряли когда IPv4 стало не хватать многие стали сидеть за NAT(а зачастую за двумя) и появилась туча костылей чтобы преодалеть его. Отсутсвие поддержки IPv6 в P2P клиентах не даёт связаться напрямую двум пользователям за двумя NAT. Пользователи сидя за натом вынуждены пользоваться внешними серверами для того чтобы те тупо гоняли трафик от одного пользователя другому (это различные видеочаты и меседжеры с аудио и видеосвязью). А это опять же лишняя нагрузка на сетевую инфраструктуру. Пришло время когда каждый пользователь не только потребляет много трафика но и генерирует и если этот трафик будет идти через третьи руки это будет двойной тяжёлой нагрузкой на сеть. Я уже вижу как твичь периодически задыхается от трафика не смотря на свой CDN по которым стримеры раскидывают свой потоки.

          Есть замечательный протокол [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 провайдера и немного рандома.
            0
            медленная адаптация к IPv6 поскольку им мало пользуются

            Подозреваю что если за 10 лет не взлетел, то и в следующие 10 лет не взлетит, а потом устареет и появится более разумная альтернатива, которых уже несколько или придумают ipv4plus. То что штаты и Индия насильно внедряют клиентам — ничего не значит(особенно учитывая, что указан не процент использования — 46% и 49%, а процент доступности), потому как много критических компонентов не поддерживают ipv6 и судя по всему ситуация не изменится, так как жестко подходить к пользователям — оставлять только ipv6 — экономически будет не выгодно, потому что с появлением 4g/5g конкуренция на рынке провайдеров значительно усилилилась. Я не против ipv6 — но на собственном опыте убедился, что лучше не тратить на него свое время и нервы — много глюков(а много вообще не работает, например скайп) и особо бесит громадная задержка(1-3сек) при переключении протокола — если ipv6(который работает по умолчанию) на некоторых ресурсах недоступен.

        0
        Опрос хорош :)

        У себя просто удалил AAAA-запись с основного адреса хаба и приклеил только её одну на другой. Кто захочет – пусть пользуется, но не более.

        Полагаю, несовместимостей решил избежать и тов. ullner. Хотя непосредственно перед публикацией этой статьи мне подогнали для теста ADCH++ с интегрированным HRBI.
        0

        А вы рассматривали mldonkey — он держит оба протокола и несколько типов сетей.
        V6 перспективен, особенно в связи с блокировками.

          0
          mldonkey
          Нет, никогда не пользовался им.

          V6 перспективен, особенно в связи с блокировками
          Тут есть противоречие. Пока он не массовый (один мой пров вообще не собирается его предоставлять нативно, а с IPv6 от другого не хочет дружить мой роутер), да. Но как только станет массовым – будут и блокировки.

        Только полноправные пользователи могут оставлять комментарии. Войдите, пожалуйста.

        Самое читаемое