Кратко

  • RFC 3378 зафиксировал EtherIP: 16-битный заголовок перед кадром Ethernet и перенос внутри IPv4 с номером протокола 97.
  • Формат не давал аутентификации узла, контроля внутренней целостности, последовательности, управления туннелем или защиты от циклов. Извлечение кадра подтверждало прибытие, а не единую безопасную LAN.

Локальная сеть определяется не только кадрами. Кабели, коммутаторы, административный периметр и предположение о соседстве делают некоторые слабые протоколы приемлемыми. EtherIP сохранил оболочку кадра, но убрал локальность.

RFC 3378 вышел в сентябре 2002 года как Informational. Он документировал протокол 1991–1992 годов и историю назначения номера 97. Для новых решений авторы предпочитали последующую стандартизацию туннелей второго уровня и псевдопроводов.

После IPv4 шли четыре бита версии со значением три и двенадцать нулевых резервных битов. Затем — кадр Ethernet или IEEE 802.3 без FCS. Получатель отбрасывал неверные значения, извлекал кадр, рассчитывал новый FCS и передавал его в удалённую LAN.

Это проверка синтаксиса, а не доверия. Заголовок не удостоверял отправителя, право использовать MAC, сессию, порядок или внутреннюю целостность.

Исходный FCS заканчивался на входе. Контрольная сумма IPv4 не защищала внутренний кадр; RFC ожидал защиту от протокола выше. Новый FCS мог быть корректным после более раннего искажения: он подтверждал лишь последний локальный участок.

Конечная станция выбирала свои кадры. Мостовая станция слушала сегмент и применяла правила по MAC, EtherType или VLAN. Ей также требовалось сопоставление MAC с IP удалённого EtherIP. Эти решения находились вне 16 битов.

Несколько мостов могли бесконечно перехватывать и возвращать один broadcast или multicast. RFC требовал дерева, но оставлял его человеку. В EtherIP не было spanning tree или счётчика переходов.

Поэтому все локальные правила могли быть верны, а их сочетание — циклично. Рост счётчиков означал работу, не полезную доставку.

Пропуск EtherIP через межсетевой экран мог открыть произвольные коммуникации. Слабая защита для соседей становилась опаснее между удалёнными сегментами. Документ приводил VRRP и предлагал IPsec для внешних датаграмм.

RFC 2401 и RFC 4301 дают контекст IPsec. Он защищает внешнее соединение, но не исправляет выбор кадра, дерево, удалённую вставку или результат приложения.

RFC 2003 и RFC 2784 позволяют сравнить IP-in-IP и GRE. RFC 3931, RFC 3985 и RFC 4448 описывают поздние L2TPv3 и псевдопровода. Эти функции не принадлежат EtherIP задним числом и не доказывают его внедрение.

MUST из RFC 2119 относится к полям и отбрасыванию. Реестр IANA делает номер понятным, но не разрешённым или распространённым. Минимальная спецификация Лу Хэна объясняет пользу нескольких общих битов; слои реальности требуют отдельно доказать выбор, упаковку, доверие, маршрут, целостность, выход и приём.

EtherIP переносил конверт. Топология, полномочия, доверие и физические последствия LAN оставались вне него.

Источники