Кратко

  • RFC 1924 представлял все 128 бит IPv6-адреса одним целым числом и кодировал его двадцатью знаками по основанию 85. Обратимость сохраняла значение, но не обеспечивала узнаваемость, индексирование и совместимость инструментов.
  • Девять печатных знаков намеренно не вошли в алфавит, чтобы остаться доступными для кавычек, списков, предложений, CIDR, URL, скобок и экранирования. Внешняя грамматика была частью задачи.
  • Более поздние документы сохранили двоеточия и шестнадцатеричные группы, ввели квадратные скобки для URI и рекомендовали канонический вывод. Совпадение записи облегчает проверку, но не доказывает назначение, маршрут, доступность, личность или доставку.

Одинаковые биты, разные следы

Оператор получает адрес из заявки и вставляет его в поиск по журналу. Ответ пуст. Запись существует, однако система напечатала те же 128 бит в Base85. Декодер способен установить равенство, но обычный текстовый индекс сравнивает поверхность. Точная сериализация не стала общей уликой.

RFC 1924 был опубликован 1 апреля 1996 года в категории Informational и не устанавливал стандарт Интернета. Предлагалось считать адрес одним беззнаковым целым и записывать его алфавитом из 85 печатных ASCII-знаков. В примере 1080:0:0:0:8:800:200C:417A превращался в 4)+k&C#VzJ4br>0wv%Yp. Результат всегда занимал двадцать позиций и сохранял ведущие нули.

Потерь в преобразовании нет. Но обратимость обещает лишь то, что правильная программа восстановит число. Она не устанавливает, распознает ли строку человек, отделит ли её URI-парсер, сведёт ли варианты таблица, сохранит ли журнал и существует ли декодер на каждом промежуточном узле.

Основание 85 было минимальным порогом

В пространстве IPv6 (2^{128}) значений. Двадцать разрядов по основанию 84 недостаточны, а по основанию 85 достаточны: (84^{20} < 2^{128} \leq 85^{20}). Даже основания 94 и 95 всё равно потребовали бы двадцать разрядов. Поэтому можно было оставить девять печатных символов внешней синтаксической среде, не увеличивая длину.

Фиксированная ширина полезна. Размер поля известен заранее, ведущие нули не исчезают, отсутствуют варианты сжатия нулевых групп. Если граница поля уже задана, а все стороны умеют декодировать формат, запись компактна и однозначна.

Однако список исключений показывает, как редко адрес бывает изолирован. Из алфавита убрали оба вида кавычек, запятую, точку, косую черту, двоеточие, две квадратные скобки и обратную косую черту. Они нужны для цитат, перечислений, конца предложения, суффикса CIDR, URL, границ литерала и экранирования. Внутренняя плотность зависела от способности внешнего языка не потерять границу.

Узнаваемая форма не была канонической

Ранняя архитектура IPv6 задавала восемь шестнадцатеричных 16-битных групп через двоеточие. Разрешалось опускать ведущие нули, один раз сжимать последовательность нулевых групп как :: и использовать десятичный хвост IPv4. Один адрес получал несколько допустимых записей, хотя двоеточия и группы сохраняли узнаваемый силуэт.

Эта гибкость вредила машинному сравнению. Поиск одной формы пропускал другую, таблица создавала дубликаты, Whois, схема и журнал выглядели противоречиво. Base85 устраняла варианты заменой всей поверхности. Последующий путь стандартов сохранил поверхность и ограничил варианты вывода.

Конфликт с URL решили локально. Двоеточия IPv6 пересекались с внешним синтаксисом, поэтому RFC 2732 окружил литерал квадратными скобками. В документе прямо ставилась цель удобного копирования с минимальным редактированием и отмечались реализации в IPv6-версиях Internet Explorer, Mozilla и Lynx. RFC 3986 затем сохранил скобочный IP-literal.

Широкий приём, узкий вывод

RFC 4291 оставил гибкие шестнадцатеричные формы. RFC 5952 позднее перечислил проблемы множества законных записей в поиске, текстовых файлах, таблицах, Whois, диаграммах, журналах, аудите и проверке. Решение разделило обязанности: парсеры должны принимать все допустимые формы RFC 4291, а форматтеры — выдавать каноническую.

При выводе удаляются ведущие нули, используются строчные шестнадцатеричные буквы, :: сжимает самую длинную нулевую последовательность, при равенстве выбирается первая, а одиночная нулевая группа не сжимается. Это не всегда самая короткая мыслимая строка. Зато два независимых устройства с большей вероятностью оставят одинаковый видимый след.

Так сохраняется совместимость старых входов и улучшается сравнимость новых записей. Скобки отвечают за внешнюю границу URI, нормализация — за внутреннюю форму. Ни одна мера не пытается решить чужую задачу.

У доказательства шесть ступеней

Сначала идут 128 бит, затем распознанное значение, нормализованное отображение, фактически сохранённая строка, результат поиска и наблюдаемое сетевое событие. Равенство на одной ступени не даёт полномочий следующей. Две строки, декодируемые в одно число, доказывают эквивалентность представления. Одинаковый канонический вывод подтверждает соглашение форматтеров. Журнал говорит, что компонент записал строку.

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

Первичные документы — RFC 1884, RFC 1924, RFC 2732, RFC 3986, RFC 4291 и RFC 5952. Это спецификации, а не перепись внедрений: они не доказывают отсутствие реализаций Base85 и не фиксируют её формальное отклонение поздними авторами.

Running-Code Primacy даёт более позднюю дисциплину чтения: проверять, что реальные парсеры, журналы и процессы принимают и сохраняют. Minimum Initial Specification, Localized Future Decision, and Voluntary Adoption помогает понять, почему небольшой общий контракт оставляет место локальным решениям. Оба текста являются поздним анализом, а не свидетельством намерений авторов RFC.

Двадцать знаков RFC 1924 вместили адрес целиком. В них не поместилось соглашение о том, как этот адрес будут узнавать, искать и предъявлять как доказательство.