Кратко

  • RFC 2153 выделил общий частный конверт, чтобы поставщики тайно не назначали конфликтующие PPP Code и Option Type.
  • OUI указывает администратора смысла; Kind и Values остаются частными, поэтому корректный пакет может быть неизвестен или запрещён.
  • Configure-Ack принимает точный запрос, а активация, двустороннее использование, трафик и результат сервиса требуют отдельных данных.

Заголовок прочитан, словаря нет

Трассировка показывает Code 0, допустимую длину, OUI и Kind. Пакет правильно отнесён к пространству имён. Но приёмник может не иметь модуля для этого Kind, не понимать версию Values или не иметь административного разрешения.

RFC 2153, информационный документ 1997 года, решал узкую задачу: не дать поставщикам самовольно занимать обычные Code LCP/NCP и Type параметров с будущими коллизиями. Внутренний частный алгоритм стандартом не стал.

Пакет Vendor Specific использует Code 0, новый Identifier для каждого пакета, Magic-Number, OUI, Kind и необязательные Values. Его можно отправить до LCP Opened. Приём вызывает RXR или RUC, однако ответ задаёт поставщик; Code-Reject даёт разрешённое событие RXJ+. Это свидетельство работы автомата, не согласия.

Параметр Vendor-Specific использует Type 0. До принятия реализация обязана проверить, что OUI и Kind обозначают известный механизм, и полностью понять значения переговоров. Формат, смысл и решение — разные проверки.

OUI не удостоверяет отправителя

OUI называет организацию, управляющую смыслом. Kind не стандартизирован между OUI, Values зависит от реализации. OUI не аутентифицирует отправителя и не разрешает эксплуатацию. RFC 1661 допускает аутентификацию узла после установления линии, а частный пакет может прийти раньше Opened; RFC 2153 не обсуждает безопасность.

Для программных поставщиков без IEEE OUI существовала серия CF0000. RFC 5342 закрыл новые назначения, а RFC 7042 сохранил решение без технического изменения формата. Реестр IANA PPP доказывает происхождение номера, но не наличие современной реализации.

Configure-Ack возможен, когда все параметры узнаваемы и значения приемлемы, и точно копирует запрос. Nak означает понятный параметр с неприемлемыми значениями. Reject означает неизвестный или административно запрещённый параметр. После Ack всё ещё нужны версия словаря, субъект разрешения, установка параметров, первый обработанный пакет механизма, NCP Opened, сетевой трафик и результат приложения.

RFC 3772 позже добавил отдельные протоколы поставщиков, оставив безопасность каждому протоколу. RFC Editor, Datatracker и errata описывают документ. Running-Code Primacy, Minimum Initial Specification и Reality Layers разделяют спецификацию, выполнение и результат.

Источники