Кратко

  • Значение 0xcf явно обозначает PPP после заголовка Q.922, но иной ненулевой байт считается сжатым PPP Protocol только при включённом PFC и уже согласованном соответствующем NCP.
  • Несколько ответов с одним LCP Identifier от разных framing addresses могут обнаружить случайное многоточечное подключение; эквивалентная инкапсуляция после NCP требует возврата в Link Establishment.

Зелёный индикатор линии объединяет слишком много вопросов. Есть ли несущая? Доходит ли кадр? Сколько узлов отвечает? Помнит ли удалённая сторона параметры PPP? Прошла ли аутентификация? RFC 1973 не позволял одному сигналу отвечать за всю цепочку.

Документ вышел в июне 1996 года и описал PPP внутри виртуального канала Frame Relay, настроенного как точка-точка. LCP, сетевые NCP, аутентификация и сжатие PPP предполагают пару участников. Frame Relay предоставляет виртуальные каналы, но способен оказаться частью многоточечной среды. Поэтому формат должен был защищать двустороннюю машину состояний от нижнего уровня, который сам по себе не удостоверяет единственность соседа.

Несовместимые границы адреса

Обычно PPP использовал HDLC-like framing на основе ISO 3309. Рассматривалась возможность совместить его с Frame Relay на одной линии. RFC 1973 зафиксировал, почему это невозможно: Q.922 расширяет адрес с одного октета до двух или четырёх, а структура подполей DLCI не всегда однозначно отличается от чтения ISO 3309. Приёмник не может надёжно определить границу адреса.

Вместо угадывания был задан явный порядок: Flag 0x7e, Q.922 Address, Control, NLPID 0xcf, PPP Protocol, затем Information и Padding. Address и Control относятся к доставке Frame Relay. 0xcf выбирает PPP. Следующее поле выбирает LCP, NCP или переносимый сетевой протокол. Поля определяют синтаксис, но не личность отправителя и не успех последующих стадий.

Отсюда запрет Address-and-Control-Field-Compression. В HDLC-like PPP постоянные значения можно убрать. В Frame Relay Address и Control непостоянны и меняются коммутационной сетью. Сжатие уничтожило бы значимый контекст доставки.

Байт, которому нужна история переговоров

Protocol-Field-Compression решает другую задачу: сокращает двухоктетное PPP Protocol до одного октета. После удаления NLPID и сжатия Protocol поле Information выравнивается на 32-битной границе, поэтому RFC рекомендует PFC там, где он повышает производительность.

Приём начинается с первого октета после заголовка. Ноль означает формат RFC 1490. 0xcf означает явный PPP NLPID. Иное ненулевое значение ожидается как сжатый PPP Protocol лишь при двух условиях: PFC включён, соответствующий NCP уже согласован. Иначе кадр следует читать по RFC 1490.

Таким образом, значение зависит от локального состояния. Чтобы при PFC не возникло коллизии, PPP Protocol 0x00cf зарезервирован. Текст допускает трактовать его как указатель на следующий пакет PPP Protocol, но не как свидетельство доставки. Реестры IANA и сегодня отдельно показывают NLPID 0xCF и зарезервированный PPP Protocol 00cf.

Один Identifier и несколько адресов

Начальные пакеты LCP несут после заголовка cf-c0-21: PPP NLPID и несжатый LCP Protocol c021. Распознанный LCP Configure-Request переводит канал в Link Establishment. Это начало переговоров, а не состояние Opened, успешная аутентификация или готовый NCP.

RFC описывает полезный признак неправильной топологии. Если предполагаемый канал точка-точка случайно подключили к multipoint network или multicast group, несколько узлов могут ответить на один Configure-Request. Несколько ответов с одинаковым Identifier, пришедших от разных framing addresses, должны вызвать сообщение об ошибочной конфигурации.

Identifier связывает ответы с запросом. Разные адреса показывают наблюдаемую множественность. Количество завершает доказательную комбинацию. Один ответ не доказывает единственного peer; DLCI не является глобальной идентичностью организации; отсутствие предупреждения тоже слабо, поскольку некоторые реализации физически не способны записать или сообщить framing address.

Когда эквивалентный формат перестаёт быть эквивалентным

Во время Link Establishment пакеты с другими NLPID нельзя отправлять, а полученные следует молча отбрасывать до фазы Network-Layer Protocol. Незавершённые переговоры PPP не должны уступать управление данным в другой грамматике.

После успешного согласования NCP тот же сетевой протокол в эквивалентной инкапсуляции RFC 1490 становится признаком потери состояния peer. Канал обязан вернуться в Link Establishment и отправить новый LCP Configure-Request. Иначе одна сторона продолжит пользоваться соглашением, которого другая уже не помнит, и трафик попадёт в чёрную дыру.

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

При неудаче решение остаётся локальным. Если необходима настройка PPP или согласованная функция вроде аутентификации, реализация может перейти в Termination. В противном случае после Max-Configure она обязана посылать только кадры RFC 1490. Остановка ради обязательного свойства и продолжение с меньшим набором свойств — разные исходы.

Ограничения реального оборудования

Канал должен быть full-duplex, постоянным или коммутируемым. Сигналы управления Frame Relay могут давать LCP события Up и Down, но их отказ не должен нарушать правильную работу PPP. Рекомендуются Magic Number и PFC. Начальный MRU равен 1600 октетам; сетевой MTU не должен превышать 1500 без явного согласования peer MRU не менее 2048.

Некоторые коммутаторы поддерживали кадры лишь до 262 октетов. Поэтому до завершения LCP реализация должна уметь ограничивать пакет LCP 259 октетами, оставляя место NLPID и Protocol. XID и Inverse ARP для таких PPP-каналов не обязательны: нужную функцию даёт согласование NCP. Это узкая граница применимости.

RFC 2427 позднее заменил общую многопротокольную спецификацию RFC 1490 и RFC 1294, а не RFC 1973. Документы и реестры подтверждают формат и номер, но не современное внедрение, настройки производителя, инцидент или результат услуги. RFC 1973 прямо не обсуждает безопасность, поэтому framing не доказывает целостность, конфиденциальность или аутентификацию.

Источники