Кратко

  • LSI обозначает Host Identity только внутри локального контекста выделившего его узла; похожая на IPv4 форма не переносит этот контекст на другую машину.
  • Выделение, HIT, локаторы, выбор пути, HIP-ассоциация, защищённый трафик, результат приложения и аудиторская корреляция должны оставаться отдельными квитанциями.

Архив сохранил оболочку и потерял полномочие

В журнале старого приложения записано число, похожее на IPv4-адрес. Через неделю аналитик сопоставляет его с текущей таблицей HIP и получает Host Identity. Вывод выглядит точным: вот кто участвовал в соединении.

Но таблица могла пережить сбор мусора, перезапуск или повторное выделение. В момент события тот же LSI обозначал другую идентичность. Текущая таблица не восстановила прошлое, а приписала ему нового субъекта.

RFC 5338 показывает, почему совместимый формат недостаточен для доказательства. Старые приложения используют адрес как краткий дескриптор, долговременную связь, callback, referral и тест идентичности. Локальная подстановка может быть корректна в первом случае и недействительна в остальных.

LSI указывает на состояние узла, а не на маршрут

В RFC 5338 Local Scope Identifier — это 32- или 128-битное локальное представление Host Identity в IPv4- или IPv6-API. RFC 9063 уточняет: типичный 32-битный LSI преобразуется в HIT слоем HIP или обработчиком сокетов и не передаётся по сети как локатор.

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

Успешный локальный connect() означает, что эта машина прочла свою таблицу в этот момент. Он не утверждает, что другая машина понимает значение, что запись переживёт перезапуск, что локаторы актуальны или что приложение завершило операцию.

DNS-посредник создаёт локальный вход, а не мировой адрес

RFC 5338 рассматривает локального агента DNS, который при наличии HIP-данных возвращает приложению LSI или HIT вместо обычного адреса. Система хранит связь и преобразует значение около границы системного вызова.

Здесь легко склеить разные факты. Каталог сообщил данные идентичности. Хост выбрал представление и выделил дескриптор. Затем требовались локаторы, выбор попытки, HIP-обмен, защищённые пакеты и ответ сервиса. Первый факт не выдаёт квитанцию за последний.

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

Если политика требует HIP, она должна ограничить варианты или зарегистрировать победившую попытку. Иначе отчёт о соответствии описывает намерение конфигурации, а не транспорт конкретной операции.

Referral переносит ключ без таблицы

Пусть B использует LSI для A и сообщает этот «адрес» C. У C нет таблицы B. Он получил локальный ключ, но не получил Host Identity A и способ её разрешения.

Явный отказ хотя бы виден. Опаснее случайное принятие: C считает значение обычным IPv4 или уже связал такой LSI с другим peer. Синтаксис остаётся корректным, запрос достигает не того субъекта.

Протокол referral должен нести имя, разрешимое получателем: HIT с механизмом поиска, проверяемое доменное имя либо объект с идентичностью, издателем, областью и сроком. Если посредник преобразует LSI, в квитанции нужно сохранить факт посредничества. Перевод не делает исходный индекс глобальным.

RFC 9063 сопоставляет проблему с host-based NAT. Приложения, встраивающие локальные адреса в сообщения, уже нарушают слой и ломаются на границе трансляции. HIP не создаёт эту задолженность; он отделяет идентичность от местоположения и тем самым делает её заметной.

Долгий кэш и короткое отображение живут по разным часам

Старое приложение может держать результат DNS дольше, чем HIP-система считает допустимым для LSI. RFC 5338 отмечает трудность garbage collection таких связей. Раннее повторное использование опасно для старых потребителей; вечное хранение раздувает состояние.

Нужна явная эпоха. Для исполнения она предотвращает перепривязку старого дескриптора. Для расследования она запрещает сопоставлять вчерашнее число с сегодняшней записью. Время события и поколение таблицы становятся частью имени.

RFC 5338 рекомендует совместно журналировать HIT, LSI, соответствующие IP-адреса и FQDN-контекст. Практический набор добавляет локальный узел, загрузку или поколение, процесс, сокет и решение политики. Только так можно объяснить, что именно слой совместимости полагал истинным.

Но это ещё не квитанция сервиса. Состояние отображения, завершение HIP-ассоциации, защищённый поток и прикладной ответ доказываются разными событиями. Корреляция связывает их; она не должна стирать границы.

Явный HIT усиливает имя, но не завершает операцию

Обычный connect(ip) может означать лишь «соедини меня с системой, доступной сейчас по этому адресу». Локальная политика способна добавить HIP, однако исходный запрос приложения не обязательно строго назвал конкретную Host Identity.

Явный HIT задаёт более сильную криптографическую идентичность. Всё равно нужны поиск локаторов, завершение обмена, установка состояния, данные и ответ приложения. Имя не подтверждает текущий секретный ключ само по себе, не выдаёт прикладное разрешение и не резервирует ресурс.

Так статья остаётся отличной от опубликованных границ HIP DNS, RVS, mobility и ESP. Здесь исследуется полномочие адресоподобного символа на границе старого API, а не последующие этапы протокола.

Wildcard-сервер оставляет выбор идентичности политике

Старый сервер часто bind-ится к wildcard. Если у хоста несколько Host Identities, а приложение не указало конкретную, выбор делает локальная политика. RFC 5338 приводит UDP-сценарий, где после recvfrom() вызов sendto() выбирает другой серверный HIT, и клиент отбрасывает ответ.

Успешный bind доказывает наличие слушателя, но не непрерывность идентичности входа и выхода. Наблюдаемость должна хранить входной локальный HIT, выбранный выходной HIT и правило. Если сервис не поддерживает множественность, разумно публиковать лишь идентичность, совпадающую с выходом по умолчанию.

Источники и граница доказательств

Источники устанавливают спецификации, заявленную архитектуру и исторический отчёт об экспериментах. Они не доказывают нынешний продукт, внедрение, инцидент, затронутую организацию или измеренную частоту отказов.