Кратко

  • Для соответствия IP-реализации SNMPv2 RFC 2011 требовала группы ipGroup и icmpGroup, однако примечание IESG прямо говорило: тип IpAddress длиной четыре октета поддерживал только IPv4.
  • Заполненная таблица или растущий счётчик подтверждали события внутри объявленного набора объектов. Они не доказывали видимость адресов, префиксов, маршрутов и соседей IPv6 и не подтверждали сетевой эффект изменения конфигурации.
  • RFC 2465 сначала создала отдельную поверхность управления IPv6, RFC 4001 связала тип адреса с его значением, а RFC 4293 затем объединила линии и потребовала новых индексов и инструментирования.

Прибор правильно измерял собственную шкалу

Ограничение RFC 2011 было явным. В примечании IESG сказано, что тогдашние MIB-модули IP, UDP и TCP поддерживали только IPv4: IpAddress представлял 32-битный адрес как OCTET STRING длиной четыре. Для 128-битного адреса IPv6 допустимого представления не существовало.

От выбора типа зависело устройство таблиц. В ipAddrTable объект ipAdEntAddr одновременно содержал адрес и служил индексом строки; маска тоже имела тип IpAddress. ipNetToMediaTable использовала тот же тип в идентичности соответствия между сетевым и физическим адресом. Поэтому синтаксис определял не только вид ячейки, но и то, какие строки могли существовать и как менеджер мог к ним обратиться. Отсутствующая строка IPv6 не обязательно означала зарегистрированную ошибку — в этой модели она была непредставима.

Агент мог реализовать все обязательные объекты, отвечать на разрешённые чтения и честно получить зелёный результат. Ошибка возникала лишь тогда, когда локальное утверждение «соответствует этой MIB» превращали в общее «IP-поведение узла охвачено».

У каждой группы был свой знаменатель

RFC 2011 решала конкретную историческую задачу. MIB-II описывала объекты IP и ICMP в рамках SNMPv1; управление маршрутами IP уже обновлялось отдельным документом. RFC 2011 перенесла оставшиеся объекты в SNMPv2 и прямо исключила управление маршрутами из описания модуля.

Декларация ipMIBCompliance требовала ipGroup и icmpGroup. В них входили режим пересылки, TTL по умолчанию, входные и выходные показатели, сборка и фрагментация, адресные строки, сетево-физические соответствия и счётчики ICMP. Это широкая инструментальная поверхность, но не тождество со всей сетью.

Даже соседние счётчики описывали разные множества. ipInReceives включал датаграммы, принятые с ошибкой. ipInDiscards считал отброшенные без ошибки обработки датаграммы, но не отбрасывания во время ожидания сборки. ipOutNoRoutes относился к пакетам, для которых не нашли маршрут. ipReasmFails не обязательно равнялся числу отброшенных фрагментов. Рост числа доказывал изменение определённой совокупности, но сам по себе не называл семейство, пакет, путь, сервис или причину.

Запись также имела ограниченный смысл. ipForwarding и ipDefaultTTL допускали изменение, строки сетево-физических соответствий можно было создать или сделать недействительными. Успешный ответ подтверждал принятие операции на уровне протокола. Он не подтверждал полномочия, сохранение настройки, выбор стека, фактическую пересылку или достижимость удалённой точки.

IPv6 сначала появился рядом

RFC 2465 в 1998 году не пыталась расширить старое поле. Она определила отдельную общую MIB для IPv6 с шестью таблицами: интерфейсы, статистика интерфейсов, префиксы, адреса, маршруты и сетево-физические соответствия. Адрес IPv6 представлялся строкой из 16 октетов, причём SMIv2 и совместимые реализации SNMP менять не требовалось.

Представление появилось, но в dual-stack-среде возникла задача стыковки. Нужно было знать, какие семейства MIB реализовал агент, какие таблицы обходил сборщик, как совпадали идентификаторы интерфейсов и не предпочитала ли панель незаметно только одну сторону. Соответствие RFC 2011 оставалось верным, но описывало IPv4-часть более крупной системы.

RFC 4001 превратила этот урок в общее правило. InetAddress несёт значение только вместе с InetAddressType; в индексе тип расположен перед длиной и байтами адреса. Спецификация предостерегала от жёсткой привязки новых объектов к одному формату, но позволяла декларации соответствия требовать лишь подмножество типов. Универсальная структура делала семейство явным, а не гарантированно реализованным.

Объединение потребовало миграции кода и данных

RFC 4293 в 2006 году заменила RFC 2011, RFC 2465 и отдельную MIB ICMPv6. Новый модуль был независим от версии IP. Системная и интерфейсная статистика получила измерение по типу IP, адреса — явный тип, а префиксы, маршрутизаторы по умолчанию и физические соседи — общие структуры.

История изменений не скрывала цену. Прежнюю ipAddrTable преобразовали в ipAddressTable лишь приблизительно; различия были настолько велики, что новый код мог оказаться проще переделки старого. Процедурам SNMP требовалась новая индексация, новым счётчикам — новое инструментирование. Стандарт определял целевую схему, но в день публикации не переносил агент, сборщик, архив, правила тревог и решения оператора.

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

Источники

Пределы доказательств

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