Примечание
Это предложение не было реализовано в указанном виде, однако длинные и короткие сообщения о создании ECIES (предложения 152 и 157) были разработаны с полями расширяемых опций. См. спецификацию Tunnel Creation ECIES для официальной спецификации.
Обзор
Добавить гибкий, расширяемый механизм для опций в записях создания туннеля I2NP, которые содержатся в сообщениях о создании туннеля и ответах на создание туннеля.
Мотивация
Появляются несколько предварительных, не задокументированных предложений по установке опций или конфигурации в сообщении о создании туннеля, так что создатель туннеля может передать некоторые параметры каждому узлу туннеля.
В TBM имеется 29 свободных байт. Мы хотим сохранить гибкость для будущих улучшений, но также разумно использовать это пространство. Использование конструкции «mapping» займет минимум 6 байт на опцию (“1a=1b;”). Жесткое определение большего количества полей опций может вызвать проблемы позже.
Этот документ предлагает новую, гибкую схему отображения опций.
Дизайн
Нам нужна репрезентация опций, которая компактна и в то же время гибка, чтобы мы могли разместить несколько опций, разной длины, в 29 байтах. Эти опции еще не определены и не требуется, чтобы они были определены в данный момент. Не используйте структуру «mapping» (которая кодирует объект Java Properties), это слишком расточительно. Используйте число для указания каждой опции и длины, что приводит к компактному, но гибкому кодированию. Опции должны быть зарегистрированы по номеру в наших спецификациях, но мы также зарезервируем диапазон для экспериментальных опций.
Спецификация
Предварительно - ниже описаны несколько альтернатив.
Это будет представлено только если бит 5 во флагах (байт 184) установлен в 1.
Каждая опция представлена номером опции и длиной в два байта, за которыми следуют длина байтов значения опции.
Опции начинаются с байта 193 и продолжаются до последнего байта 221.
Число/длина опции:
Два байта. Биты 15-4 — это 12-битовый номер опции, 1 - 4095. Биты 3-0 — это количество байтов значения опции, которые будут следовать, от 0 до 15. Булева опция может иметь ноль байтов значения. Мы будем вести реестр номеров опций в наших спецификациях, а также определим диапазон для экспериментальных опций.
Значение опции от 0 до 15 байтов, интерпретируется тем, кто нуждается в этой опции. Неизвестные номера опций следует игнорировать.
Опции завершаются числом/длиной опции 0/0, то есть двумя байтами 0. Оставшиеся из 29 байтов, если таковые имеются, должны быть заполнены случайной подкладкой, как обычно.
Это кодирование дает нам место для 14 опций с 0 байт, или 9 опций с 1 байтом, или 7 опций с 2 байтами. Альтернативой было бы использовать только один байт для числа/длины опции, возможно, с 5 битами для номера опции (максимум 32) и 3 битами для длины (максимум 7). Это увеличило бы емкость до 28 опций с 0 байтами, 14 опций с 1 байтом или 9 опций с двумя байтами. Мы также могли бы сделать его переменным, где 5-битный номер опции 31 означает чтение еще 8 битов для номера опции.
Если узлу туннеля нужно вернуть опции создателю, мы можем использовать тот же формат в сообщении-ответе на создание туннеля, с префиксом в виде магического числа из нескольких байт (так как у нас нет определенного байта флага, чтобы указать, что опции присутствуют). В TBRM имеется 495 свободных байтов.
Примечания
Эти изменения касаются записей о создании туннеля и поэтому могут использоваться во всех вариантах сообщений о создании - Запрос на создание туннеля, Запрос на создание переменного туннеля, Ответ на создание туннеля и Ответ на создание переменного туннеля.
Миграция
Неиспользуемое пространство в записях о создании туннелей заполняется случайными данными и в настоящее время игнорируется. Пространство может быть преобразовано для содержания опций без проблем с миграцией. В сообщении о создании присутствие опций указывается в байте флага. В сообщении-ответе о создании присутствие опций указывается многобайтовым магическим числом.