Кратко

  • Configure-Ack не разрешалось улучшать число, менять порядок или толковать запрос заново. Identifier и весь список опций должны были точно совпасть с последним Configure-Request.
  • LCP вёл два направления раздельно. Nak предлагал приемлемые значения, Reject закрывал переговоры об опции, а для Opened требовались и отправленный, и полученный Ack.

Исправленное согласие переставало быть согласием

Пусть сторона А называет максимальный размер кадра, который готова принимать. Б понимает Maximum-Receive-Unit, считает соседнее значение удобнее и помещает его в Configure-Ack. Человеку это покажется разумной уступкой, но для PPP такой ответ недействителен.

RFC 1661 требует скопировать Identifier последнего запроса и вернуть опции в том же порядке и без изменений. Ack допустим, только если все опции распознаны и каждое значение приемлемо. Ответчик может сказать «да», но не может редактировать текст согласия.

Точная копия устраняет неоднозначность распределённого состояния. Если бы Ack мог улучшать предложение, отправителю пришлось бы угадывать, подтвердили ли его вариант, заменили его или собрали третью конфигурацию. Потери, повторы и встречные пакеты усилили бы расхождение. Равенство байтов оставляет один проверяемый факт: принято именно это предложение.

Identifier связывает ответ с попыткой. Он меняется вместе с содержимым и после действительного ответа на предыдущий запрос; повторная передача может сохранить номер. Это не удостоверение личности партнёра. Поле лишь не даёт старому разговору управлять новым запросом.

Для встречного предложения и границы были разные сообщения

Configure-Nak применяется, когда опция понятна и допускает переговоры, но её значение неприемлемо. Nak убирает уже приемлемые элементы, перечисляет спорные и может предложить значения, которые устроят его отправителя. Он также может указать обязательную локальную опцию, пропущенную в запросе.

Nak не правит открытый запрос. Инициатор решает, отправлять ли новый Configure-Request с другим содержимым и Identifier. Предложенное значение становится кандидатом, а не действующей настройкой; ему ещё нужен точный Ack.

Configure-Reject обозначает более жёсткий предел. Опция неизвестна, не реализована или исключена из переговоров местной политикой. Reject копирует отвергнутую опцию, а следующий запрос должен её убрать. Для логической опции без альтернативного значения тоже нужен Reject, а не Nak.

Так три кода получают разный объём власти. Ack подтверждает готовый текст, Nak очерчивает возможный диапазон, Reject отказывает обсуждать вопрос. Ни один ответ не разрешает соседу скрытно переписать локальное требование.

На одной линии шли два согласования

Если конкретная опция не говорит иначе, параметры LCP действуют в одном направлении и обычно описывают приём отправителя Configure-Request. Запрос А сообщает Б условия приёма у А; Б формирует отдельный запрос для обратного направления.

Пакеты могут пересечься. А уже получил Ack на свой список, но ещё выбирает ответ на список Б. RFC 1171 называл это Ack-Received: согласие получено, но ещё не отправлено. Разрешение одного направления не порождает разрешение другого.

RFC 1331 зафиксировал порог открытия: этап установления завершается, когда Configure-Ack и отправлен, и получен. Физический сигнал либо единственный Ack не позволяют одной стороне объявить весь PPP-канал открытым.

Двойной учёт сохранял полезную асимметрию. Пределы приёма, требования к аутентификации, сжатие и обработка управляющих символов могут различаться. Совместимость не требовала одинаковых устройств — она требовала доказуемого состояния для каждого направления.

Отсутствие опции означало значение по умолчанию

Configure-Request перечисляет не все способности, а желаемые отклонения от стандартных значений. RFC 1661 советует не посылать опцию с её default. Поэтому пропуск — не неизвестность: продолжает действовать заданное правило.

Журнал одних явных опций не восстановит фактическую конфигурацию. К принятому списку нужно добавить значения по умолчанию и правильно учесть направление.

Опции одного запроса рассматриваются одновременно. Ack принимает весь упорядоченный список; Nak сообщает лишь спорные значения; Reject — лишь то, что не войдёт в переговоры. Решение остаётся атомарным, не вынуждая сторону раскрывать все возможности.

Язык управления оставался читаемым во время спора о сжатии

Некоторые опции меняют формат последующих кадров. Если А начнёт сжимать поля, полагая договорённость завершённой, а Б продолжит ожидать обычный формат, нечитаемыми могут стать даже сообщения для исправления разногласия.

RFC 1548 и RFC 1661 оставляют устойчивый путь: LCP-пакеты конфигурации, завершения и Code-Reject передаются так, будто опции ещё не включены. Сжатие полей Address, Control и Protocol на них не распространяется.

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

Молчание и бесконечный торг получили пределы

Configure-Request защищён Restart timer и счётчиком, поскольку кадры теряются. Max-Configure обязан настраиваться; RFC 1661 рекомендует десять передач. Исчерпание даёт локальное основание прекратить попытку, но не доказывает атаку или физический разрыв.

Ответы тоже могут не вести к сближению. Max-Failure считает последовательные Nak; рекомендуемое значение — пять. Затем дальнейшие Nak превращаются в Reject, а сторона перестаёт добавлять собственные желательные опции. Не сходящийся торг не должен занимать автомат бесконечно.

Открытый LCP ещё не означал готовый IP

Четыре кода конфигурации присутствовали уже в RFC 1134 ноября 1989 года. Они прошли через RFC 1171, RFC 1331 и RFC 1548 в базовый RFC 1661 июля 1994 года. Одновременно яснее разделились этапы.

Нижний уровень сначала сообщает о физической готовности. LCP согласует параметры, не зависящие от сетевого протокола. Если выбрана аутентификация, она выполняется затем. После этого отдельный Network Control Protocol открывает IP или иной протокол. Только его состояние Opened разрешает соответствующий трафик.

Configure-Ack не доказывает личность, успешную аутентификацию, адрес IP, маршрут или доступность приложения. Он подтверждает лишь принятие одним концом точного предложения LCP.

Нынешний реестр PPP IANA по-прежнему отводит коды 1–4 Request, Ack, Nak и Reject и ведёт пространство опций. Реестр доказывает согласованный словарь, а не современную распространённость или качество реализаций.

Узкое согласие сделало различия совместимыми

PPP разложил расплывчатое «мы договорились» на малые факты: точная копия для принятия, отдельные сообщения для совета и отказа, свой учёт каждого направления, предел молчания и повторов. Верхние уровни должны были сами заслужить готовность.

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

Источники и границы

RFC 1134, RFC 1171, RFC 1331, RFC 1548 и RFC 1661 подтверждают развитие, форматы, состояния и пределы; IANA — текущие назначения. Они не измеряют сегодняшнее применение, соответствие производителей, производительность, практику операторов или единый тайм-аут. Толкование точного ответа как узкой двусторонней власти является редакционным выводом.