Кратко

  • Регистрация PPP-Max-Payload под номером 288 согласовала значение тега, но не свидетельствовала о готовности всех сетей к увеличенным кадрам.
  • Переезд PPPoE с персонального компьютера на домашний шлюз поставил традиционные 1492 байта между локальным IP-пакетом длиной 1500 и сетью доступа.
  • Расширение отделило объявление возможности от согласования MRU, а проверка больших и малых запросов могла ограничить отправителя размером 1492 на время конкретного сеанса.

Два документа — не одна модернизация

У истории расширения есть удобная, но неверная короткая версия: появился стандарт, выделили номер, сеть стала переносить больше. Первичные документы рассказывают иначе.

Опубликованный в сентябре 2006 года RFC 4638 имел статус Informational, а не Internet Standard. Примечание IESG призывало к осторожности с учётом тогдашней ситуации со стандартизацией Ethernet для полезной нагрузки свыше 1500 байтов. Это замечание относится к 2006 году, а не описывает состояние стандартов в 2026-м.

В июне 2007 года RFC 4937 оформил правила регистрации 16-битных типов тегов PPPoE и указал PPP-Max-Payload под десятичным номером 288. В проверенном реестре параметров PPPoE IANA сохраняется та же связь.

Реестр нужен независимым реализациям, чтобы одинаково понимать поле. Он не измеряет вместимость интерфейса и не модернизирует мосты между участниками сеанса. Дата записи не является датой повсеместного внедрения.

Различие важно потому, что само расширение уже исходило из этой ограниченности. Оно позволяло сторонам сообщить о поддержке, затем согласовать размер в пределах местных возможностей и, наконец, отступить от большого размера по результатам работы.

Восемь байтов были заняты заранее

В феврале 1999 года RFC 2516 описал PPP поверх Ethernet. При максимальной полезной нагрузке Ethernet в 1500 байтов шесть занимал заголовок PPPoE, ещё два — идентификатор протокола PPP. Для нагрузки PPP оставалось 1492.

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

Расширение 2006 года не убрало эти восемь байтов. Чтобы сохранить 1500 байтов нагрузки PPP, нижележащая нагрузка Ethernet при счёте «шесть плюс два» должна вмещать 1508. Предложение опиралось на системы, способные переносить более крупные кадры.

Это необходимое место, а не универсальная команда настройки. Число 1508 нельзя без проверки переносить в любое поле, которое производитель назвал размером кадра. Способ учёта тегов и внешних полей должен соответствовать тому, что требуется передать.

Ограничение осталось, участник сменился

RFC 4638 связывает потребность в расширении с изменением архитектуры широкополосного доступа. В прежней схеме, которую он описывает, PPPoE начинался на компьютере пользователя. Ограничение в 1492 обычно было приемлемо: сам конечный компьютер участвовал в согласовании ограниченного участка.

Домашний шлюз изменил место стыка. Со стороны локальной сети он принимал IP поверх Ethernet, а со стороны доступа устанавливал PPPoE. К нему мог прийти IP-пакет длиной 1500 байтов, тогда как традиционная нагрузка следующего PPP-участка ограничивалась 1492.

Новый заголовок при этом не возник. Изменилось распределение работы. Компьютер, создающий пакет, больше не был стороной LCP-согласования на участке доступа. Разницу должен был обслуживать шлюз.

Документ также рассматривает переходы с PPPoA на PPPoE и сообщает о развёрнутом тогда клиентском оборудовании PPPoA, которое не поддерживало 1492. Это историческое описание обстановки 2006 года, а не современная статистика и не свойство всех устройств такого типа.

Сама ATM-среда тоже не давала бесконечного пространства. Согласно RFC 2364 от июля 1998 года, MRU для PPP over AAL5 не должна превышать максимальную CPCS-SDU, разрешённую контрактом трафика виртуального соединения в соответствующем направлении. При миграции менялись нижележащие условия, а не появлялось первое в истории PPP ограничение.

Что именно обнаруживал Discovery

PPPoE сначала находит партнёра, затем ведёт сеанс PPP. Клиент рассылает PADI, получает предложения PADO, отправляет PADR выбранному концентратору и получает подтверждение PADS. Ethernet-адреса и идентификатор сеанса связывают дальнейший обмен с нужными участниками.

Успешное обнаружение не завершает все следующие этапы PPP, возможную аутентификацию и подготовку сетевого протокола. Оно также не доказывает, что более крупные пакеты пройдут тем же путём. Маленькие управляющие сообщения могут не затронуть ограничение, важное для данных.

Расширение добавило в Discovery тег PPP-Max-Payload. Клиент, желающий выйти за 1492, обязан включить его и в PADI, и в PADR. Поддерживающий расширение сервер, получивший тег, возвращает его в PADO и PADS.

Тип тега — 0x0120, то есть 288. Двухбайтовое двоичное значение обозначает максимальную нагрузку PPP, которую клиент поддерживает и при отправке, и при приёме. Номер типа не является размером пакета, а два байта значения не превращаются в постоянный дополнительный заголовок каждого пакета сеанса.

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

Сервер повторяет объявление, но сохраняет свои условия

Возвращая тег, сервер повторяет информацию клиента. Он не обязан прямо в Discovery переписывать её в собственный окончательный максимум. Локальная вместимость ограничивает последующее согласование PPP.

Описанная в RFC 4638 процедура начинает с 1492. Если тег присутствует и его значение больше, верхняя граница для переговоров становится меньшим из двух чисел: объявленной величины и MTU интерфейса за вычетом восьми байтов. Затем обычный LCP определяет фактическую MRU.

Поэтому большое число в PADO и меньший последующий результат могут быть согласованной работой протокола. Первое показывает общую способность понимать расширение. Второе учитывает условия его использования.

RFC 1661, опубликованный в июле 1994 года, определяет MRU как максимальную единицу приёма для Information и Padding. Поле протокола и внешнее оформление кадра в неё не входят. Объявление приёмной способности не приказывает другой стороне заполнять каждый пакет до предела.

Обычный PPP использует по умолчанию 1500, но это общее правило не отменяет специального ограничения PPPoE. Даже тег выше 1500 сам по себе не создаёт фактическую MRU выше 1500: при выполненных условиях расширения, но без согласования большего MRU, остаётся обычное значение по умолчанию. Объявление, допустимый потолок и выбранный размер — три разных свидетельства.

Мосты между сторонами ничего не обещали

Промежуточный Ethernet-мост мог пропустить все сообщения Discovery и LCP, оставаясь неспособным передать увеличенный кадр. Он не подписывал соглашение между концами PPP.

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

Функцию рекомендуется включать по умолчанию и делать настраиваемой; предварительное знание сети может служить основанием для отключения. Это не предписание проводить одинаковую обязательную проверку в каждом сеансе. Документ не задаёт общего для всех числа повторов или таймера.

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

RFC 1661 допускает Echo-Request и Echo-Reply в состоянии LCP Opened и связывает ответ с запросом посредством Identifier. Но это не гарантирует равенства их длин. Одно успешное взаимодействие нельзя считать бессрочным доказательством максимальной симметричной пропускной способности по размеру. Нужны реальные размеры и направления сообщений.

Удалённый маршрут остаётся отдельным вопросом

Проверка PPPoE не заменяет определение MTU всего IP-маршрута. RFC 1191 от ноября 1990 года описывает IPv4 Path MTU Discovery: источник устанавливает запрет фрагментации и уменьшает оценку после ICMP-сообщения от маршрутизатора, который не может передать пакет без дробления.

В таком случае маршрутизатор отбрасывает пакет и сообщает о проблеме. Следовательно, неверно говорить, будто любой слишком большой IPv4-пакет обязательно будет фрагментирован и доставлен. Бит DF меняет действие при ограничении размера.

Сеансовая проверка касается доступа и обработки Ethernet между его участниками. За этим участком может находиться другой, с меньшим допустимым размером. Локальный успех нельзя выдавать за заключение о любом удалённом назначении.

Узкий охват не делает проверку бесполезной. Он определяет, какому решению она может служить. Расширение позволяло согласовать использование большей ёмкости там, где она существовала, но не утверждало, что согласование создаёт её.

Регистрационный номер завершал лишь одну часть этой работы — общий язык. Восемь байтов по-прежнему должны были поместиться в реальную передачу. Исторический результат состоял в разделении ответственности за объявление, выбор и проверку, а не в административном увеличении кадров.