Заметка
Выполняется развертывание и тестирование сети. Возможно внесение небольших изменений.
Обзор
Предлагается внедрить улучшения к транспортировке SSU и NTCP2 для IPv6.
Мотивация
С ростом IPv6 по всему миру и увеличением числа конфигураций, работающих только с IPv6 (особенно на мобильных устройствах), необходимо улучшить поддержку IPv6 и убрать предположения, что все маршрутизаторы поддерживают IPv4.
Проверка подключения
При выборе пиров для туннелей или путей OBEP/IBGW для маршрутизации сообщений, полезно рассчитать, может ли маршрутизатор A подключиться к маршрутизатору B. В общем случае это означает, что A имеет возможность исходящего соединения для типа транспорта и адреса (IPv4/v6), который совпадает с одним из объявленных входящих адресов B.
Однако во многих случаях мы не знаем возможностей A и вынуждены делать предположения. Если A скрыт или находится за файрволом, адреса не публикуются, и у нас нет прямых сведений — мы предполагаем, что он поддерживает IPv4 и не поддерживает IPv6. Решением является добавление двух новых “возможностей” или способностей в Router Info для указания исходящей возможности для IPv4 и IPv6.
Введение IPv6
Наши спецификации SSU и SSU-SPEC содержат ошибки и несоответствия относительно поддержки вводных устройств IPv6 для введений с IPv4. В любом случае, это никогда не было реализовано ни в Java I2P, ни в i2pd. Это необходимо исправить.
Вводные устройства для IPv6
Наши спецификации SSU и SSU-SPEC ясно указывают, что вводные устройства IPv6 не поддерживаются. Это было сделано из предположения, что IPv6 никогда не блокируется файрволом. Это явно не так, и нам нужно улучшить поддержку маршрутизаторов IPv6, которые могут быть за файрволами.
Диаграммы введения
Легенда: —– это IPv4, ====== это IPv6
Текущий сценарий только для IPv4:
Алиса Боб Чарли
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
Введение через IPv4, вводное устройство на IPv6
Алиса Боб Чарли
RelayRequest ======================>
<============== RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
Введение через IPv6, вводное устройство на IPv6
Алиса Боб Чарли
RelayRequest ======================>
<============== RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
Введение через IPv6, вводное устройство на IPv4
Алиса Боб Чарли
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
Дизайн
Предполагается внедрение трех изменений.
- Добавление возможностей “4” и “6” в адреса маршрутизатора для указания поддержки исходящих соединений IPv4 и IPv6
- Добавление поддержки для введения через IPv4 с помощью вводных устройств IPv6
- Добавление поддержки для введения через IPv6 с помощью вводных устройств IPv4 и IPv6
Спецификация
4/6 Возможности
Это изначально было реализовано без формального предложения, но это необходимо для введений через IPv6, поэтому мы включаем это здесь. Смотрите также CAPS.
Определяются две новые возможности “4” и “6”. Эти новые возможности будут добавлены в свойство “caps” в адресе маршрутизатора, но не в свойствах caps самой информации о маршрутизаторе. В настоящее время у нас нет свойства “caps” для NTCP2. Адрес SSU с вводными устройствами в настоящее время, по определению, является ipv4. Мы не поддерживаем введение через ipv6. Однако это предложение совместимо с введением через IPv6. Смотрите ниже.
Кроме того, маршрутизатор может поддерживать подключение через оверлейные сети, такие как I2P-over-Yggdrasil, но не хочет публиковать адрес или этот адрес не имеет стандартного формата IPv4 или IPv6. Эта новая система возможностей должна быть достаточно гибкой, чтобы поддерживать и эти сети.
Мы определяем следующие изменения:
NTCP2: Добавить свойство “caps”
SSU: Добавить поддержку адреса маршрутизатора без хоста или вводных устройств для указания исходящей поддержки для IPv4, IPv6 или обоих.
Оба транспорта: Определить следующие значения caps:
- “4”: Поддержка IPv4
- “6”: Поддержка IPv6
Множественные значения могут быть поддержаны в одном адресе. Смотрите ниже. Хотя бы один из этих caps обязателен, если значение “host” не включено в адрес маршрутизатора. Не более одного из этих caps является необязательным, если значение “host” включено в адрес маршрутизатора. В будущем могут быть определены дополнительные caps для указания поддержки оверлейных сетей или другой связности.
Примеры использования и примеры
SSU:
SSU с хостом: 4/6 необязательны, никогда не более одного. Пример: SSU caps=“4” host=“1.2.3.4” key=… port=“1234”
SSU только с исходящей поддержкой для одного, другое опубликовано: Только Caps, 4/6. Пример: SSU caps=“6”
SSU с вводными устройствами: никогда не комбинируются. 4 или 6 обязательны. Пример: SSU caps=“4” iexp0=… ihost0=… iport0=… itag0=… key=…
SSU скрытый: Только Caps, 4, 6, или 46. Множественные значения разрешены. Нет необходимости для двух адресов один с 4 и один с 6. Пример: SSU caps=“46”
NTCP2:
NTCP2 с хостом: 4/6 необязательны, никогда не более одного. Пример: NTCP2 caps=“4” host=“1.2.3.4” i=… port=“1234” s=… v=“2”
NTCP2 только с исходящей поддержкой для одного, другое опубликовано: Только Caps, s, v, 4/6/y, множественные разрешены. Пример: NTCP2 caps=“6” i=… s=… v=“2”
NTCP2 скрытый: Только Caps, s, v, 4/6, множественные разрешены. Нет необходимости для двух адресов один с 4 и один с 6. Пример: NTCP2 caps=“46” i=… s=… v=“2”
Вводные устройства IPv6 для IPv4
Требуются следующие изменения для исправления ошибок и несоответствий в спецификациях. Также мы описали это как “часть 1” предложения.
Изменения спецификаций
SSU в настоящий момент говорит (заметки по IPv6):
IPv6 поддерживается с версии 0.9.8. Публикуемые адреса реле могут быть IPv4 или IPv6, и связь Алисы-Боба может осуществляться через IPv4 или IPv6.
Добавить следующее:
Хотя спецификация была изменена с версии 0.9.8, связь Алисы-Боба через IPv6 не поддерживалась до версии 0.9.50. Более ранние версии Java роутеров ошибочно публиковали ‘C’ возможность для IPv6 адресов, хотя фактически они не действовали как вводный через IPv6. Следовательно, роутеры должны доверять возможности ‘C’ на IPv6 адресе только если версия роутера 0.9.50 или выше.
SSU-SPEC в данный момент говорит (Relay Request):
IP адрес включается только если он отличается от исходного адреса и порта пакета. В текущей реализации длина IP всегда 0, а порт всегда 0, и принимающий должен использовать исходный адрес и порт пакета. Это сообщение может быть отправлено через IPv4 или IPv6. Если IPv6, Алиса обязана включить свой IPv4 адрес и порт.
Добавить следующее:
IP и порт должны быть включены для введения IPv4 адреса при отправке этого сообщения через IPv6. Это поддерживается начиная с релиза 0.9.50.
Введение через IPv6
Все три сообщения реле SSU (RelayRequest, RelayResponse и RelayIntro) содержат поля длины IP, чтобы указать длину IP адреса (Алисы, Боба или Чарли), который следует.
Поэтому изменение формата сообщений не требуется. Только текстовые изменения в спецификациях, указывающие, что 16-байтные IP адреса разрешены.
Требуемые изменения в спецификациях. Также мы описали это как “часть 2” предложения.
Изменения спецификаций
SSU в данный момент говорит (заметки по IPv6):
Связь Боб-Чарли и Алиса-Чарли осуществляется только через IPv4.
SSU-SPEC в данный момент говорит (Relay Request):
Нет планов по внедрению релейных устройств для IPv6.
Изменить на:
Релейные устройства для IPv6 поддерживаются с релиза 0.9.xx
SSU-SPEC в данный момент говорит (Relay Response):
IP адрес Чарли должен быть IPv4, так как это адрес, на который Алиса отправит запрос соединения после дорожного пробивания. Нет планов по внедрению релейных устройств для IPv6.
Изменить на:
IP адрес Чарли может быть IPv4 или, начиная с релиза 0.9.xx, IPv6. Это адрес, на который Алиса отправит запрос соединения после дорожного пробивания. Релейные устройства для IPv6 поддерживаются с релиза 0.9.xx
SSU-SPEC в данный момент говорит (Relay Intro):
IP адрес Алисы всегда 4 байта в текущей реализации, потому что Алиса пытается подключиться к Чарли через IPv4. Это сообщение должно быть отправлено через установленное IPv4 соединение, так как только так Боб знает IPv4 адрес Чарли, который вернется к Алисе в RelayResponse.
Изменить на:
Для IPv4, IP адрес Алисы всегда 4 байта, потому что Алиса пытается подключиться к Чарли через IPv4. Начиная с релиза 0.9.xx, поддерживается IPv6, и IP адрес Алисы может быть 16 байт.
Для IPv4, это сообщение должно быть отправлено через установленное IPv4 соединение, так как только так Боб знает IPv4 адрес Чарли, который вернется к Алисе в RelayResponse. Начиная с релиза 0.9.xx, поддерживается IPv6, и данное сообщение может быть отправлено через установленное IPv6 соединение.
Также добавить:
Начиная с релиза 0.9.xx, любой адрес SSU, публикуемый с вводными устройствами, должен содержать “4” или “6” в опции “caps”.
Миграция
Все старые роутеры должны игнорировать свойство caps в NTCP2 и неизвестные символы возможностей в свойстве caps SSU.
Любой адрес SSU с вводными устройствами, который не содержит “4” или “6” возможность считается адресом для введения через IPv4.