В основном, написано про то как собирать и отслеживать уже существующую информацию, про
Radius accounting, логирование, про безопасность и авторизацию, которая реализуется NAC. Что правильно, но как эти данные назначить и передать хосту? За пределами назначения DNS полномочия IPv6 SLAAC кончаются, да даже DNS является дискуссионной опцией. DHCP не обеспечивает синхронность состояний, конечный хост может произвольно поменять или игнорировать любые параметры от DHCP, но DHCP позволяет централизованно осуществить рассылку нужных хосту параметров и это уже далеко шагнуло за границы IP как такового. Упомянутый в статье NTP это как торчащие ушки большой проблемы централизованного управления большим набором конечных устройств.Конечно, для этого есть
AD или TR-069, или если уж на то пошло SD-* решения. Поэтому, ни капли не защищая DHCP - он не обеспечит ни безопасность. ни контроль состояний, ни гарантию применения параметров - не используйте его в этих целях. Но, DHCP рабочее решение прямо сейчас, которое поддерживается подавляющим большинством устройств и позволяет как минимум попытаться определить границы и передать те начальные значения в которых устройство должно работать. А уже потом можно включиться и взрослым ребятам с аккаунтингом и мониторингом и автоматизацией и авторизацией по сертификатам, чтобы контролировать эти границы, которые для начала должны быть обозначены. И пускать этот процесс на самотёк так себе идея.Другой вариант как передать адрес сервера начальной настройки или другого сервиса без
DHCP - DNS и сказать что это лучше, никак нельзя. Сколько уже разных вариантов service discovery туда прикрутили и сколько из них хотя бы минимально совместимы между собой? DNS ещё более резиновый.Или, размазать выдачу адресов конечным хостам на сотни разных сетевых устройств, для каждого из которых придётся менять настройки, вместо централизованного управления
DHCP. Это не проблема в эпоху тотальной автоматизации можно управлять и 10 000 устройствами одновременно, но всё сразу ломается когда это будет хотя бы 100 разных версий одного вендора, не говоря о 100 разных вендорах - типичная ситуация с абонентскими подключениями в провайдере, где каждый абонент сам по себе.DHCP удачно объединяет в себе многие функции. В статье эти функции по отдельности расписаны и для реализации которых надо поднимать несколько разных систем вместо одной, пусть плохой, но рабочей. Рано его ещё хоронить, светлое будущее непосредственного управление каждым устройством в сети конечно наступит, но не прямо сейчас. Но не стоит забывать что всему своё место и решать задачи надо теми инструментами которые для них предназначены, у DHCP такие задачи всё ещё есть.