Кратко

  • RFC 9962 позволяет участвующим xTR совместно поддерживать карту EID—RLOC LISP. В push-варианте регистрации реплицируются multicast-рассылкой, в pull-варианте множество Map-Server находится согласованным преобразованием и DNS.
  • Карта, аутентифицированная регистрация и подтверждение обработки — ограниченные свидетельства событий плоскости управления. RFC 9301 говорит, что состояние RLOC не выражает достижимость пути с точки зрения запрашивающей стороны.

LISP разделяет Endpoint Identifier, именующий конечную точку в оверлее, и Routing Locator, несущий инкапсулированный трафик. Между ними нужен механизм отображения. В привычной схеме отдельный Mapping System Provider ведёт Map-Resolver и Map-Server, а xTR плоскости данных регистрируют или запрашивают там соответствия. RFC 9962 не делает запись картой без владельца и без суждения. Он меняет круг тех, кто хранит и отдаёт этот ограниченный факт: xTR, использующий карту, может быть и пиром, поддерживающим её.

Это изменение структуры зависимости, а не полное доказательство реального результата. Согласно RFC 9301, ETR посылает Map-Server сообщение Map-Register с префиксом EID и набором RLOC. Запросив Map-Notify, он получает подтверждение, что сервер принял и обработал регистрацию. «Принял», «обработал», «подтвердил» — это конкретные действия управления. Они не говорят, что любой запрашивающий достигнет данного RLOC, что обратный путь существует или что сервис за адресом по-прежнему годится для операционного обязательства.

RFC 9301 проводит ключевую границу: статус RLOC может сообщать достижимость, но не достижимость пути с позиции запрашивающего; нужен отдельный тест пути. Точка отправления, инкапсуляция, фильтры, обратная маршрутизация, перегрузка, переключение и политика сервиса дают разные результаты для одной и той же записи. Верная карта может вести к непригодному пути. И факт прибытия пакета к адресу не решает вопросов личности конечной точки, делового разрешения или операционного принятия.

Две конструкции RFC 9962 эту границу подчёркивают. В push-модели xTR вступают в одну multicast-группу, и Map-Register может быть доставлен всем Map-Server группы, хранящим реплицированное зарегистрированное состояние. Это даёт избыточность, но требует реально работающей multicast-основы. В pull-модели детерминированное преобразование превращает EID в DNS-имя и находит нужное множество Map-Server. Состояния реплицируется меньше, но требуется устойчивое согласие о функции, именах, модуле и масштабировании. Это не два свободно смешиваемых улучшения.

RFC 9962 требует выбрать один; при сосуществовании это всё равно дискретные системы отображения без обещания взаимной совместимости.

У аутентификации тоже есть предел. RFC 9962 ссылается на RFC 9301 и ECDSA-AUTH для доверия между xTR. RFC 9301 защищает происхождение и целостность Map-Register, применяет nonce против повтора и разрешает Map-Server отвергнуть регистрацию, не отвечающую ключам или политике. Так становится проверяемым вопрос: кто представил какую регистрацию и что сделал механизм? Но это не доказательство личности конечной точки, права обслуживать клиента, качества пути или будущей доставки. Доказательство ключом относится к акту протокола, а не ко всем последствиям.

В логике Lu Heng о минимальном начальном механизме и локализованном будущем решении значение RFC 9962 в том, что функция координации приближается к участникам, но не получает власть решать за них. Общая карта может снизить цену обнаружения и регистрации. Она не должна самим фактом существования выбирать трафик, клиентскую экспозицию, отказоустойчивость или выход. Вопрос для руководства не в благозвучии слова «децентрализованный», а в том, какая зависимость изменилась, какая запись аудируема и кто сохраняет последнее суждение.

Источники