Кратко

  • В IPv6-джамбограмме нулевое поле Payload Length передаёт определение длины параметру Jumbo Payload в непосредственно следующем заголовке Hop-by-Hop Options.
  • Параметр содержит настоящую длину в 32 битах и действителен только для значения больше 65 535 октетов; один ноль не доказывает ни пустоту, ни правильность пакета.
  • Корректная цепочка заголовков не гарантирует пропускную способность всего пути, а отсутствие ошибки ICMPv6 не подтверждает доставку.

Ноль как указатель

Фиксированный заголовок IPv6 занимает 40 октетов, а его поле Payload Length — 16 бит. В обычном пакете оно считает всё после базового заголовка, включая заголовки расширения. Максимум равен 65 535. RFC 2675 не увеличивает общий заголовок ради редкого случая, а резервирует ноль и переносит достоверное значение длины в отдельный 32-битный параметр.

Такое толкование требует контекста. Узел, получивший нулевую базовую длину, Hop-by-Hop Options в Next Header и дополнительные октеты, обязан обработать этот заголовок. Значение Jumbo Payload Length без знака охватывает расширения и данные верхнего уровня после базового заголовка, не включает его 40 октетов и должно быть больше 65 535.

Запись, в которой осталась лишь базовая строка с нулём, сохраняет направление поиска, но не сам ответ. Для проверяемого вывода нужны Next Header, наличие и позиция параметра, объявленное число и фактический объём захвата. Если анализатор обрезал кадр по snap length, недостающие в файле байты могут говорить об ограничении наблюдения, а не о повреждении переданного пакета.

Свидетельство образует пара

RFC 2675 перечисляет недопустимые сочетания. Нулевая базовая длина и заголовок Hop-by-Hop без Jumbo — ошибка. Параметр Jumbo при ненулевой базовой длине — тоже. Значение Jumbo меньше 65 536 применять нельзя. Наконец, один пакет не может содержать одновременно Jumbo Payload и заголовок Fragment.

Следовательно, доказательством служит не отдельная ячейка, а согласование полей. Ноль передаёт полномочие, параметр отвечает величиной, порядок заголовков подтверждает правильность передачи. Декодер, который подписывает каждый ноль как «пусто», теряет допустимые джамбограммы. Декодер, который принимает любой ноль за джамбограмму, пропускает структуры, предписанные к отбрасыванию.

Противоречие может вызвать ICMPv6 Parameter Problem. В RFC 4443 Type 4 Code 0 означает ошибочное поле заголовка; пакет отбрасывается, а ответ должен быть отправлен с учётом правил протокола. Но отсутствие ответа не является квитанцией о приёме. Фильтр, ограничение частоты, асимметричный маршрут или разрыв обратного пути также скрывают ICMPv6.

У нуля UDP другая юрисдикция

UDP располагает собственным 16-битным полем длины. В составе джамбограммы оно может быть нулевым, если фактическая длина UDP превышает 65 535. Получатель выводит её из Jumbo Payload Length, вычитая предшествующие UDP заголовки расширения. При расчёте контрольной суммы используется эта реальная длина, а не ноль.

Два нуля согласованы, но относятся к разным правилам. Ноль IPv6 отправляет к Jumbo-опции; ноль UDP включает транспортное исключение. Наличие одного нельзя использовать как доказательство второго. У TCP сопоставимого поля длины пакета нет. В этом режиме MSS 65 535 трактуется как отсутствие собственного предела, а практический размер определяет обнаруженный MTU пути.

Формат может быть верным, а путь — узким

Джамбограммы имеют смысл только на каналах с MTU больше 65 575 октетов: 40 октетов базового заголовка плюс полезная нагрузка свыше 65 535. Реализация, не подключённая к таким каналам, не обязана их поддерживать. RFC 8201 определяет Path MTU как минимальный MTU на маршруте. Слишком крупный пакет может быть отброшен с сообщением Packet Too Big.

Поэтому синтаксическая корректность не резервирует место в туннеле или промежуточном устройстве. Отправитель, получатель и первый канал могут поддерживать формат, а следующий участок — нет. Обратная крайность тоже ошибочна: фильтр, отбрасывающий пакет лишь из-за Jumbo-опции, устраняет разрешённые стандартом джамбограммы. RFC 9288 подчёркивает этот риск при обсуждении заголовков расширения.

Расследование должно разнести три утверждения: что заявил пакет, согласуется ли структура со стандартом и что произошло на пути. На первые два отвечают полные поля и проверка цепочки. Для третьего нужны факт приёма, счётчики, Packet Too Big, контролируемые пробы или сопоставленные точки захвата. Свести все три к нулю значит превратить компактный указатель в ложный вердикт.

Такая же точность нужна в атрибуции. Авторами RFC 2675 указаны David Borman, Steve Deering и Robert M. Hinden; RFC 8200 — Steve Deering и Bob Hinden. Профиль IETF называет Hinden одним из соизобретателей IPv6. Эти данные не подтверждают единоличное создание механизма или контроль над решениями независимых операторов.

Источники