Кратко

  • RFC 894 назначил IPv4 значение EtherType 0800 в шестнадцатеричной записи и потребовал дополнять нулями поле данных Ethernet, если оно не достигало минимума в 46 октетов. Дополнение передавалось по каналу, но не входило ни в IP-пакет, ни в Total Length.
  • Получателю нужны две длины: реальная длина link-layer payload для размещения внешнего контейнера и Total Length для окончания разбора IP. RFC 6274 позднее потребовал отбрасывать случай, когда канал доставил меньше байтов, чем заявил IP.
  • Байты без смысла для IP могли содержать секреты. CERT/CC описал драйверы, отправлявшие старое содержимое буфера вместо нулей; две проверенные errata RFC 894 аналогично сохраняют границу между неизменным текстом и подтверждённым исправлением.

Исправление не переписало 1984 год

В RFC 894 сначала указан правильный минимум поля данных Ethernet — 46 октетов. Следующий абзац называет 1500 «minimum» и тут же выводит из этого максимальный размер IP-дейтаграммы 1500. Противоречие находится внутри самого документа.

Проверенная техническая erratum 570, зарегистрированная в 2001 году, заменяет minimum на maximum. Erratum 5141, поданная в 2017-м и проверенная в 2024-м, фиксирует то же исправление. Дата проверки не означает, что в 2024 году изменился Ethernet MTU.

Политика RFC Editor сознательно не стирает исходный факт. Опубликованные RFC не меняются. Проверенные errata считаются точными, но не встраиваются в TXT, PDF или XML.

Исходник отвечает на вопрос, что именно было опубликовано. Erratum отвечает, как следует читать ошибочное место. Молча исправленная локальная копия удобнее и хуже для аудита; буквальное следование ошибке лучше сохраняет байты и хуже описывает технику. Нужны оба свидетельства и явная связь между ними.

У дейтаграммы уже была собственная граница

RFC 791 определил Total Length как длину всей IPv4-дейтаграммы в октетах, включая IP-заголовок и данные. IHL отдельно задаёт длину заголовка в 32-битных словах и тем самым начало данных.

RFC 894 поместил этот объект в стандартный Ethernet-кадр. В поле Type находилось шестнадцатеричное 0800, затем шли IP-заголовок и IP-данные. Если поле данных получалось короче 46 октетов, отправитель дописывал нули, не включая их в Total Length.

Минимальный IPv4-заголовок без данных занимает двадцать октетов. Ethernet нужно ещё 26. Приписать их к IP означало бы позволить нижнему уровню изобрести payload, которого не давало приложение. Не передать их означало бы нарушить требование канала.

Поэтому корректное отношение выглядит так:

IHL × 4 <= IP Total Length <= размер payload канального уровня

Строгое второе неравенство не делает кадр повреждённым. Оно оставляет место для законного заполнения.

0800 сообщал тип, а не число байтов

Шестнадцатеричное 0800 равно 2048 в десятичной системе. Это число могло ввести в заблуждение, потому что Ethernet и IEEE 802.3 использовали одну позицию заголовка по-разному.

RFC 1122 описал разграничение: значения до 1500 включительно являются длинами 802.3, допустимые EtherType находятся выше 1500. Поэтому 2048 выбирает IPv4. Оно не обещает 2048 октетов в кадре.

Сначала внешний код выбирает грамматику. Затем Total Length внутри выбранной грамматики указывает конец объекта. Конец link-буфера не может заменить внутреннее поле лишь потому, что за дейтаграммой осталось место.

RFC 1122 потребовал от узлов на 10-Мбит/с Ethernet принимать и отправлять формат RFC 894. Формат IEEE 802 из RFC 1042 следовало принимать и разрешалось отправлять. Узел, отправляющий оба, должен был иметь переключатель с RFC 894 по умолчанию.

Восемь внешних октетов меняли доступный MTU

RFC 1042 переносил IP и ARP через IEEE 802.2 LLC и SNAP. Вместе эти заголовки занимали восемь октетов. Последние 16 бит SNAP сохраняли EtherType: 2048 для IP и 2054 для ARP.

При необходимости минимального размера IEEE 802 данные также дополнялись нулями вне IP Total Length. Указанный минимум 28 октетов составляли двадцать октетов минимального IPv4-заголовка и восемь LLC/SNAP без MAC-заголовка. Это не новое определение 46 октетов из RFC 894.

RFC 1122 указал MTU 1500 для Ethernet и 1492 для 802.3. Восемь октетов внешней упаковки занимали место на носителе. Они не уменьшали IHL и не превращали padding в IP-данные.

RFC 895, опубликованный в тот же месяц, описывал 3-Мбит/с Experimental Ethernet с восьмибитными адресами. Другой Type и максимум 1536 отличались от RFC 894. Правило оставалось: заполнение минимального кадра не входило в Total Length. Локальный предел менялся, область полномочий IP — нет.

Trailer переставлял, padding только дополнял

RFC 893 тоже описывал данные у конца link-пакета. Trailer Encapsulation переносил переменные заголовки верхних уровней после данных ради выравнивания памяти и меньшего копирования на подходящих машинах. Сосед должен был понимать альтернативный формат.

Padding RFC 894 не перемещал IP-заголовок. Заголовок и данные сохраняли обычный порядок, а нули шли после конца из Total Length. Получателю не требовалось восстанавливать порядок; требовалось вовремя остановить IP-разбор.

Дополнение, trailer, IP option и FCS не становятся одним объектом из-за близости к физическому концу. Их разрешают разные поля и правила.

Внешний буфер и внутренний parser подчинялись разным длинам

В RFC 6274 отмечено, что IP-модуль может получить payload больше значения Total Length. Обычно это объясняет законное канальное заполнение; возможна и злонамеренная причина.

Память для приёма следует выделять по размеру, сообщённому канальным уровнем. Внешний контейнер должен физически поместиться. Но интерпретация IPv4 всё равно заканчивается в Total Length: право занять буфер не означает принадлежность протоколу.

Обратный случай недопустим. Если link payload меньше Total Length, пакет следует отбросить и событие записать. Нельзя читать недостающие байты из соседней памяти. Значение IHL, умноженное на четыре, также не должно превышать Total Length.

Одна длина не может безопасно заменить две. Link-длина управляет размещением, IP-длина — смыслом.

То, что не читал IP, мог прочитать сосед

В январе 2003 года CERT/CC VU#412115 сообщил о сетевых драйверах, которые дополняли короткие кадры не нулями, а прежним содержимым frame buffer. В зависимости от реализации наружу могли попасть данные ядра, статическая память драйвера или аппаратный буфер.

Эти октеты не становились допустимым IP payload. Корректный parser останавливался раньше. Но сосед на Ethernet видел их физически. Исключение из протокольного смысла не обеспечивало конфиденциальность передачи.

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

Уровень, добавивший байты, отвечает за их содержание. Ссылка на Total Length не отменяет того, что интерфейс действительно вывел на линию.

Источники