Примечание
Сетевое развертывание и тестирование в процессе. Возможны незначительные правки.
Обзор
В данном предложении описывается реализация улучшений транспортов SSU и NTCP2 для IPv6.
Мотивация
По мере роста использования IPv6 по всему миру и увеличения числа конфигураций только с IPv6 (особенно на мобильных устройствах), нам необходимо улучшить поддержку IPv6 и устранить предположения о том, что все маршрутизаторы поддерживают IPv4.
Проверка соединения
При выборе пиров для туннелей или выборе путей OBEP/IBGW для маршрутизации сообщений полезно определить, может ли маршрутизатор A подключиться к маршрутизатору B. В общем случае это означает определение, имеет ли A исходящую возможность для транспорта и типа адреса (IPv4/v6), которая соответствует одному из входящих адресов B.
Однако во многих случаях мы не знаем возможностей A и вынуждены делать предположения. Если A скрыт или находится за брандмауэром, адреса не публикуются, и у нас нет прямых сведений — поэтому мы предполагаем, что он поддерживает IPv4, но не поддерживает IPv6. Решение — добавление двух новых «возможностей» (caps) в информацию о маршрутизаторе для указания исходящей поддержки IPv4 и IPv6.
IPv6-интродьюсеры
Наши спецификации для SSU содержат ошибки и несоответствия относительно того, поддерживаются ли IPv6-интродьюсеры для IPv4-интродукций. В любом случае, это никогда не было реализовано ни в Java I2P, ни в i2pd. Это необходимо исправить.
IPv6-интродукции
Наши спецификации для SSU чётко указывают, что IPv6-интродукции не поддерживаются. Это было основано на предположении, что IPv6 никогда не блокируется брандмауэром. Очевидно, что это неверно, и нам нужно улучшить поддержку маршрутизаторов IPv6, находящихся за брандмауэром.
Диаграммы интродукций
Условные обозначения: —– — IPv4, ====== — IPv6
Текущая, только IPv4:
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
Интродукция по IPv4, интродьюсер по IPv6:
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ----------->
<-------------------------------------------- HolePunch
SessionRequest -------------------------------------------->
<-------------------------------------------- SessionCreated
SessionConfirmed ------------------------------------------>
Data <--------------------------------------------------> Data
Интродукция по IPv6, интродьюсер по IPv6:
Alice Bob Charlie
RelayRequest ======================>
<============== RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
Интродукция по IPv6, интродьюсер по IPv4:
Alice Bob Charlie
RelayRequest ---------------------->
<-------------- RelayResponse RelayIntro ===========>
<============================================ HolePunch
SessionRequest ============================================>
<============================================ SessionCreated
SessionConfirmed ==========================================>
Data <==================================================> Data
Проектирование
Требуется реализовать три изменения.
- Добавить возможности «4» и «6» в свойства возможностей адреса маршрутизатора для указания исходящей поддержки IPv4 и IPv6
- Добавить поддержку IPv4-интродукций через IPv6-интродьюсеров
- Добавить поддержку IPv6-интродукций через IPv4 и IPv6-интродьюсеров
Спецификация
Возможности 4/6
Изначально это было реализовано без формального предложения, но оно необходимо для IPv6-интродукций, поэтому мы включаем его здесь.
Определяются две новые возможности: «4» и «6». Эти новые возможности будут добавлены в свойство «caps» в адресе маршрутизатора, а не в возможности в информации о маршрутизаторе. В настоящее время у нас нет определённого свойства «caps» для NTCP2. Адрес SSU с интродьюсерами по определению сейчас является ipv4. Мы вообще не поддерживаем ipv6-интродукцию. Однако это предложение совместимо с IPv6-интродукциями. См. ниже.
Кроме того, маршрутизатор может поддерживать соединение через оверлейную сеть, например I2P-over-Yggdrasil, но не желает публиковать адрес, или этот адрес не имеет стандартного формата IPv4 или IPv6. Новая система возможностей должна быть достаточно гибкой для поддержки таких сетей.
Определяются следующие изменения:
NTCP2: Добавить свойство «caps»
SSU: Добавить поддержку адреса маршрутизатора без хоста или интродьюсеров, чтобы указать исходящую поддержку IPv4, IPv6 или обоих.
Оба транспорта: Определить следующие значения возможностей:
- «4»: поддержка IPv4
- «6»: поддержка IPv6
Несколько значений могут поддерживаться в одном адресе. См. ниже. По крайней мере одно из этих значений обязательно, если в адресе маршрутизатора отсутствует значение «host». Максимум одно из этих значений является необязательным, если в адресе маршрутизатора указано значение «host». В будущем могут быть определены дополнительные возможности транспорта для указания поддержки оверлейных сетей или другой связности.
Примеры использования и примеры
SSU:
SSU с хостом: 4/6 необязательны, никогда не более одного. Пример: SSU caps=“4” host=“1.2.3.4” key=… port=“1234”
Только исходящая поддержка SSU для одного, другой опубликован: Только возможности, 4/6. Пример: SSU caps=“6”
SSU с интродьюсерами: никогда не комбинируются. Требуется 4 или 6. Пример: SSU caps=“4” iexp0=… ihost0=… iport0=… itag0=… key=…
Скрытый SSU: Только возможности, 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, и связь между Alice и Bob может осуществляться по IPv4 или IPv6.
Добавить следующее:
Хотя спецификация была изменена начиная с версии 0.9.8, связь между Alice и Bob по IPv6 фактически не поддерживалась до версии 0.9.50. Более ранние версии Java-маршрутизаторов ошибочно публиковали возможность «C» для IPv6-адресов, несмотря на то, что они фактически не работали как интродьюсеры по IPv6. Поэтому маршрутизаторы должны доверять возможности «C» на IPv6-адресе только в том случае, если версия маршрутизатора 0.9.50 или выше.
В спецификации SSU сейчас сказано (Relay Request):
IP-адрес включается только в том случае, если он отличается от исходного адреса и порта пакета. В текущей реализации длина IP всегда 0, а порт всегда 0, и получатель должен использовать исходный адрес и порт пакета. Это сообщение может быть отправлено по IPv4 или IPv6. Если по IPv6, Alice должна включить свой IPv4-адрес и порт.
Добавить следующее:
IP и порт должны быть включены для интродукции IPv4-адреса при отправке этого сообщения по IPv6. Это поддерживается начиная с версии 0.9.50.
IPv6-интродукции
Все три сообщения ретрансляции SSU (RelayRequest, RelayResponse и RelayIntro) содержат поля длины IP, указывающие длину IP-адреса (Alice, Bob или Charlie), следующего далее.
Следовательно, изменения формата сообщений не требуются. Требуются только текстовые изменения в спецификациях, указывающие, что разрешены 16-байтные IP-адреса.
Требуются следующие изменения в спецификациях. Мы также описали это как «часть 2» предложения.
Изменения спецификации
В спецификации SSU сейчас сказано (заметки по IPv6):
Связь Bob-Charlie и Alice-Charlie осуществляется только по IPv4.
В спецификации SSU сейчас сказано (Relay Request):
Не планируется реализация ретрансляции для IPv6.
Изменить на:
Ретрансляция для IPv6 поддерживается начиная с версии 0.9.xx
В спецификации SSU сейчас сказано (Relay Response):
IP-адрес Charlie должен быть IPv4, так как это адрес, на который Alice отправит SessionRequest после Hole Punch. Не планируется реализация ретрансляции для IPv6.
Изменить на:
IP-адрес Charlie может быть IPv4 или, начиная с версии 0.9.xx, IPv6. Это адрес, на который Alice отправит SessionRequest после Hole Punch. Ретрансляция для IPv6 поддерживается начиная с версии 0.9.xx
В спецификации SSU сейчас сказано (Relay Intro):
IP-адрес Alice всегда 4 байта в текущей реализации, потому что Alice пытается подключиться к Charlie по IPv4. Это сообщение должно быть отправлено по установленному IPv4-соединению, так как только так Bob узнаёт IPv4-адрес Charlie, чтобы вернуть его Alice в RelayResponse.
Изменить на:
Для IPv4 IP-адрес Alice всегда 4 байта, потому что Alice пытается подключиться к Charlie по IPv4. Начиная с версии 0.9.xx, поддерживается IPv6, и IP-адрес Alice может быть 16 байт.
Для IPv4 это сообщение должно быть отправлено по установленному IPv4-соединению, так как только так Bob узнаёт IPv4-адрес Charlie, чтобы вернуть его Alice в RelayResponse. Начиная с версии 0.9.xx, поддерживается IPv6, и это сообщение может быть отправлено по установленному IPv6-соединению.
Также добавить:
Начиная с версии 0.9.xx, любой опубликованный SSU-адрес с интродьюсерами должен содержать «4» или «6» в опции «caps».
Миграция
Все старые маршрутизаторы должны игнорировать свойство caps в NTCP2 и неизвестные символы возможностей в свойстве caps SSU.
Любой SSU-адрес с интродьюсерами, не содержащий возможности «4» или «6», считается предназначенным для IPv4-интродукции.