Кратко

  • RFC 2452 оставил tcpActiveOpens и большинство объектов управления TCP общими для IPv4 и IPv6: версия IP под транспортом не меняла смысл этих показателей.
  • Таблице IPv6 потребовался ipv6TcpConnIfIndex, потому что четыре адреса и порта не всегда задавали единственную строку на узле с несколькими интерфейсами.

Когда одинаковые четыре значения означают разное

В записи TCP-соединения есть локальный адрес и порт, а также удалённый адрес и порт. На первый взгляд, этих четырёх значений достаточно. Но у IPv6 есть области действия. Адрес link-local уникален не обязательно во всём узле: одинаковое значение может относиться к разным интерфейсам и разным каналам связи. Тогда четырёх полей недостаточно, чтобы однозначно найти строку в таблице управления.

Опубликованный в декабре 1998 года RFC 2452 добавил пятый индекс ipv6TcpConnIfIndex к строке IPv6-соединения. Он дополнил ключ записи, а не пакет TCP. В заголовке TCP не появился пятый параметр, и передаваемый по сети кортеж соединения не изменился. Изменилось представление, которым система управления выбирала одну строку среди возможных наблюдений.

Почему счётчики не разделили на две семьи

RFC 2452 исходил из того, что IPv6 в основном невидим для поведения TCP: реализации нужны новые адреса, но не новый «TCPng». Большинство объектов RFC 2012 по-прежнему описывало TCP независимо от того, поверх какой версии IP шло соединение.

Например, tcpActiveOpens считает прямые переходы TCP из CLOSED в SYN-SENT. Счётчик не меняет смысл, если между конечными точками используется IPv4 или IPv6. Общая метрика сохраняет одно имя для одного события. Но она не сообщает, какая IP-версия, конкретное соединение, интерфейс, процесс или пользователь вызвали прирост. И это правило внешнего контракта управления, а не доказательство того, что все устройства хранили данные во внутреннем едином счётчике.

Исключением была таблица соединений. RFC 2012 применял тип SMIv2 IpAddress, состоящий из четырёх октетов и потому не представляющий IPv6-адрес. RFC 2452 создал отдельную ipv6TcpConnTable только для соединений между двумя IPv6-конечными точками; IPv4 оставался в прежней таблице. Единая новая таблица потребовала бы менять RFC 2012 и затронула бы реализации только для IPv4. Параллельный вариант сохранял старый путь нетронутым, а модуль поместили в экспериментальную ветвь MIB, поскольку ожидалось его включение в будущую редакцию TCP-MIB.

Что именно обозначает интерфейс

Значение зависит от пары адресов. Если удалённый адрес link-local, а локальный — нет, индекс указывает на локальный интерфейс в том же канале, что и удалённый адрес. В остальных случаях он идентифицирует интерфейс, связанный с локальным IPv6-адресом. Ненулевой индекс обозначает тот же интерфейс, что и одноимённый ipv6IfIndex, и должен оставаться неизменным на протяжении соединения.

Если определить интерфейс нельзя, RFC допускает ноль; одним возможным примером назван локальный адрес-шаблон ::0. Ноль не обозначает скрытый интерфейс с номером ноль. Он сохраняет отсутствие знания. Если позже подставить туда «наиболее вероятный» интерфейс, неопределённость превратится в неподтверждённую атрибуцию.

Строка была временной: она исчезала при переходе TCP в CLOSED или вскоре после него. Таблица показывала текущее состояние соединения, но не давала постоянный идентификатор сервера, приложения, процесса или человека. Ни четыре поля, ни индекс интерфейса не подтверждают личность удалённой стороны, владение адресом, достижимость или успех приложения.

IPv6-таблица также унаследовала доступное для записи состояние deleteTCB(12), которое могло немедленно завершить соединение на управляемом узле. История этого вмешательства разобрана в опубликованной статье о RFC 2012; здесь это только ограниченное напоминание о чувствительности самой поверхности. Точный индекс не даёт права на действие и не доказывает, что увидела удалённая сторона.

В 2005 году RFC 4022 заменил RFC 2012 и RFC 2452 TCP-MIB, независимым от версии IP, с универсальными соглашениями об адресах. Он не сохранил прежнюю таблицу IPv6 и пятый индекс без изменений. RFC 4001 ввёл пару InetAddressType/InetAddress, в том числе формы с зоной; RFC 4007 описал области и зоны IPv6. В 2017 году RFC 8096 отдельно перевёл RFC 2452 в статус Historic и отметил старые IPv6-модули как obsolete для обслуживания репозиториев MIB. Техническая унификация и последующая историческая переклассификация были разными этапами.

Источники