Кратко

  • LISP разделяет семантику EID и RLOC, но успешная доставка требует их авторизованной регистрации, разрешения через Mapping System, неистёкшей записи Map-Cache, выбора по Priority и Weight, маршрута underlay и последней внутренней пересылки после декапсуляции.
  • David Meyer — один из нескольких соавторов исходного и нынешнего стандартов плоскости данных. Его роль позволяет проследить, как архитектурная идея получила часы, права и процедуры схождения, но не делает его единственным изобретателем или владельцем LISP.

Стабильность начинается с подвижного сведения

Слово «идентификатор» обещает постоянство. Если сервис меняет подключение или предпочитаемого провайдера, хочется оставить знакомое значение и исправить только маршрут. В обычном IP одна и та же адресная структура помогает назвать узел и расположить его в топологии. Изменение одной функции затрагивает другую.

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

RFC 9299 формулирует ответ LISP. EID и RLOC синтаксически выглядят как IPv4- или IPv6-адреса, но принадлежат разным смысловым пространствам. EID называет конечный узел независимо от междоменного положения. RLOC обозначает топологическую точку подключения в underlay. Mapping System хранит соответствие, а туннельные маршрутизаторы инкапсулируют пакет к выбранному RLOC.

Положение удаляется из идентификатора, но возникает как отдельное, изменяемое сведение. Его устойчивость приходится поддерживать чаще, чем сам EID.

Что происходит после назначения EID

RFC 9300 требует уникальности публичного EID и его выделения из префикса, связанного с площадкой. Это не документ о собственности, не аутентификация человека, не обещание переносимости между операторами и не признак действующей регистрации.

ETR связывает EID-Prefix с одним или несколькими RLOC и передаёт Map-Register на Map-Server. Сервер должен знать, какие префиксы имеет право регистрировать этот ETR. Для аутентификации стороны заранее настраивают общий секрет. RFC 9301 предупреждает, что отсутствие проверки полномочий открывает тривиальный захват префикса.

Отправляющий ITR выполняет longest-prefix match по EID в своём Map-Cache. При совпадении он получает Locator-Set. При промахе запрос идёт через Map-Resolver. Пока ответ не пришёл, реализация может отбросить или буферизовать пакеты. Следовательно, даже одинаково совместимые узлы способны по-разному переживать неизвестное положение.

Ответ имеет TTL. Ноль требует немедленного удаления, специальное значение позволяет получателю самому определить срок. Cache содержит и сведения о достижимости. Новая авторитетная регистрация и новая рабочая копия на каждом ITR появляются не одновременно.

RLOC выбирается не только по наличию. Меньшая Priority предпочтительнее; 255 запрещает пересылку. При равном приоритете Weight распределяет поток. Можно не менять EID и набор адресов, но изменить фактическое направление большей части трафика одним весом.

Затем underlay обязан доставить внешний пакет к RLOC. ETR снимает оболочку и пересылает внутренний пакет внутри площадки. Верная карта не доказывает маршрут underlay; достижение RLOC не доказывает последнее плечо до EID.

Разные часы одной карты

Регистрация периодически продлевается и может быть удалена, если действительный Map-Register перестаёт приходить. Negative Map-Reply с пустым набором локаторов различает отсутствие регистрации, запрет политики и сбой аутентификации. Она может предписать нативную пересылку, новый запрос, бездействие или отбрасывание. Объединять эти причины в одну ошибку опасно.

При изменении соответствия Solicit-Map-Request предлагает ITR, у которых уже есть cache, запросить свежую запись. Обе стороны ограничивают частоту. ITR без такой записи не должен обновляться заранее. Это управляемое схождение активных копий, а не мгновенная очистка всей сети.

RFC 9302 показывает проблему в закрытой доверенной среде через необязательную двенадцатибитную Map-Version. Добавление и удаление RLOC, изменение Priority или Weight, а также локальной достижимости меняют версию. Счётчик циклический, поэтому старое значение может показаться новым; нужно ждать по меньшей мере прежний TTL или подтверждать переход активного трафика.

На публичном Интернете RFC 9300 запрещает применять Map-Versioning, gleaning, Locator-Status-Bits и Echo-Nonce как сокращённое доказательство обновления или достижимости. Там требуются механизмы control plane. Доверенный сигнал имеет чёткую область применимости.

Полномочие предшествует криптографии

Модель RFC 9301 считает Mapping System защищённым и доверенным, а связь с ETR — заранее настроенной. Система знает, какие EID ему разрешено объявлять. Создание ключей и прав остаётся за пределами документа. Протокол может проверить предоставленное полномочие, но не способен сам решить, кому оно принадлежит.

RFC 9303 определяет обязательный для рассматриваемых публичных применений LISP-SEC. Он обеспечивает аутентификацию источника, целостность, защиту от повтора и проверку права заявлять EID-Prefix. Это препятствует перенаправлению и overclaiming более широкого диапазона. Однако остаются допущения: Mapping System доставляет запрос предназначенному ETR, а Map-Server проверяет право при регистрации.

Защищается связь EID с RLOC, а не «личность» числа. Долгоживущий EID создаёт и приватностный компромисс: последовательность связанных с ним RLOC может показать топологические перемещения. Отсутствие перенумерации и отсутствие слежения — разные цели.

Meyer как участник длинного пересмотра

Под RFC 9300 стоят Dino Farinacci, Vince Fuller, Dave Meyer, Darrel Lewis и редактор Albert Cabellos. Meyer участвовал и в RFC 6830. Повторная авторская работа важна как временная перспектива, а не основание приписать LISP одному человеку. Консенсус IETF, код, Mapping System и эксплуатация имеют разных владельцев.

Историческая страница ONUG упоминает работу Meyer в Cisco и Brocade, участие в IAB и программном комитете NANOG, а также RouteViews в University of Oregon. Это сведения своего периода, не текущая должность. Они показывают устойчивый интерес к границе между абстрактной плоскостью управления и доступным оператору наблюдением.

Уже опубликованная статья о Meyer посвящена RouteViews, RPSL и OpenDaylight — публичной видимости маршрутизации. Здесь другой вопрос: кто вправе записать связь идентификатора с положением, сколько её копия сохраняет силу и какие проверки остаются после успешного Map-Reply.

Experimental-руководство RFC 7215 завершает доказательную цепь. Его миграционный перечень проверяет платформу, конфигурацию, MTU, выделение префикса, достижимость RLOC, регистрацию и ключ, proxy-cache, политики BGP, внешнюю видимость и реальный трафик. Некоторые механизмы относятся к переходу 2014 года, но вывод не устарел: спецификация не равна настройке, настройка — регистрации, регистрация — доставке.

LISP не освобождает EID от инфраструктуры. Он позволяет инфраструктуре продолжать признавать один EID при смене места. Эта возможность существует ровно столько, сколько уполномоченные участники поддерживают карту свежей и доказывают путь до конца.

Источники