Кратко

  • 1500 байт на стороне IPoE, 1492 в PPPoE — в схеме RFC 4638 это соседство дало много фрагментированных пакетов. Причина уместилась в восьми байтах: шесть занял заголовок PPPoE, еще два — PPP Protocol ID.
  • RFC 4638 предложил вернуть эти восемь байтов только после переговоров: клиент объявляет размер, концентратор отвечает в пределах своей настройки, а путь проходит проверку. Ни один отдельный флажок не обещает, что большой пакет пройдет всю цепочку.

Один широкополосный путь получил два потолка

У одного маршрута было два потолка: IPoE работал с MTU 1500, а PPPoE между домашним шлюзом и BRAS останавливался на 1492. RFC 4638 называет последствие прямо: много фрагментированных пакетов. Путь не мог решить спор за устройства; восемь байтов разделяли две настройки, и целое приходилось делить на части.

Ethernet-нагрузки в 1500 байт будто бы хватает для интернет-пакета того же размера. Но PPPoE занимает восемь байтов до выхода пакета на линию: шесть уходят на собственный заголовок, два — на идентификатор протокола PPP. Поэтому в феврале 1999 года RFC 2516 установил MTU PPP в 1492 байта для стандартного сегмента Ethernet.

Вычитание было простым. Сложнее был другой вопрос: зачем оператору широкополосного доступа сохранять PPP, если абонентское устройство уже работало через Ethernet?

Широкополосный доступ хотел Ethernet и отдельную сессию на каждого абонента

RFC 2516 дал практический ответ. Ethernet недорого соединял несколько устройств за мостом в доме абонента. PPP сохранял индивидуальный контроль доступа, учет и модель обслуживания каждого пользователя. Домашние устройства делили локальную среду, а оператор поддерживал отдельную PPP-сессию для каждого абонента.

За эту сделку каждый пакет платил восемь байтов. Оператор сохранял границу сессии, а IP-пакету абонента доставалось на восемь байтов меньше в обычной Ethernet-нагрузке размером 1500 байт. RFC 2516 закрепил предел явно, не предлагая оборудованию угадывать, хватит ли места на следующем участке.

Восемь байтов стали предметом согласования возможностей

RFC 4638 не заставлял каждую сессию PPPoE работать выше 1492 байтов. Но для описанных в документе широкополосных сетей следующего поколения он требует, чтобы BRAS в роли PPPoE-сервера поддерживал согласование значений выше этого предела; необязательный тег PPP-Max-Payload определяет, смогут ли конкретные клиент и сервер использовать больший размер. Двухбайтовое значение тега указывает максимальную нагрузку PPP, которую клиент поддерживает в обоих направлениях. Запрашивая больше 1492, клиент включает тег в PADI и PADR. Сервер, который может выполнить запрос, возвращает тег в PADO и PADS.

Тег позволяет обсуждать больший размер, но не назначает итог. Концентратор выбирает значение в пределах своей настройки и максимума, который объявил клиент. У сервера есть еще одна простая граница: из MTU его интерфейса вычитают восемь байтов. Если MTU интерфейса равен 1500, по этой формуле остается 1492. Итог не может превышать ни значение тега, ни эту границу; промежуточные сегменты тоже должны пропустить пакет.

Так одно число превратилось в цепочку решений. Клиент может попросить больше. Концентратор отвечает лишь в пределах своих возможностей. Локальному интерфейсу нужно место для инкапсуляции. Каждый Ethernet-сегмент на пути должен передать итоговый пакет. Значение 1500 на экране абонента не подтверждает, что каждый коммутатор между домом и концентратором его принимает.

Путь тоже мог отказать

RFC 4638 описывает проверку после установления сессии. Отправитель может передать Echo-Request размером MRU через получателя и промежуточное оборудование Ethernet. Если на большой пробный пакет не приходит Echo-Reply, а на пакет размером 1492 приходит, отправитель не должен передавать в этой сессии пакеты большего размера.

Этот откат важен. Если стороны не обменялись тегом или у одной из них нет настройки для большего размера, действует предел RFC 2516 в 1492 байта. Если путь не проходит проверку большого пакета, соединение также может вернуться к меньшему пределу. Старое соглашение остается рабочим минимумом, а совместимый путь может договориться о большем.

Опубликованный вариант не расширил стандарт Ethernet

RFC 4638 — информационный документ. В примечании IESG к нему сказано, что на момент публикации не существовало действующего стандарта IEEE для jumbo-кадров с MTU свыше 1500 байт; там же отмечены риски совместимости и надежности нестандартных расширений. Стороны PPPoE могли предложить большее значение, но каждый Ethernet-порт должен был действительно его принять.

Поэтому история не сводится к формуле «1492 автоматически стало 1500». RFC 4638 оставил старый предел для путей, которым он был нужен, определил обмен возможностями и дал реализациям способ проверить больший размер. Протокол может записать предложение; его судьбу решают участвующие устройства и сам путь.

RFC фиксируют конструкцию и цель уменьшить фрагментацию, но не сообщают, какие сети доступа включили этот тег. Для подтверждения внедрения в конкретной сети нужна датированная конфигурация концентратора или запись фактического обмена PPPoE при обнаружении сервиса.

Источники