Кратко

  • DHCPv6-PD передаёт запрашивающему маршрутизатору ответственность за использование префикса, но не описывает топологию за ним.
  • Запрашивающая сторона должна превратить аренду в стабильные дочерние префиксы и согласованные сроки, а CE — сопоставить каждую аренду с правильным следующим переходом.
  • Квитанция «от делегирования до маршрута» должна связать состояние протокола с двусторонними пакетными измерениями.

Аренда зелёная, а LAN не работает

Представим панель поддержки, где обмен IA_PD отмечен успешным. Нижестоящий маршрутизатор получил префикс, preferred lifetime и valid lifetime уменьшаются штатно, ошибок DHCPv6 нет. Тем не менее пакеты к серверу за этим маршрутизатором пропадают на клиентском пограничном устройстве. CE либо не установил маршрут делегированного префикса через нижестоящий узел, либо удалил его раньше, чем клиент прекратил использовать адреса.

Обе панели могут показывать правду. DHCPv6 поддерживает действующее делегирование, пока путь пересылки остаётся неполным. Ошибка возникает, когда успех аренды принимают одновременно за доказательство резервирования пула, назначения на канал, объявления, программирования пересылки и достижимости.

RFC 8415 чётко проводит границу. Делегирование префикса рассчитано на ситуацию, когда делегирующий маршрутизатор не знает топологию за запрашивающим. Сервер выбирает префикс и возвращает его, после чего ответственность несёт клиент. Он может разделить блок, назначить подсети интерфейсам и объявить их. Это последующие действия, которых нет в самом статусе успеха IA_PD.

Передача ответственности с временными границами

Рабочая единица — не отметка «префикс есть», а набор из идентичности клиента, IAID, точного префикса и длины, сервера, T1, T2, preferred lifetime, valid lifetime и времени наблюдения. Renew может продлить сроки, но RFC 8415 разрешает серверу изменить список префиксов или вернуть неподходящий префикс с нулевыми сроками. Нужно хранить содержимое ответа, а не только зелёный индикатор.

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

RFC 9818 добавляет требования к CE, делегирующим префиксы на интерфейсах LAN. Они должны поддерживать IA_PD внутри сети, выделять блоки из доступного пула и регистрировать ошибку управления при нехватке. Префикс канала не должен меняться без изменения политики или топологии. Главное: локальная таблица маршрутизации должна динамически следовать арендам и связанным следующим переходам, удаляя маршрут при Release или истечении срока.

Остаются независимые точки отказа: слишком малый блок сверху, непоследовательное резервирование дочернего префикса, отсутствие объявления, аренда без маршрута, чрезмерный срок дочернего блока или разные правила для прямого и обратного пути. Повторное чтение одного DHCP Reply их не устраняет.

Составить квитанцию с обеих сторон

На стороне делегирования фиксируют сервер, DUID, IAID, точный префикс, время транзакции, T1/T2, оба срока и тип события: назначение, Renew, Rebind, Release или истечение. На стороне запроса — реально выделенные дочерние префиксы, целевые каналы или маршрутизаторы, унаследованные сроки и поколение конфигурации, принявшее решение.

Затем добавляют доказательства пересылки: маршрут CE, следующий переход, интерфейс, время установки, возможный фильтр и событие удаления. Ниже по сети фиксируют локальный маршрут, Router Advertisement и ожидаемый выбор исходного адреса. Наконец, проводят пакетные и сервисные проверки в обоих направлениях. Ping с CE не покрывает DNS, фильтры с состоянием, выбор исходного адреса или асимметричный обратный путь.

Квитанцию проверяют при первом делегировании, продлении, изменении политики или топологии, а также при Release или истечении. Одинаковая строка префикса в два момента не гарантирует одинаковый следующий переход, пул, сроки, объявления и фильтры.

Не расширять область действия

Квитанция не превращает DHCPv6 в протокол топологии. Она соединяет распределённые доказательства, сохраняя разделение ответственности. Она также не решает выбор исходного адреса и политику в сети с несколькими провайдерами. RFC 9818 исключает такой сценарий из-за его сложности; оператору нужны отдельные данные о выходе, обратном пути и домене отказа.

Источники