Кратко

  • В архитектуре HIP 2006 года Robert Moskowitz и Pekka Nikander предложили идентификатор на основе открытого ключа для конечного узла, оставив IP-адрес локатором для маршрутизации.
  • Такое разделение может сохранить ассоциацию после смены адреса, если оба узла используют HIP. Оно не переносит регистрацию ресурса и не обновляет автоматически правила всех приложений.

Ноутбук отключается от одной сети, подключается к другой и получает новый IP-адрес. Путь пакетов изменился, а узел на другом конце остался прежним. Долгое время протоколы поручали одному числу сразу две роли: показывать топологическое местоположение и называть конечную точку связи. Robert Moskowitz и Pekka Nikander превратили это совмещение в явный архитектурный вопрос в RFC 4423.

Host Identity Protocol вводит отдельное пространство идентичности между интернет- и транспортным уровнями. Host Identifier здесь — открытый ключ, а Host Identity — абстрактная сущность, которую он представляет. Host Identity Tag (HIT) служит компактным 128-битным представлением. IP-адрес по-прежнему нужен: маршрутизаторам надо знать, куда направлять пакеты. Но он больше не обязан единолично определять, какому узлу принадлежит транспортная ассоциация.

Именно эта смена привязки составляет суть HIP. RFC 4423 описывает транспортные ассоциации, связанные с Host Identity. Если адрес меняется при перемещении, подключении к новой сети или перенумерации, совместимый с HIP узел может обновить локатор и сохранить ассоциацию, привязанную к идентичности. Один узел также может быть доступен через несколько интерфейсов. Часть непрерывности переносится с фиксированного адреса на криптографическое состояние, которое поддерживают участвующие конечные узлы.

История RFC помогает точно обозначить вклад Moskowitz. RFC 4423 вышла в мае 2006 года как информационный документ. В аннотации она названа снимком рассуждений авторов на осень 2003 года с оговоркой, что архитектура могла измениться; стандарт Интернета этот документ не задаёт. Более поздняя RFC 7401, редактором которой был Moskowitz вместе с другими авторами, специфицирует HIP версии 2 в категории Standards Track. Она описывает, как согласившиеся участвовать узлы создают общее состояние IP-уровня посредством четырёхпакетного криптографического обмена. В 2021 году RFC 9063, написанная Moskowitz и Miika Komu, обновила архитектуру, заменила RFC 4423 и включила опыт реализации RFC 7401, а также рассмотрела криптографическую гибкость и доверие при первом использовании.

Эта последовательность документов показывает развитие технической идеи, но не доказывает, что Интернет перестал зависеть от адресов. HIP поддерживает ассоциацию, которой управляют оба участвующих узла. Межсетевой экран может по-прежнему пропускать только конкретный IP-адрес источника. DNS может возвращать старый локатор. У второй стороны может не быть HIP. Приложение способно хранить IP в настройках или оценивать по нему репутацию. Сохранение ассоциации при смене адреса не обновляет эти состояния автоматически.

в примечании 68 Heng Lu предлагает отдельный экономический ракурс: адрес может стать памятью бизнеса, если клиенты, партнёры и службы безопасности выстраивают вокруг него ожидания. Это не описание HIP и не свидетельство его внедрения в конкретной сети. Этот взгляд помогает различить два вида непрерывности. HIP разделяет идентичность узла в обмене протокола и локатор маршрутизации, но не переписывает внешние отношения, которые сложились вокруг IP-адреса.

Работу Moskowitz точнее всего понимать как проведённую архитектурную границу: «мой маршрут может измениться, а аутентифицированная идентичность конечного узла — отдельное состояние». Эта граница полезна именно своей ограниченностью. HIP может уменьшить зависимость от неизменного адреса при мобильности и многосвязности, но DNS, маршрутизация, управление ресурсами, правила приложений и обещания непрерывности для клиентов остаются отдельными задачами.

Источники