Протокол РРР

Пакет LCP типа Code-Request

Пакет LCP типа Code-Request используется в том случае, когда сервер РРР получает от клиента пакет РРР с искаженным значением в поле Код. Это говорит о том, что версия РРР у клиента не совпадает с версией РРР на сервере или же у клиента неправильно установлена поддержка РРР. После того как сервер послал пакет такого типа, он немедленно разрывает РРР-соединение.

Пакет LCP типа Protocol-Request

Пакет LCP типа Protocol-Request применяется, если сервер РРР получает пакет РРР либо с искаженным значением в поле Протокол, либо с протоколом, который им не поддерживается. При этом в поле данных пакета этого типа включается копия отвергнутого пакета. Получение такого пакета клиентом свидетельствует о том, что указанный протокол не поддерживается сервером, о чем он сообщает пользователю.

Пакет LCP типа Echo-Request

Пакет LCP типа Echo-Request применяется для реализации метода обратной связи в РРР-соединении. Получив пакет Echo-Request, устройство РРР должно выдать в ответ на него пакет Echo-Reply. Довольно часто эта процедура используется для того, чтобы предотвратить преждевременное завершение соединения из-за отсутствия активности. Она может использоваться также в диагностических целях. Во время переговоров о параметрах соединения может быть определен параметр Magic-Number, который затем можно использовать в данном пакете для идентификации соединения.

Пакет LCP типа Echo-Reply

Как уже отмечалось, пакет LCP типа Echo-Reply используется в ответ на пакет Echo-Request. Если для соединения был определен параметр Magic-Number, то он должен включаться в этот пакет.

Пакет LCP типа Discard-Request

Пакет LCP типа Discard-Request применяется для тестирования соединения. Приемное устройство должно немедленно отбросить пакет Discard-Request. Никакого ответа на этот пакет приемное устройство посылать не должно. Пакет типа Discard-Request также должен содержать параметр Magic-Number, который был определен на стадии установления соединения.

Параметры переговоров LCP

При обмене пакетами Configure-Request в течение фазы переговоров клиент РРР может попросить изменить тот или иной параметр соединения. Если параметр не включен в пакет Configure-Request, то его значение принимается равным значению по умолчанию. На рис. 8.5 представлен формат полей параметров в пакете Configure-Request.

Рис. 8.5. Поля параметров пакета LCP типа Configure-Request

Поле Тип используется для идентификации параметра, о величине которого ведутся переговоры. В табл. 8.3 показаны возможные параметры.

Поле Длина имеет один октет в длину и определяет длину полей Параметры.

Максимальный принимаемый блок (Maximum Receive Unit — MRU)

Основной параметр LCP, о величине которого ведутся переговоры, — это максимальный принимаемый блок (Maximum Receive Unit) или MRU. Его значение определяет размер пакетов, которые будут передаваться через соединение. Чем больше размер пакета, тем больший объем данных может быть передан без перегрузки полосы. Однако слишком большой размер пакета может снижать производительность на плохих линиях, в которых часто появляются искажения, так как при появлении ошибки производится повторная передача всего пакета. Когда это возможно, устанавливается значение MRU равное 1500, что соответствует размеру пакета в сети Ethernet. Однако при низкоскоростном соединении рекомендуется снижать MRU до 296, благодаря этому снижается вероятность появления ошибок и, как следствие, уменьшается количество повторных передач.

Контроль качества (Quality Control)

Параметр контроля качества (Quality Control) используется, когда устройства желают определить качество установленного соединения. При возрастании количества ошибок желательно проверить качество соединения, и если оно не удовлетворяет определенным нормам, разорвать его. По умолчанию контроль качества соединения не производится. В RFC описан лишь один тип протокола контроля качества — протокол отчета о состоянии соединения Link Quality Report типа с025. При этом обе стороны, участвующие в соединении, должны согласовать использование контроля качества и его тип, прежде чем начать наблюдение за состоянием соединения.

Параметр "магическое число" (Magic-Number)

Параметр "магическое число" (Magic-Number) используется для реализации в РРР-соединении обратной связи. При этом образуется петля и клиент имитирует РРР-соединение с самим собой. Когда в пакет Configure-Request включен параметр Magic-Number, то получивший его хост РРР сравнивает это число с параметром Magic-Number из предыдущего пакета Configure-Request. Если они совпадают, то, скорее всего, имеет место соединение типа "петля". После того как параметр Magic-Number для сеанса РРР был определен, его можно употреблять в пакетах Echo-Request и Echo-Reply с целью проверки целостности соединения.

Параметр сжатия поля протокола (Protocol Field Compression)

Параметр сжатия поля протокола (Protocol Field Compression) применяется для идентификации метода сжатия, который используется обоими устройствами в РРР-соединении с целью экономии эффективной полосы пропускания. По умолчанию поле Протокол состоит из двух октетов. Если оба устройства РРР согласны использовать протокол сжатия, то это поле может быть сокращено на один октет. Если учесть, что во время сеанса РРР обычно передается несколько тысяч кадров, то мы получим значительную экономию полосы пропускания. Однако следует отметить, что в пакетах LCP нельзя использовать возможности сжатия поля Протокол. Кроме того, проверочная последовательность кадра FCS должна вычисляться со сжатым, а не с действительным полем Протокол.

Параметр сжатия полей адреса и управления (Address and Control Field Compression)

Параметр сжатия полей адреса и управления (Address and Control Field Compression) позволяет производить сжатие кадра РРР за счет сокращения полей HDLC Адрес и Управление. При этом полоса пропускания экономится даже на низкоскоростных линиях, а объем экономии больше, чем при сжатии поля Протокол. Подобно предыдущему параметру, значение проверочной последовательности кадра FCS вычисляется без этих полей.

Параметр протокола аутентификации (Authentication Protocol)

Параметр протокола аутентификации (Authentication Protocol) позволяет устройствам вести переговоры о методе проверки подлинности клиента при установлении соединения с хостом. Поскольку к сетевой безопасности в настоящее время предъявляются довольно высокие требования, то при установке РРР-соединения практически всегда проводится аутентификация клиента. На сегодняшний день поддерживаются два типа проверки подлинности клиента: тип с223 для протокола CHAP и тип с023 для протокола PAP. Более детально эти протоколы будут рассмотрены в следующем разделе.

Фаза аутентификации РРР

В качестве альтернативы проверки пользователя с помощью текстовой процедуры userid/password были разработаны два метода аутентификации. Широкое распространение в реализациях РРР получил протокол аутентификации PAP. По сравнению с PAP, протокол CHAP более безопасен и сейчас приобретает все большую популярность. В реализации РРР для ОС Linux реализованы оба этих метода проверки подлинности пользователей.