Кратко

  • RFC 3634 определяет CCC sub-option 10 как один или несколько IPv4-адресов KDC блоками по четыре октета; несколько адресов идут в порядке убывания приоритета. Realm, transport, port, health и identity отсутствуют.
  • Получение DHCP, установка списка, выбор, сетевой контакт, проверка KDC, выдача ticket, аутентификация приложения и результат SNMPv3 требуют разных квитанций.
  • Возврат и переключение надо контролировать через версию списка, причину выбора, класс ошибки, предел retry, запас мощности следующего KDC и проверку realm.

Конфигурация стареет молча

RFC 3634 решал задачу CableHome: передать residential gateway адрес KDC для начала Kerberos перед защищённым SNMPv3. Поле содержит code 10, length и хотя бы один IPv4-адрес. Длина — не меньше четырёх и кратна четырём; серверы перечисляются от большего приоритета к меньшему.

В поле нет времени измерения или срока свежести. Нет realm, транспорта, порта, веса, сертификата, server principal или результата ticket. Даже корректно полученный список может пережить изменение маршрута, ротацию KDC и новую политику клиента.

RFC 3495 отдельно кодирует realm и параметры AS/AP retry/backoff. Эти факты находятся рядом, но не внутри адреса.

Порядок не определяет поведение клиента

RFC 3634 не завершает алгоритм: сколько ждать, какие ошибки разрешают следующий адрес, как долго помнить отказ и когда вернуться к первому. Разные реализации получают одинаковый список и создают разные временные шкалы.

RFC 4120 использует в DNS SRV service, transport, realm, TTL, priority, weight, port и target. RFC 2782 задаёт выбор, но подчёркивает статическую природу weight: это не динамический датчик нагрузки. Значит, даже более богатая запись не является health probe.

RFC 6784 позднее разделил priority, weight, transport, port, IPv6 address и realm для DHCPv6. Он показывает независимость измерений, но не расширяет старый формат задним числом.

Защита доверия не отменяет задержку

RFC 3634 полагается на безопасность DHCP. Ошибочный адрес способен перенаправить трафик и вызвать DoS. CMTS-фильтры, сертификаты, взаимная Kerberos-аутентификация, сегментация и firewall описаны как меры или предположения.

Если ложный KDC будет отвергнут, криптографическая граница сработает. Но клиент уже потратил время и вычисления. Для множества устройств одинаковая ошибка синхронизирует тайм-ауты и переносит нагрузку на следующий сервер. Безопасный отказ остаётся операционным событием.

Разрешённый источник конфигурации также не доказывает правильный realm и институциональную роль. Канал распределения и личность сервиса — разные отношения.

Восемь независимых фактов

Сначала сохраняются DHCP server, validation, transaction, lease/configuration epoch и raw bytes. Затем — факт установки. Квитанция выбора содержит hash списка, позицию, попытку, дедлайн, предыдущую ошибку и правило перехода.

Далее фиксируются route, transport, port и contact. После них — KDC identity, realm, clock и cryptographic result. AS/TGS, ticket, AP, security association и SNMP operation идут отдельными шагами.

DHCPACK не является ticket. Ticket не является успехом приложения. Защищённый канал не является выполненной операцией управления.

Граница доказательств

Статья не называет оператора, gateway, CMTS, KDC, realm, пользователя, инцидент или внедрение. Standards Track и IANA code 10 доказывают спецификацию и регистрацию, не использование.

RFC 3634 — основной источник; RFC 3495 — контекст CCC; RFC 2131/3118 разделяют доставку и аутентификацию DHCP; RFC 4120/2782 дают сравнение discovery; RFC 6784 — поздняя линия; RFC 5021/6251 отделяют transport и TLS.

Тексты Heng Lu о running code, минимальной спецификации, authority и reality layers используются как явно обозначенные аналитические рамки. Они помогают не смешивать декларацию, полномочие, исполнение и результат, но не доказывают историческое намерение или deployment.

Первый адрес имел приоритет в списке. Проверенным он становился только в последующих событиях.

Sources