PPP (сетевой протокол)

PPP-протокол был разработан на основе HDLC и дополнен некоторыми возможностями^{[какими?]}, которые до этого встречались только в проприетарных протоколах.

Link Control Protocol (LCP) обеспечивает автоматическую настройку интерфейсов на каждом конце (например, установка размера пакетов) и опционально проводит аутентификацию. Протокол LCP работает поверх PPP, то есть начальная PPP-связь должна быть до работы LCP.

RFC 1994 описывает Challenge-handshake authentication protocol (CHAP), который является предпочтительным для соединений с провайдерами. Уже устаревший, Password authentication protocol (PAP) всё ещё иногда используется.

Другим вариантом аутентификации через PPP является Extensible Authentication Protocol (EAP)^[1].

После того, как соединение было установлено, поверх него может быть настроена дополнительная сеть. Обычно используется Internet Protocol Control Protocol (IPCP), хотя Internetwork Packet Exchange Control Protocol (IPXCP) и AppleTalk Control Protocol (ATCP) были когда-то популярны. Internet Protocol Version 6 Control Protocol (IPv6CP) получит большее распространение в будущем, когда IPv6 заменит IPv4 как основной протокол сетевого уровня.

PPP позволяет работать нескольким протоколам сетевого уровня на одном канале связи. Другими словами, внутри одного PPP-соединения могут передаваться потоки данных различных сетевых протоколов (IP, Novell IPX и т. д.), а также данные протоколов канального уровня локальной сети. Для каждого сетевого протокола используется Network Control Protocol (NCP), который его конфигурирует (согласовывает некоторые параметры протокола).

PPP NCP обеспечивает процесс создания соединения через PPP, инициирует и настраивает различные протоколы сетевого уровня, такие как IP, IPX или AppleTalk.

Microsoft PPP поддерживает следующие NCP:

• Internet Protocol Control Protocol (IPCP) для настройки IP.
• Internetwork Packet Exchange Control Protocol (IPXCP) для настройки IPX.
• AppleTalk Control Protocol (ATCP) для настройки AppleTalk.
• NetBIOS Frames Control Protocol (NBFCP) для настройки NetBEUI.

PPP обнаруживает закольцованные связи, используя особенность, включающую magic numbers. Когда узел отправляет PPP LCP сообщения, они могут включать в себя магическое число. Если линия закольцована, узел получает сообщение LCP со своим собственным магическим числом вместо получения сообщения с магическим числом клиента.

• Link Control Protocol устанавливает и завершает соединения, позволяя узлам определять настройки соединения. Также он поддерживает и байт-, и биториентированные кодировки.
• Network Control Protocol используется для определения настроек сетевого уровня, таких как сетевой адрес или настройки сжатия, после того, как соединение было установлено.

Так как в PPP входит LCP-протокол, то можно управлять следующими LCP-параметрами:

• Аутентификация. RFC 1994 описывает Challenge Handshake Authentication Protocol (CHAP), который является предпочтительным для проведения аутентификации в PPP, хотя Password Authentication Protocol (PAP) иногда ещё используется. Другим вариантом для аутентификации является Extensible Authentication Protocol (EAP).
• Сжатие. Эффективно увеличивает пропускную способность PPP-соединения за счёт сжатия данных в кадре. Наиболее известными алгоритмами сжатия PPP-кадров являются Stacker и Predictor.
• Обнаружение ошибок. Включает Quality-Protocol и помогает выявить петли обратной связи посредством Magic Numbers RFC 1661.
• Многоканальность. Multilink PPP (MLPPP, MPPP, MLP) предоставляет методы для распространения трафика через несколько физических каналов, имея одно логическое соединение. Этот вариант позволяет расширить пропускную способность и обеспечивает балансировку нагрузки.

Каждый кадр PPP всегда начинается и завершается байтом 0x7E. Затем следует байт адреса и байт управления, которые тоже всегда равны 0xFF и 0x03, соответственно. В связи с вероятностью совпадения байтов внутри блока данных с зарезервированными флагами существует система автоматической корректировки «проблемных» данных с последующим восстановлением.

Поля «Флаг», «Адрес» и «Управление» (заголовок кадра HDLC) могут быть опущены и не передаваться, но это произойдёт, если PPP в процессе конфигурирования (используя LCP) договорится об этом. Если PPP инкапсулирован в L2TP-пакеты, то поле «Флаг» не передаётся.

Поле «Данные» PPP-кадра, в свою очередь, разбиты ещё на два поля: флаг протокола (который определяет тип данных до конца кадра) и сами данные.

• Флаги протокола от 0x0XXX до 0x3XXX идентифицируют протоколы сетевого уровня. Например, популярному IP-протоколу соответствует флаг 0x0021, а Novell IPX — 0x002B.
• Флаги протокола от 0x4XXX до 0x7XXX идентифицируют протоколы с низким уровнем трафика.
• Флаги протокола от 0x8XXX до 0xBXXX идентифицируют протокол управления сетью (NCP).
• Флаги протокола от 0xCXXX до 0xEXXX идентифицируют управляющие протоколы. Например, 0xC021 обозначает, что кадр содержит данные протокола управления соединением LCP.

Фазы PPP по RFC 1661 указаны ниже:

• Link Dead. Эта фаза наступает, когда связь нарушена либо одной из сторон указали не подключаться (например, пользователь завершил модемное соединение.)
• Link Establishment Phase. В данной фазе проводится настройка Link Control. Если настройка была успешной, управление переходит в фазу аутентификации либо в фазу Network-Layer Protocol, в зависимости от того, требуется ли аутентификация.
• Authentication Phase. Данная фаза является необязательной. Она позволяет сторонам проверить друг друга перед установкой соединения. Если проверка успешна, управление переходит в фазу Network-Layer Protocol.
• Network-Layer Protocol Phase. В данной фазе вызывается NCP для желаемого протокола. Например, IPCP используется для установки IP-сервисов. Передача данных по всем успешно установленным протоколам также проходит в этой фазе. Закрытие сетевых протоколов тоже включается в данную фазу.
• Link Termination Phase. Эта фаза закрывает соединение. Она вызывается в случае ошибок аутентификации, если было настолько много ошибок контрольных сумм, что обе стороны решили закрыть соединение, если соединение неожиданно оборвалось либо если пользователь отключился. Данная фаза пытается закрыть всё настолько аккуратно, насколько возможно в данных обстоятельствах.

Протокол PPP определен в RFC 1661 (The Point-to-Point Protocol, июль 1994). Ряд соответствующих RFC был написан, чтобы определить, как различные сетевые протоколы, включая TCP/IP, DECnet, AppleTalk, IPX и другие, работают с PPP.

• RFC 1661, Standard 51, Протокол точка-точка (PPP)
• RFC 1662, Standard 51, Использование HDLC в разработке PPP
• RFC 1994, Аутентификация в PPP посредством (CHAP)
• RFC 5072, IPv6 и PPP.

• PPTP
• LCP
• IPCP
• MPPE
• pppd
• GRE
• SLIPpp
• PLIP^[англ.]