Кратко

  • Состояние LCP Opened подтверждало общий канал, но не поддержку каждой величины PPP Protocol. Неизвестное значение требовало Protocol-Reject с кодом LCP 8.
  • Ответ содержал двухоктетный Rejected-Protocol и часть информации исходного пакета, обрезанную до MRU партнёра и лишённую заголовков канального уровня и FCS.
  • Отказ NCP мог быть допустимым RXJ+, тогда как отказ самому LCP считался катастрофическим RXJ-: исчезал общий язык, позволявший локализовать несовместимость.

Работоспособность канала не была каталогом возможностей

В 1989 году RFC 1134 предложил PPP для передачи датаграмм нескольких протоколов сетевого уровня по соединениям точка-точка. LCP управлял общей линией, а семейство Network Control Protocols настраивало отдельные сетевые протоколы. Поэтому открытие LCP и готовность каждого возможного сервиса были разными утверждениями.

Разногласие могло обнаружиться после успешного открытия. Один узел присылал пакет со значением PPP Protocol, неизвестным другому. Если LCP находился в Open, получатель должен был ответить пакетом LCP с Code 8 — Protocol-Reject. Стандарт не превращал частную несовместимость в автоматическое доказательство гибели всего носителя.

RFC 1331 в 1992 году разделил неизвестность и несвоевременность. Если протокол поддерживался, но соответствующий NCP ещё не достиг Opened, пакет молча отбрасывался. Если неизвестным было само значение Protocol, следовал отказ. В первом случае не совпадала фаза, во втором — набор возможностей.

Из молчания нельзя вывести поддержку. LCP мог находиться в другом состоянии, NCP мог быть закрыт, сообщение могло потеряться, а реализация — нарушить стандарт. Code 8 также не доказывал физический обрыв или ошибку аутентификации. Он сообщал более узкий факт: конкретный протокол не принят в существующем контексте LCP.

Размер свидетельства ограничивал тот же договор

В RFC 1661 поле Code равно 8, а Identifier обязан меняться для каждого отправленного Protocol-Reject. Rejected-Protocol занимает два октета и копирует PPP Protocol отвергнутого пакета.

Rejected-Information начинается с его поля Information. Туда не входят заголовки канального уровня и FCS. Поле обязательно обрезается так, чтобы ответ не превышал установленную для партнёра Maximum-Receive-Unit. Диагностическое сообщение не получало права нарушить ограничение приёма, о котором стороны уже договорились.

Поэтому возврат нельзя считать полной копией кадра. Он может быть усечён и изначально исключает внешние элементы. Identifier тоже не является постоянным номером происшествия. Доказательство типизировано и ограничено: оно связывает отказ с величиной протокола и допустимым фрагментом вызвавшего его пакета.

RFC 1548 сохранил механизм в 1993 году, а RFC 1661 закрепил его в 1994-м. Преемственность подтверждает место в архитектуре стандарта, но не качество каждой реализации.

Прекратить передачу должен был отправитель

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

RFC 1332 определяет IPCP для установки и настройки IP поверх PPP. RFC 5072 описывает IPv6CP. Это примеры отдельных NCP, а не доказательство их работы на наблюдаемой линии. Если NCP отвергнут, соответствующий сетевой сервис не становится доступным от одного сохранения LCP. Другой протокол продолжится лишь при собственной поддержке и завершённой настройке.

Отправлять Protocol-Reject можно только в LCP Opened. Полученный в другом состоянии пакет следует молча отбросить. Состояние служит границей полномочий: сообщение о несовместимости способно управлять партнёром только после того, как стороны установили общий контрольный контекст.

Один и тот же Code 8 имел два исхода

RFC 1331 называл допустимое получение отказа RXJ+. В качестве примера приводился Protocol-Reject для NCP. Такое событие находилось в пределах нормальной работы: указанный тип пакетов прекращался, но LCP мог оставаться открытым.

RXJ- был катастрофическим. Если отвергался сам LCP, ошибка считалась невосстановимой и соединение прекращалось. Формат сообщения оставался прежним; менялся уровень, которому отказали. После потери NCP общий LCP ещё мог описать проблему. Если неизвестным объявлен LCP, стороны теряют язык конфигурации, проверки и локализации отказа.

Следовательно, открытый канал не равен доступному сервису. Приложение, зависящее от единственного отвергнутого NCP, может полностью остановиться при состоянии LCP Opened. Непрерывность носителя и полезной функции надо измерять отдельно.

Реестр расшифровывал номер, но не обещал поддержку

Реестр номеров PPP IANA указывает LCP Code 8 как Protocol-Reject и публикует назначения поля Protocol. Он авторитетно объясняет номер, но не подтверждает наличие функции в устройстве, состояние NCP, современное использование или успешную передачу.

RFC 3818 перевёл распределение пространств PPP к процедуре IETF Consensus. Это свидетельство управления расширяемым пространством, не перепись внедрений. Операционный вывод требует соединить реестр с конфигурацией, состояниями, трассой пакетов и действиями после отказа.

Источники