Кратко
- RFC 10038 позволяет конечной точке сегмента SRv6 получить через DHCPv6 структурированный локатор со сроками действия, алгоритмом и полями разметки.
- Поскольку выделение может создать и анонсировать маршрут локатора, продление, освобождение и истечение аренды становятся событиями состояния маршрутизации, а не обычным обслуживанием адресов.
Аренда, на которой строится SID
В SRv6 локатор играет структурную роль. Он обозначает адресное пространство, из которого узел выделяет Segment Identifiers, и потому определяет больше, чем достижимость одного интерфейса. RFC 10038 переносит эту структуру в двух новых опциях DHCPv6. IA Locator содержит предпочтительный и действительный сроки, значение IGP Algorithm, длины блока локатора и части узла, длины Function и Argument, а также байты самого локатора.
Эти поля помещают решение на границу выделения. Клиент может заявить предпочтение, но сервер ищет в настроенном пуле локаторов и создаёт привязку согласно своей политике. Сумма структурных длин не должна превышать 128 бит, а сумма длины блока локатора и части узла не может быть равна нулю. Клиент обязан отбросить локатор, если его предпочтительный срок превышает действительный. Это факты протокола, но не свидетельство того, что конкретный продукт корректно их проверяет.
IANA назначила коды опций 149 и 150 и код состояния 23 NoSRv6LocatorAvail. Отрицательный ответ, таким образом, является определённым исходом, а не разрешением придумать локатор на месте. Спецификация не предписывает устройство пула оператора и не определяет, какая организация вправе одобрять выделение.
Переход аренды может стать переходом маршрута
Жизненный цикл следует DHCPv6: Solicit, Advertise, Request и Reply устанавливают привязку; Renew и Rebind пытаются её сохранить; Release освобождает её. Если соответствующий таймер продления истёк без ответа, клиент считает аренду истёкшей и начинает заново. При корректном освобождении или истечении сервер возвращает локатор в пул.
Далее RFC 10038 входит в область маршрутизации. Сервер или ретранслятор может установить локальный маршрут к выделенному локатору с запрашивающим клиентом в качестве следующего перехода и анонсировать его через IGP. Освобождение требует удалить локальный маршрут и отозвать прежний анонс. Локаторы с Algorithm 0 могут использовать обычную IP-достижимость; для ненулевого Algorithm необходимы TLV локатора, определённые для IS-IS или OSPFv3.
Операционный вывод статьи состоит в том, что журнал аренды, запись RIB и анонс IGP представляют одно решение о полномочиях. Однако в реализации они способны разойтись. Успешный ответ DHCP не доказывает, что маршрут установлен, распространён, запрограммирован в плоскости пересылки или доступен от конца до конца. И наоборот, маршрут, оставшийся после истечения привязки, сохранял бы видимость достижимости после прекращения полномочия на выделение. Мы не утверждаем, что такой сбой произошёл в какой-либо названной сети.
Агрегация меняет форму отказа
RFC 10038 отмечает компромисс устойчивости. Анонс агрегатов может уменьшить колебания RIB при изменении отдельных аренд. Однако отозванный конкретный локатор может остаться покрытым агрегатом; трафик к префиксу, который больше не делегирован клиентскому интерфейсу, тогда может быть отброшен на нём. Агрегат сохраняет грубую достижимость, хотя конкретное полномочие уже исчезло.
Для мониторинга это различие существенно. Считать агрегат доказательством действительности всех локаторов под ним — значит спутать маршрутное резюме с состоянием базовых аренд. Оператору нужны оба представления: политика агрегации, защищающая RIB, и состояние отдельной привязки, объясняющее, должен ли конкретный локатор по-прежнему завершаться на конкретной конечной точке.
Безопасность начинается с права выделять
RFC 10038 наследует соображения безопасности DHCP и прямо отмечает отсутствие сквозного шифрования между клиентами и серверами DHCP. Там, где нет иных средств защиты, возможны перехват, изменение и прослушивание. Документ также предупреждает, что смешанные механизмы выделения могут назначить один локатор нескольким устройствам. Разделение пулов между механизмами — одна из мер снижения риска.
Стандарт не превращает обмен DHCP в доказательство организационного разрешения. Такое доказательство остаётся локальным: какому серверу и ретранслятору доверяли, какую идентичность клиента допустили, какие пул и алгоритм одобрили и какая запись об изменении объясняет привязку. Протокольная корректность и управленческое полномочие — разные виды доказательств.
Источники
Обзор для участников
Подробный контекст профиля
Войдите с подходящим уровнем подписки, чтобы открыть полный обзор и примечания к источникам.
Только для Стратегического сообщества
Стратегическое сообщество
Открыто всем читателям. Вступите и войдите, чтобы открыть обзоры профилей.
Вступить в Стратегическое сообществоТолько для Альянса лидеров
Альянс лидеров
Для проверенных владельцев IP-активов и руководителей. Войдите, чтобы открыть обзоры Альянса.
Вступить в Альянс лидеров
