RFC 1661 The Point-to-Point Protocol (PPP)

image_print
Network Working Group                                      W. Simpson, Editor
Request for Comments: 1661                                         Daydreamer
STD: 51                                                             July 1994
Obsoletes: 1548
Category: Standards Track

Point-to-Point Protocol (PPP)

Протокол соединений «точка-точка»

PDF

Статус документа
Этот документ задает проект стандарта Интернет для сообщества Интернет и служит приглашением к дискуссии в целях совершенствования протокола. Информацию о состоянии стандартизации и текущем статусе протокола можно найти в «Internet Official Protocol Standards” (STD 1). Распространение этого документа не ограничивается.

Тезисы
Протокол PPP1 обеспечивает стандартный метод для транспортировки дейтаграмм разных протоколов через соединения «точка-точка». PPP включает три основных компоненты, перечисленных ниже.

  1. Метод инкапсуляции дейтаграмм разных протоколов.

  2. Протокол управления соединением LCP2.

  3. Протоколы управления сетью (NCP3) для установки и настройки протоколов сетевого уровня.

Этот документ определяет организацию и методологию PPP, а также инкапсуляцию PPP и расширяемый механизм согласования опций, позволяющий использовать многочисленные конфигурационные параметры и набор дополнительных функций управления. Протокол управления каналом PPP (LCP) описан в терминах этого механизма.

Содержание

Исключено в версии HTML

1. Введение

Протокол РРР разработан для простых линий связи, которые транспортируют пакеты между двумя узлами-партнерами. Эти соединения обеспечивают полнодуплексную двухстороннюю связь с сохранением порядка доставки пакетов. Предполагается, что РРР обеспечивает базовое решение для простого соединения различных хостов, мостов и маршрутизаторов [1].

Инкапсуляция

Инкапсуляция РРР обеспечивает мультиплексирование различных протоколов сетевого уровня через один канал. Эта инкапсуляция была разработана с учетом совместимости с наиболее распространенным оборудованием.

Для инкапсуляции применяется лишь 8 при использовании принятого по умолчанию кадрирования в стиле HDLC. В средах с дефицитной пропускной способностью издержки на инкапсуляцию и кадрирование могут быть сокращены до 2 или 4 октетов.

Для поддержки высокоскоростных реализаций принятая по умолчанию инкапсуляция использует лишь простые поля, из которых только одно нужно проверять для демультиплексирования. Используемый по умолчанию заголовок и информационные поля выравниваются по 32-битовым границам, а трейлер может дополняться до произвольной границы.

Протокол LCP

Для обеспечения достаточной универсальности и переносимости в разные среды протокол РРР включает протокол управления соединением (LCP). Этот протокол служит для автоматического согласования опций формата инкапсуляции, обработки ограничений на размеры пакетов, детектирования канальных петель и других конфигурационных ошибок, а также для разрыва соединений. Поддерживаются другие необязательные возможности для проверки подлинности отождествления партнера по каналу, контроля корректности работы соединения и обнаружения отказов.

Протоколы управления сетью (NCP)

Для соединений «точка-точка» характерна тенденция усугублять многие проблемы стека сетевых протоколов. Например, назначение и и поддержка адресов IP, которые являются проблемой в локальных сетях, дополнительно осложняются при работе по коммутируемым соединениям «точка-точка» (таким, как соединения с модемными пулами). Эти проблемы обрабатываются семейством протоколов управления NCP, которые решают конкретные задачи соответствующих протоколов сетевого уровня. Эти протоколы определены в сопутствующих документах.

Настройка

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

Автоматическая настройка конфигурации реализована на основе расширяемого механизма согласования опций, где каждая сторона соединения описывает партнеру свои возможности и потребности. Хотя механизм согласования описан в этом документе в терминах LCP, те же средства разработаны для использования с другими протоколами управления, в частности NCP.

1.1 Соглашения

В этом документе некоторые слова служат для задания уровня требований. Такие слова выделяются шрифтом.

MUST — должно

Это слово, а также термин требуется (REQUIRED) используется для требований, которые являются абсолютно необходимыми в данной спецификации.

MUST NOT — недопустимо

Эта фраза означает абсолютный запрет в рамках спецификации.

SHOULD — следует

Это слово, а также глагол рекомендуется (RECOMMENDED) используется для обозначения требований, от выполнения которых можно отказаться при наличии разумных причин. Однако при таком отказе следует помнить о возможных проблемах в результате отказа и принимать взвешенное решение.

MAY — можно, возможно

Это слово, а также прилагательное необязательный (OPTIONAL) обозначают элементы, реализация которых является необязательной. Реализация, не включающая ту или иную опцию, должна быть готова к работе с реализациями, которые используют эту опцию (возможно совместная работа будет обеспечиваться за счет некоторого ущерба функциональности).

1.2 Терминология

Ниже приведены определения терминов, часто используемых в этом документе.

Datagram — дейтаграмма

Единица передачи на сетевом уровне (например, IP). Дейтаграмма может инкапсулироваться в один или несколько пакетов, передаваемых канальному уровню.

Frame — кадр

Единица передачи на уровне логического канала данных. Кадр может включать заголовок и/или трейлер вместе с некоторым числом блоков данных.

Packet — пакет

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

Peer — партнер

Другая сторона соединения «точка-точка».

Silently discard – отбрасывание без уведомления

Реализация отбрасывает пакет без дальнейшей обработки. Реализации следует поддерживать возможность записи в системный журнал ошибок, включая содержимое отброшенных без уведомления кадров, а также следует учитывать такие события в счетчике статистики.

2. Инкапсуляция PPP

Инкапсуляция PPP позволяет различать дейтаграммы разных протоколов. Инкапсуляция требует кадрирования для указания начала и конца. Методы кадрирования описаны в сопутствующих документах.

Инкапсуляция РРР показана на рисунке. Поля передаются слева направо.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Protocol  |Information| Padding       |
| 8/16 битов|     *     |     *         |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Protocol

Поле Protocol состоит из одного или двух октетов и его значение указывает дейтаграмму, инкапсулированную в поле Information. Поле передается, начиная со старшего октета.

Структура этого поля совместима с механизмом расширения ISO 3309 для полей адреса. Все значения Protocol должны быть нечетными, т. е. младший бит младшего октета должен иметь значение 1. Значения поля должны назначаться так, чтобы младший бит старшего октета был равен 0. Принятые кадры, которые не соответствуют этим правилам, должны быть считаться кадрами с неизвестным протоколом.

Значения поля Protocol от 0*** до 3*** указывают пакеты пакеты конкретного протокола сетевого уровня, а значения от 8*** до b*** — пакеты, относящиеся в соответствующему протоколу NCP (если он имеется).

Значения поля Protocol 4*** до 7*** используются для протоколов с незначительным трафиком, не имеющих соответствующего NCP. Значения поля от c*** до f*** указывают пакеты протоколов управления соединением (такие, как LCP).

Современные значения поля Protocol указаны в действующем RFC «Assigned Numbers» [2]. Эта спецификация резервирует приведенные в таблице значения.

 

Шестнадцатеричное значение

Имя протокола

1

Протокол заполнения

0003 001f

Резерв (прозрачность неэффективна)

007d

Резерв (Control Escape)

00cf

Резерв (PPP NLPID)

00ff

Резерв (сжатие неэффективно)

8001 801f

Не используется

807d

Не используется

80cf

Не используется

80ff

Не используется

c021

LCP

c023

PAP4

c025

Link Quality Report

c223

CHAP5

 

Разработчики новых протоколов должны получить номер в агентстве IANA6, по адресу IANA@isi.edu.

Information

Поле Information может быть пустым и обычно включает дейтаграмму протокола, указанного в поле Protocol.

Максимальный размер поля Information, включая Padding, но без учета поля Protocol определяется размером максимального принимаемого блока переменной (MRU7), который по умолчанию составляет 1500 октетов. По согласованию совместимые реализации РРР могут установить другие значения MRU.

Padding

При передаче, поле Information может дополняться произвольным числом октетов, вплоть до MRU. Каждый протокол самостоятельно отличает заполнение от от реальной информации.

3. Работа соединений РРР

3.1 Обзор

Для коммуникаций через соединение «точка-точка», каждая сторона соединения РРР должна сначала передать пакеты LCP, служащие для настройки и тестирования канала данных. После организации соединения партнеры могут проверить подлинность друг друга.

После этого РРР должен передать пакеты NCP для выбора и настройки одного или множества протоколов сетевого уровня. После настройки каждого из этих протоколов дейтаграммы протокола могут передаваться через канал.

Соединения остается настроенными для передачи данных до тех пор, пока заключительный соединение не будет закрыто явным пакетом LCP или NCP или не произойдет то или иное внешнее событие (таймер бездействия или действия администратора).

3.2 Фазы протокола

В процессе настройки, поддержки и разрыва соединение РРР проходит через несколько разных фаз, которые показаны на рисунке ниже.

+------+        +-----------+           +--------------+
|      | UP     |           | OPENED    |              | SUCCESS/NONE
| Dead |------->| Establish |---------->| Authenticate |--+
|      |        |           |           |              |  |
+------+        +-----------+           +--------------+  |
   ^               |                        |             |
   |          FAIL |                   FAIL |             |
   +<--------------+             +----------+             |
   |                             |                        |
   |            +-----------+    |           +---------+  |
   |       DOWN |           |    |   CLOSING | Network |  |
   +------------| Terminate |<---+<----------|  layer  |<-+
                |           |                | protocol|
                +-----------+                +---------+


На диаграмме указаны не все переходы. Должна соблюдаться описанная ниже семантика.

3.3 Link Dead

Соединение всегда начинается и завершается этой фазой. Когда внешнее событие (например, детектирование соединения на физическом уровне или настройка сетевым администратором) покажет, что физический уровень готово к использованию, РРР перейдет в фазу Link Establishment.

В течение этой фазы, машина LCP (см. ниже) будет находиться в состояниях Initial или Starting. Переход в фазу Link Establishment будет сигналом Up для машины состояний LCP.

Примечание для разработчиков. Обычно соединение возвращается в эту фазу после отключения модема. В случае фиксированного соединения (hard-wired link) эта фаза может быть крайне непродолжительной – достаточно просто определить присутствие другого устройства.

3.4 Link Establishment

Протокол LCP служит для организации соединения путем обмена пакетами Configure. Этот обмен завершается и соединение переходит в состояние LCP после обмена пакетами ConfigureAck (см. ниже).

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

Важно отметить, что LCP может настраивать лишь опции конфигурации, которые не зависят от конкретного протокола сетевого уровня. Настройка протоколов сетевого уровня выполняется отдельными протоколами NCP в фазе NetworkLayer Protocol.

Все пакеты, не относящиеся к LCP, которые полученны в этой фазе, должны отбрасываться без уведомления.

Получение пакета LCP ConfigureRequest вызывает возврат из фаз NetworkLayer Protocol и Authentication в фазу Link Establishment.

3.5 Authentication

На некоторых каналах может оказаться желательным запрос аутентификации партнера до начала обмена пакетами сетевого уровня.

По умолчанию аутентификация не требуется. Если реализация желает аутентифицировать партнера с помощью конкретного протокола проверки подлинности, она должна запросить использование этого протокола аутентификации в фазе Link Establishment.

Аутентификацию следует выполнять сразу после организации соединения. Однако одновременно с этим может выполняться проверка качества соединения. Реализации недопустимо разрешать обмен пакетами проверки качества соединения с задержкой аутентификации на неопределенный срок.

Переход из фазы Authentication в фазу Network-Layer Protocol недопустим до завершения проверки подлинности. Если аутентификация завершилась отказом, инициировавшей ее стороне следует перейти в фазу Link Termination.

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

Примечание для разработчиков. Реализации не следует выдавать отказ при аутентификации на основании лишь тайм-аута или отсутствия ответа. Для аутентификации следует поддерживать тот или иной метод повтора передачи и переходить в фазу Link Termination только после заданного числа попыток.

За переход в фазу Link Termination отвечает реализация, отклонившая аутентификацию партнера.

3.6 NetworkLayer Protocol

После того как РРР завершил предыдущие фазы, каждый протокол сетевого уровня (IP, IPX, AppleTalk) должен быть настроен отдельно соответствующим протоколом NCP.

Каждый протокол NCP в любой момент может находиться в состоянии Opened или Closed.

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

После того как NCP перейдет в состояние Opened, РРР может передавать пакеты соответствующего протокола сетевого уровня. Все пакеты протоколов сетевого уровня, принятые до того, как соответствующий NCP перейдет в состояние Opened, должны отбрасываться без уведомления.

Примечание для разработчиков. Пока LCP находится в состоянии Opened, для любого пакета не поддерживаемого реализацией протокола должен возвращаться отклик ProtocolReject (см. ниже). Отбрасываются без уведомления лишь пакеты поддерживаемых протоколов.

В этой фазе трафик соединения может включать любые комбинации пакетов LCP, NCP и протоколов сетевого уровня.

3.7 Link Termination

РРР может завершить соединение в любой момент. Это может быть обусловлено потерей несущей, отказом при аутентификации или проверке качества соединения, а завершением отсчета таймера бездействия или административным разрывом соединения.

LCP используется для закрытия соединения путем обмена пакетами Terminate. При закрытии соединения РРР информирует протоколы сетевого уровня, чтобы они могли выполнить соответствующие действия.

После обмена пакетами Terminate, реализации следует сообщить физическому уровню о разрыве соединения, чтобы разорвать соединение на физическом уровне, особенно в случае отказа при аутентификации. Отправителю пакета TerminateRequest следует отключиться после получения пакета TerminateAck или по завершении отсчета Restart. Получателю пакета TerminateRequest следует ждать отключения партнера и недопустимо отключаться пока не пройдет как минимум один интервал Restart после передачи TerminateAck. РРР следует перейти в фазу Link Dead.

Все пакеты, не относящиеся к LCP, полученные в течение этой фазы, должны отбрасываться без уведомления.

Примечание для разработчиков. Закрытия соединения с помощью LCP достаточно и протоколам NCP не требуется передавать пакеты Terminate. И наоборот, перехода NCP в состояние Closed не является достаточным основанием для закрытия соединения РРР, даже если этот NCP был единственным протоколом в состоянии Opened.

4. Машина согласования опций

Автоматизация конечных состояний определяется событиями, действиями и сменой состояний. События включают получение внешних команд, таких как Open и Close, завершение отсчета таймера Restart, получение пакетов от партнера. Действия включают запуск таймера Restart и передачу пакетов партнеру.

Некоторые типы пакетов — ConfigureNak и ConfigureReject, CodeReject и ProtocolReject, EchoRequest, EchoReply и DiscardRequest не различаются в описаниях автомата. Как будет показано ниже, эти пакеты в действительности служат для разных функций. Однако они всегда приводят к одинаковым сменам состояний.

 

События

Действия

Up

Нижележащий уровень в состоянии Up

tlu

Данный уровень в состоянии Up

Down

Нижележащий уровень в состоянии Down

tld

Данный уровень в состоянии Down

Open

Административный переход в состояние Open

tls

Данный уровень в состоянии Started

Close

Административный переход в состояние Close

tlf

Данный уровень в состоянии Finished

TO+

Тайм-аут с незавершенным (>0) счетчиком

irc

Initialize-Restart-Count

TO-

Тайм-аут с завершенным счетчиком

zrc

Zero-Restart-Count

RCR+

Получен корректный запрос Configure-Request

scr

Передан Configure-Request

RCR-

Получен некорректный запрос Configure-Request

RCA

Получен Configure-Ack

sca

Передан Configure-Ack

RCN

Получен Configure-Nak/Rej

scn

Передан Configure-Nak/Rej

RTR

Получен Terminate-Request

str

Передан Terminate-Request

RTA

Получен Terminate-Ack

sta

Передан Terminate-Ack

RUC

Получен неизвестный код

scj

Передан Code-Reject

RXJ+

Получен Code-Reject (разрешено)
или Protocol-Reject

RXJ-

Получен Code-Reject (катастрофа)
или Protocol-Reject

RXR

Получен Echo-Request
или Echo-Reply
или Discard-Request

ser

Передан Echo-Reply

 

4.1 Таблица переходов состояний

Полная таблица смены состояний приведена ниже. Состояния указаны в верхней строке, событияв левом столбце. Смены состояний и действия представлены в форме действие/новое состояние. Множественные действия разделены запятыми и могут продолжаться в следующих строках, множественные действия могут быть реализованы в любом удобном порядке. Дефис (-) показывает недопустимость смены состояния.

Состояние

События

0
Initial

1
Starting

2
Closed

3
Stopped

4
Closing

5
Stopping

6
Req-Sent

7
Ack-Rcvd

8
Ack-Sent

9
Opened

Up
Down
Open
Close

2

tls/1
0

irc,scr/6

1
tlf/0


0
irc,scr/6
2


tls/1
3r8
2


0
51
4


1
51
4


1
6
irc,str/4


1
7
irc,str/4


1
8
irc,str/4


tld/1
91
irc,str/4

TO+
TO-





str/4
tlf/5

str/5
tlf/3

scr/6
tlf/39

scr/6
tlf/32

scr/8
tlf/32


RCP+
RCP-
RCA
RCN







sta/2
sta/2
sta/2
sta/2

irc,scr,sca/8
irc,scr,sca/8
sta/3
sta/3

4
4
4
4

5
5
5
5

sca/8
scn/6
irc/7
irc,scr/6

sca,tlu/8
scn/7
scr/610
scr/63

sca/8
scn/6
irc,tlu/9
irc,scr/8

tld,scr,sca/8
tld,scr,scn/6
tld,scr/63
tld,scr/63

RTR
RTA



sta/2
2

sta/3
3

sta/4
tlf/2

sta/5
tlf/3

sta/6
6

sta/6
6

sta/6
8

tld,zrc,sta/5
tld,scr/6

RUC
RXJ+
RXJ-





scj/2
2
tlf/2

scj/3
3
tlf/3

scj/4
4
tlf/2

scj/5
5
tlf/3

scj/6
6
tlf/3

scj/7
6
tlf/3

scj/8
8
tlf/3

scj/9
9
tld,irc,str/5

RXR

2

3

4

5

6

7

8

ser/8

Состояния, в которых таймер Restart запущен, узнаваемы по присутствию событий TO. Таймер Restart запускают или перезапускают лишь действия Send-Configure-Request, Send-Terminate-Request и Zero-Restart-Count. Таймер Restart останавливается, когда происходит переход из состояния, где таймер работает, в состояние, где таймер не работает.

События и действия, определяются в соответствии с проходящими сообщениями, а не архитектурой сигнализации. Если для действия желательно управление конкретными сигналами (например, DTR), могут потребоваться дополнительные действия.

4.2 Состояния

Ниже переведено детальное описание каждого состояния машины конечных состояний.

Initial

В состояние Initial нижний уровень недоступен (Down) и не происходит событий Open. Таймер Restart не работает в состоянии Initial.

Starting

Состояние Starting является аналогом Open для состояния Initial. Был инициирован административный переход в Open, но нижний уровень все еще не доступен (Down). Таймер Restart не работает в этом состоянии.

Когда нижний уровень станет доступен (Up), передается сообщение ConfigureRequest.

Closed

В состоянии Closed соединение доступно (Up), но событие Open еще не произошло. Таймер Restart не работает в состоянии Closed.

В ответ на прием пакетов ConfigureRequest посылается TerminateAck. TerminateAck отбрасывается для предотвращения образования петли.

Stopped

Состояние Stopped является аналогом Open для состояния Closed. Это состояние возникает, когда машина ждет события Down после действия ThisLayerFinished или после отправки TerminateAck. Таймер Restart не работает в состоянии Stopped.

При получении пакетов ConfigureRequest, передается подходящий ответ, при получении других пакетов — TerminateAck. Сообщения TerminateAck отбрасывается без уведомления для предотвращения петель.

Обоснование. Состояние Stopped является переходным при разрыве соединения, отказе при настройке и отказах машины состояний. Оно потенциально разделяет состояния, которые были объединены.

Это вариант состязания между откликом на событие Down (в результате ThisLayerFinished) и событием ReceiveConfigureRequest. Когда сообщение ConfigureRequest приходит до события Down, это событие будет вытеснено возвратом машины в состояние Starting. Это предотвращает атаку на основе повторов.

Вариант реализации. После того как партнер отказался ответить на сообщения ConfigureRequest, реализация может пассивно ждать, когда партнер передаст ConfigureRequest. В этом случае действие ThisLayerFinished не используется для события TO— в состояниях ReqSent, AckRcvd и AckSent.

Эта опция полезна на выделенных устройствах и каналах не имеющих сигналов состояния, но ее не следует применять для коммутируемых каналов.

Closing

В состоянии Closing предпринимается попытка разорвать соединение. Запрос TerminateRequest передан и таймер Restart запущен, но сообщение TerminateAck еще не получено.

При получении TerminateAck происходит переход в состояние Closed. По завершении отсчета таймера Restart передается новое сообщение TerminateRequest и таймер перезапускается. После того, как отсчет таймера завершился MaxTerminate раз, происходит переход в состояние Closed.

Stopping

Состояние Stopping является аналогом Open для состояния Closing. Запрос TerminateRequest передан и таймер Restart запущен, но сообщение TerminateAck еще не получено.

Обоснование. Состояние Stopping предоставляет шанс завершить соединения до того, как появится новый трафик. После разрыва соединения может быть создана новая конфигурация через состояния Stopped или Starting.

RequestSent

Состояние RequestSent является попыткой настроить соединение. Запрос ConfigureRequest передан, таймер Restart запущен, но сообщение ConfigureAck еще не получено и не передано.

AckSent

В состоянии AckSent сообщения ConfigureRequest и ConfigureAck уже посланы, но подтверждение ConfigureAck еще не получено. Таймер Restart запущен, поскольку сообщение ConfigureAck не получено.

Opened

В состоянии Opened подтверждение ConfigureAck передано и получено. Таймер Restart не запущен.

При переходе в состояние Opened реализации следует сообщить вышележащим уровням о событии Up. При выходе из состояния Opened реализации следует сообщить вышележащим уровням о событии Down.

4.3 События

Смены состояния и действия машины состояний обусловлены событиями, перечисленными ниже.

Up

Это событие происходит, когда нижележащий уровень показывает что он готов передавать пакеты.

Обычно это событие используется для работы с модемом, вызывающим процессорм или какой-то другой связкой РРР с физической средой, чтобы сообщить LCP о переходе соединения в фазу Link Establishment.

Событие также используется LCP для уведомления каждого NCP о переходе соединения в фазу NetworkLayer Protocol, т. е. действие ThisLayerUp в LCP вызывает событие Up в NCP.

Down

Это события происходит, когда нижний уровень показывает, что он не готов дальше передавать пакеты.

Обычно это событие используется для работы с модемом, вызывающим процессорм или какой-то другой связкой РРР с физической средой, чтобы сообщить LCP о переходе соединения в фазу Link Dead.

Событие также используется LCP для уведомления каждого NCP о выходе канала из фазы NetworkLayer Protocol, т. е. действие ThisLayerDown в LCP вызывает событие Down в NCP.

Open

Это событие показывает, что соединение административно доступно для трафика, т. е. сетевой администратор (человек или программа) указал, что соединению разрешен переход в состояние Opened. Если это событие происходит, когда канал находится не в состоянии Opened, машина состояний пытается передать партнеру пакеты настройки конфигурации.

Если автомат не может начать настройку конфигурации (нижележащий уровень в состоянии Down или предыдущее событие Close не завершено), организация соединения автоматически задерживается.

При получении запроса TerminateRequest или других событиях, которые делают канал недоступным, машина перейдет в состояние, где канал будет готов к посторному соединению. Административного вмешательства не требуется.

Примечание для разработчиков. Опыт показывает, что пользователи выполняют дополнительную команду Open, если им нужно заново согласовать соединение. Это может указывать согласование новых значений.

Поскольку это не означает события Open, предполагается, что при выполнении пользовательской команды Open в состоянии Opened, Closing, Stopping или Stopped реализация создает событие Down, за которым сразу же следует событие Up. Нужно принять меры против получения промежуточного состояния Down из другого источника.

Событие Down, за которым следует Up, приводит к упорядоченному повторному согласованию канала путем прохождения от состояния Starting к состоянию Request-Sent. Это приведет к повторному согласованию канала без негативных побочных эффектов.

Close

Это событие показывает, что канал недоступен для трафика, т. е. сетевой администратор (человек или программа) указал, что каналу запрещен переход в состояние Opened. Когда такое событие происходит в отличном от Closed состоянии канала, автоматически предпринимается попытка разорвать соединение. Дальнейшие попытки перенастроить канал отвергаются, пока не произойдет новое событие Open.

Примечание для разработчиков. При отказе аутентификации канал следует разорвать для предотвращения повторных атак и отказа в обслуживании других пользователей. Поскольку соединение административно доступно (по определению), это может быть достигнуто имитацией события Close для LCP, за которой незамедлительно следует событие Open. Нужно позаботиться о том, чтобы событие Close не могло быть вызвано другим источником.

Событие Close, за которым следует Open, будет приводить к упорядоченному завершению соединения, проходящему через состояния Closing и Stopping, когда действие ThisLayerFinished может отключить соединение. Машина будет ожидать в состоянии Stopped или Starting для следующей попытки соединения.

Timeout (TO+,TO-)

Это событие показывает завершение отсчета таймера Restart, который определяет время ответа на запросы ConfigureRequest и TerminateRequest.

Событие TO+ показывает, что значение счетчика Restart остается больше нуля, что вызывает повторную передачу пакетов ConfigureRequest и TerminateRequest.

Событие TO— показывает, что значение счетчика Restart не больше нуля и больше не требуется повторять передачу пакетов.

Receive-Configure-Request (RCR+,RCR-)

Это событие обусловлено получением от партнера пакета ConfigureRequest, который показывает желание создать соединение и может содержать параметры конфигурации. Пакет ConfigureRequest будет описан ниже.

Событие RCR+ говорит о том, что запрос ConfigureRequest был воспринят и вызвал отправку соответствующего пакета ConfigureAck.

Событие RCR— показывает, что пакет ConfigureRequest не был воспринят и вызвал отправку соответствующего пакета ConfigureNak или ConfigureReject.

Примечание для разработчиков. Эти события могут произойти, когда соединение уже находится в состоянии Opened. Реализация должна быть готова повторно согласовать конфигурационные опции.

ReceiveConfigureAck (RCA)

Это событие обусловлено приемом корректного пакета ConfigureAck от партнера. Пакет ConfigureAck является положительным ответом на пакет ConfigureRequest. Пакеты с нарушением порядка доставки и другие недействительные пакеты отбрасываются.

Примечание для разработчиков. Поскольку корректный пакет уже был получен до перехода в состояние AckRcvd или Opened, получение других таких пакетов крайне маловероятно. Как было отмечено, все недействительные пакеты Ack/Nak/Rej отбрасываются и не влияют на состояние машины.

Однако не исключено прибытие корректно сформированного пакета из совпадающего по времени кросс-соединения. Скорей всего это будет ошибкой реализации. Такие события следует по меньшей мере записывать в системный журнал.

Receive-Configure-Nak/Rej (RCN)

Это событие обусловлено получением от партнера действительного пакета ConfigureNak или ConfigureReject, которые являются негативными откликами на ConfigureRequest. Пакеты с нарушением порядка доставки и другие недействительные пакеты отбрасываются без уведомления.

Примечание для разработчиков. Хотя ConfigureNak и ConfigureReject вызывают одинаковые смены состояния, эти пакеты по-разному влияют на конфигурационные параметры, передаваемые в результирующем пакете ConfigureRequest.

ReceiveTerminateRequest (RTR)

Это событие обусловлено получением пакета TerminateRequest. Запрос TerminateRequest уазывает желание партнера закрыть соединение.

Примечание для разработчиков. Это событие не идентично событию Close (см. выше) и не отменяет команды Open от локального сетевого администратора. Реализация должна быть готова получить новый пакет ConfigureRequest без вмешательства сетевого администратора.

ReceiveTerminateAck (RTA)

Это событие происходит, когда от удаленной стороны получен пакет TerminateAck. Пакет TerminateAck обычно является ответом на пакет TerminateRequest. Так же он может указывать на то, что удаленная сторона находится в состоянии Closed или Stopped, а так же служит для повторной синхронизации конфигурации соединения.

ReceiveUnknownCode (RUC)

Это событие обусловлено получением от партнера пакета, который не удается интерпретировать. В ответ передается пакет Code-Reject.

Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)

Это событие обусловлено получением от партнера пакета CodeReject или ProtocolReject.

Событие RXJ+ происходит, когда отвергнутое значение приемлемо, например, CodeReject из расширенного кода или ProtocolReject от NCP. Это не выходит за пределы нормального функционирования. Реализация должна прекратить передачу соответствующего типа пакетов.

Событие RXJпроисходит, когда отвергнутое значение критично, например, CodeReject для ConfigureRequest или ProtocolReject от LCP. Это событие вызывает непоправимую ошибку и разрывает соединение.

ReceiveEchoRequest, ReceiveEchoReply, ReceiveDiscardRequest (RXR)

Это событие обусловлено получением от партнера пакетов EchoRequest, EchoReply или DiscardRequest. Пакет EchoReply является откликом на EchoRequest. Для пакетов EchoReply или DiscardRequest откликов не бывает.

4.4 Действия

Действия в машине состояний обусловлены событиями и обычно указывают отправку пакетов и/или запуском или остановкой таймера Restart.

IllegalEvent (-)

Это действие указывает событие, которого не могло произойти в правильно реализованной машине. Реализация имеет внутренние ошибки, которые следует занести в системный журнал. Смены состояний не происходит и реализации не следуе выполнять сброс или останавливаться.

ThisLayerUp (tlu)

Это действие показывает вышележащим уровням переход в состояние Opened.

Обычно это действие используется протоколом LCP для информирования о событии Up протокола аутентификации, контроля качества канала или NCP, а также может применяться NCP для индикации доступности канала для трафика сетевого уровня.

ThisLayerDown (tld)

Это действие показывает вышележащим уровням выход из состояния Opened.

Обычно это действие используется протоколом LCP для информирования о событии Down протокола аутентификации, контроля качества канала или NCP, а также может применяться NCP для индикации недоступности канала для трафика сетевого уровня.

ThisLayerStarted (tls)

Это действие показывает нижележащим уровням выход из состояния Starting и потребность в канале нижележащего уровня. Нижележащему уровню следует ответить событием Up, когда этот уровень будет доступен.

Результат этого действия зависит от реализации.

ThisLayerFinished (tlf)

Это действие показывает нижележащим уровням переход машины в состояние Initial, Closed или Stopped, когда нижележащий уровень больше не требуется для канала. Нижележащему уровню следует ответить событием Down, когда канал будет разорван.

Обычно это действие может использоваться протоколом LCP перед фазой Link Dead и может применяться также NCP для индикации протоколу LCP возможности разорвать соединение при отсутствии других открытых NCP.

Результат этого действия зависит от реализации.

InitializeRestartCount (irc)

Это действие устанавливает подходящее значение счетчика Restart (MaxTerminate или MaxConfigure). Счетчик декрементируется после каждой отправки, включая первую.

Примечание для разработчиков. В дополнение к установке счетчика Restart реализация должна установить начальное значение для тайм-аута при снижении значения для таймера Restart.

ZeroRestartCount (zrc)

Это действие устанавливает Restart = 0.

Примечание для разработчиков. Это действие позволяет приостановить FSA перед переходом в желаемое финальное состояние, позволяя партнеру обработать трафик. Кроме сброса в 0 счетчика Restart реализация должна установить подходящее значение для тайм-аута.

Send-Configure-Request (scr)

Передается пакет Configure-Request. Это указывает желание создать соединение с заданным набором конфигурационных опций. При отправке ConfigureRequest запускается таймер Restart для защиты от потери пакетов. Счетчик Restart декрементируется при каждой передаче пакета ConfigureRequest.

SendConfigureAck (sca)

Передается пакет ConfigureAck, подтверждающий прием ConfigureRequest с приемлемым набором конфигурационных опций.

Send-Configure-Nak (scn)

Передан пакет Configure-Nak или Configure-Reject, служащий негативным откликом на пакет ConfigureRequest с неприемлемым набором конфигурационных опций.

Пакеты ConfigureNak служат для отказа от значения Configuration Option и предлагают приемлемый набор опций. Пакеты ConfigureReject используются для отказа от согласования конфигурационных опций, обычно по причине того, что они не распознаны или не реализованы.

Send-Terminate-Request (str)

Передан пакет Terminate-Request, указывающий желание закрыть соединение. При передаче пакета TerminateRequest запускается таймер Restart. Счетчик Restart декрементируется при каждой передаче TerminateRequest.

Send-Terminate-Ack (sta)

Передан пакет Terminate-Ack, служащий для подтверждения приема TerminateRequest или синхронизации машин состояний.

Send-Code-Reject (scj)

Передан пакет Code-Reject, указывающий получение пакета неизвестного типа.

Send-Echo-Reply (ser)

Передан пакет Echo-Reply, подтверждающий прием пакета EchoRequest.

4.5 Предотвращение петель

Протокол делает предпринимает попытки избавится от петель согласования конфигурационных опций. Однако протокол не гарантирует отсутствие петель. Как при любом согласовании можно настроит две реализации РРР с конфликтующими политиками, которые никогда не сойдутся. Можно также настроить политики, которые будут сходиться, но это займет осень много времени. Разработчикам следует принимать это во внимание, а также следует реализовать механизм обнаружения петель или тайм-аутов на вышележащих уровнях.

4.6 Счетчики и таймеры

Restart

В машине состояний используется один таймер. Таймер Restart служит для управления временем передачи пакетов ConfigureRequest и TerminateRequest. Завершение отсчета этого таймера вызывает событие Timeout и повтор передачи соответствующего пакета ConfigureRequest или TerminateRequest. Таймер Restart должен быть настраиваемым и по умолчанию следует установить значение три (3) секунды.

Примечание для разработчиков. Значение таймера Restart следует устанавливать в зависимости от скорости соединения. Принятое по умолчанию значение рассчитано на низкоскоростные (2400 — 9600 бит/с) коммутируемые линии с медленной коммутацией (обычные телефонные линии). Для высокоскоростных соединений или соединений с быстрой коммутацией следует выбирать меньшие значения.

Вместо постоянного значения можно изначально устанавливать для таймер Restart небольшое значение и постепенно повышать его до заданного в конфигурации конечного значения. При этом каждое новое значение следует делать по как минимум вдвое больше предыдущего, пока не достигнут заданный максимум. Начальное значение следует выбирать не меньше удвоенного времени передачи пакета с поддерживаемой в канале скоростью с добавлением не менее 100 мсек, чтобы позволить партнеру обработать пакет перед отправкой отклика. На некоторых соединениях добавляется еще 200 мсек задержки в спутниковом канале. Время кругового обхода для модемов со скоростью 14400 бит/с составляет от 160 до 600 миллисекунд.

MaxTerminate

Имеется один обязательный счетчик повторов для запросов TerminateRequest. Счетчик MaxTerminate показывает число переданных пакетов Terminate-Request, на которые не было получено откликов TerminateAck до того, как будет сделан вывод о невозможности партнера ответить. Счетчик MaxTerminate должен быть настраиваемым и по умолчанию следует установить два (2) повтора.

MaxConfigure

Аналогичный предыдущему счетчик рекомендуется и для запросов ConfigureRequest. Счетчик MaxConfigure показывает число переданных пакетов ConfigureRequest, на которые не было получено откликов ConfigureAck, ConfigureNak или ConfigureReject до того, как будет сделан вывод о невозможности партнера ответить. Счетчик MaxConfigure должен быть настраиваемым и по умолчанию следует установить десять (10) повторов.

MaxFailure

Похожий счетчик рекомендуется для ConfigureNak. Счетчик MaxFailure показывает число переданных пакетов ConfigureNak без передачи ConfigureAck до того, как будет сделан вывод о том, что конфигурация не сходится. Все дополнительные пакеты ConfigureNak для опций, запрошенных партнером, будут преобразованы в пакеты ConfigureReject, а опции, запрошенные локальной стороной, не будут добавляться. Счетчик MaxFailure должен быть настраиваемым и по умолчанию следует установить пять (5) повторов.

5. Форматы пакетов LCP

Существует три класса пакетов LCP, перечисленных ниже.

  1. Организация и настройка соединения (ConfigureRequest, ConfigureAck, ConfigureNak и ConfigureReject).

  2. Завершение соединения (Terminate-Request и Terminate-Ack).

  3. Обслуживание и отладка канала (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply и Discard-Request).

Для упрощения в пакетах LCP отсутствует поле версии. Корректно работающая реализация LCP будет всегда отвечать на незнакомые значения Protocol и Code легко распознаваемым пакетом LCP, предоставляя таким образом детерминированный механизм «отступления» для реализаций других версий протокола.

Независимо от разрешенных опций конфигурации, все LCP-пакеты Link Configuration, Link Termination и CodeReject (коды 1 — 7) всегда передаются как при отсутствии согласования опций конфигурации. В частности каждая конфигурационная опция задает принятое по умолчанию значение. Это гарантирует распознаваемость таких пакетов LCP даже в тех случаях, когда одна сторона соединения ошибочно считает соединение отрытым.

В поле PPP Information инкапсулируется один пакет LCP, при этом поле PPP Protocol имеет шестнадцатеричное значение c021 (LCP).

Формат пакета LCP показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

Code

Однооктетное поле Code указывает тип пакета LCP. При получении пакета с неизвестным полем Code передается пакет CodeReject.

Современные значения поля Code определены в актуальном RFC «Assigned Numbers» [2]. Связанные с этим документом значения перечислены ниже.

  1. Configure-Request

  2. Configure-Ack

  3. Configure-Nak

  4. Configure-Reject

  5. Terminate-Request

  6. Terminate-Ack

  7. Code-Reject

  8. Protocol-Reject

  9. Echo-Request

  10. Echo-Reply

  11. Discard-Request

Identifier

Однооктетное поле Identifier служит для сопоставления откликов с запросами. При получении пакета с недействительным полем Identifier такой пакет отбрасывается без уведомления и обработки.

Length

Двухоктетное поле Length указывает размер пакета LCP с учетом полей Code, Identifier, Length и Data. Значению поля Length недопустимо превышать MRU для соединения.

Октеты за пределами размера, заданного полем Length, считаются заполнением и игнорируются получателем пакета. Пакеты с недопустимым значением поля Length отбрасываются без уведомления и обработки.

Data

Поле Data содержит октеты данных в соответствии со значением поля Length. Формат поля Data определяется полем Code.

5.1 ConfigureRequest

Реализация, желающая организовать соединение должна передать пакет ConfigureRequest. Поле Options заполняется любыми желательными значениями, изменяющими принятые по умолчанию. Не следует включать опции с принятыми по умолчанию значениями.

При получении пакета ConfigureRequest должен передаваться соответствующий отклик.

Поля пакета ConfigureRequest показаны ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+

Code

1 (Configure-Request).

Identifier

Поле Identifier должно изменяться всякий раз при изменении содержимого поля Options или получении действительного отклика на предыдущий запрос. При повторе поле Identifier может сохраняться.

Options

Поле Options переменного размера содержит список (возможно пустой) конфигурационных опций, которые отправитель желает согласовать. Все конфигурационные опции согласуются совместно. Формат конфигурационных опций описан ниже.

5.2 ConfigureAck

Если каждая конфигурационная опция, полученная в ConfigureRequest, опознана и все значения приемлемы, реализация должна передать отклик ConfigureAck. Для подтвержденных опций конфигурации недопустимо менять порядок или вносить иные изменения.

Поле Identifier в принятом пакете ConfigureAck должно соответствовать значению в последнем переданном пакете ConfigureRequest. Кроме того, конфигурационные опции в ConfigureAck должны совпадать с опциями в последнем переданном пакете ConfigureRequest. Недействительные пакеты отбрасываются без уведомления.

Формат пакета ConfigureAck показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+

Code

2 (Configure-Ack).

Identifier

Поле Identifier содержит копию одноименного поля в пакете ConfigureRequest, вызвавшем передачу ConfigureAck.

Options

Поле Options переменного размера содержит список (возможно пустой) конфигурационных опций, которые отправитель подтверждает. Все конфигурационные опции подтверждаются совместно.

5.3 ConfigureNak

Если полученные конфигурационные опции опознаны, но некоторые значения не приемлемы, реализация должна передать пакет ConfigureNak. В поле Options указываются только неприемлемые опции из пакета ConfigureRequest, а пригодные опции исключаются из ConfigureNak, но при этом недопустимо менять порядок опций из ConfigureRequest.

Для опций, не имеющих значений (логические), вместо ConfigureNak должен использоваться отклик ConfigureReject.

Для каждой конфигурационной опции, которая допустима лишь в одном экземпляре, значение в ConfigureNak должно быть заменено приемлемым. Можно использовать принятое по умолчанию значение, если оно отличается от запрошенного.

Когда конкретная опции может указываться более одного раза с разными значениями, пакет ConfigureNak должен включать список всех значений этой опции, приемлемых для отправителя ConfigureNak. Включаются также приемлемые значения, которые присутствовали в ConfigureRequest.

Реализация может быть настроена на запрос согласования определенной опции. Если эта опция не указана, ее можно добавить в список опций ConfigureNak, как предложение партнеру включить эту опцию в следующий пакет ConfigureRequest. Все поля опций должны содержать значения, приемлемые для отправителя ConfigureNak.

Поле Identifier в принятом пакете ConfigureNak должно совпадать с переданным в последнем пакете ConfigureRequest. Недействительные пакеты отбрасываются без уведомления.

Получение действительного пакета ConfigureNak показывает, что при передаче нового пакета ConfigureRequest конфигурационные опции можно изменить в соответствии с ConfigureNak. При наличии множества экземпляров опции партнеру следует выбрать одно значение и включить его в следующий пакет ConfigureRequest.

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

Формат пакета ConfigureNak показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+

Code

3 (Configure-Nak).

Identifier

Поле Identifier содержит копию одноименного поля в пакете ConfigureRequest, вызвавшем передачу Configure-Nak.

Options

Поле Options переменного размера включает список (возможно пустой) конфигурационных опций, неприемлемых для отправителя. Все конфигурационные опции обрабатываются совместно.

5.4 ConfigureReject

Если некоторые опции из пакета ConfigureRequest не удается распознать или они не приемлемы при согласовании (административные настройки), реализация должна передать отклик ConfigureReject. В поле Options указываются только неприемлемые опциями из ConfigureRequest, а все понятные и пригодные опции исключаются из ConfigureReject, но при этом недопустимо менять порядок опций из Configure-Request.

Поле Identifier в принятом пакете ConfigureReject должно совпадать с переданным в последнем пакете ConfigureRequest. Кроме того, опции в пакете ConfigureReject должны быть подмножеством переданных в последнем пакете ConfigureRequest опций. Недействительные пакеты отбрасываются без уведомления.

Получение действительного пакета ConfigureReject указывает, что при передаче нового ConfigureRequest недопустимо включать какую-либо из опций, содержащихся в ConfigureReject.

Формат пакета ConfigureReject показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Options ...
+-+-+-+-+

Code

4 (Configure-Reject).

Identifier

Поле Identifier содержит копию одноименного поля в пакете ConfigureRequest, вызвавшем Configure-Reject.

Options

Поле Options переменного размера включает список (возможно пустой) конфигурационных опций, отвергнутых отправителем. Все конфигурационные опции отвергаются совместно.

5.5 TerminateRequest и TerminateAck

LCP включает коды TerminateRequest и TerminateAck в качестве механизма закрытия соединений.

Реализации, желающей закрыть соединение, следует передать пакет TerminateRequest. Передачу этих пакетов следует повторять, пока не будет получено подтверждение TerminateAck и нижележащий уровень не покажет отключение или пока не будет передано достаточно большое число пакетов, позволяющее с уверенностью считать, что партнер отключился.

При получении TerminateRequest должен возвращаться пакет TerminateAck.

Получение не запрошенного пакета TerminateAck показывает, что партнер находится в состоянии Closed или Stopped или повторное согласование требуется по иным причинам.

Формат пакетов TerminateRequest и TerminateAck показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

Code

5 (Terminate-Request) или 6 (Terminate-Ack).

Identifier

При передаче поле Identifier должно быть изменено при изменении содержимого поля Data или получении действительного отклика на предыдущий запрос. При повторе поле Identifier может сохраняться.

На приемной стороне поле Identifier копируется из пакета TerminateRequest в пакет TerminateAck.

Data

Поле Data (возможно пустое) содержит неинтерпретируемые данные для использования отправителем. Поле может включать произвольное двоичное значение. Окончание данных указывается значением поля Length.

5.6 CodeReject

Получение пакета LCP с неизвестным кодом указывает, что партнер использует другую версию протокола. Этот код должен быть возвращен отправителю в пакете CodeReject.

При получении CodeReject с кодом, который требуется в этой версии протокола, реализации следует сообщить о проблеме и разорвать соединение, поскольку автоматическое решение проблемы маловероятно.

Формат пакета CodeReject показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Rejected-Packet ...
+-+-+-+-+-+-+-+-+

Code

7 (CodeReject).

Identifier

Поле Identifier должно изменяться для каждого передаваемого пакета CodeReject.

Rejected-Packet

Поле Rejected-Packet содержит копию отвергнутого пакета LCP, начиная с поля Information без заголовков канального уровня и FCS. Размер пакета RejectedPacket должен отсекаться в соответствии с согласованным партнерами значением MRU.

5.7 ProtocolReject

Получение пакета PPP c неизвестным полем Protocol показывает, что партнер пытается использовать не поддерживаемый протокол. Это обычно происходит, когда партнер пытается настроить новый протокол. Если машина LCP находится в состоянии Opened, партнеру должен быть передан пакет ProtocolReject.

При получении пакета ProtocolReject реализация должна прекратить передачу пакетов указанного протокола при первой возможности.

Пакеты ProtocolReject могут передаваться лишь в том случае, когда LCP находится в состоянии Opened. Пакеты ProtocolReject, полученные в состоянии, отличном от Opened, следует отбрасывать без уведомления.

Формат пакета ProtocolReject показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       Rejected-Protocol       |      Rejected-Information ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code

8 (Protocol-Reject).

Identifier

Поле Identifier должно изменяться для каждого передаваемого пакета ProtocolReject.

RejectedProtocol

Двухоктетное поле RejectedProtocol содержит поле PPP Protocol из отвергнутого пакета.

RejectedInformation

Поле Rejected-Information содержит копию отвергнутого пакета, начиная с поля Information без заголовков канального уровня и FCS. Размер пакета RejectedProtocol должен отсекаться в соответствии с согласованным партнерами значением MRU.

5.8 Echo-Request и Echo-Reply

LCP включает коды EchoRequest и EchoReply для предоставления канальному уровню механизма loopback, позволяющего проверить соединение в обоих направлениях. Это может служить для отладки, определения качества линии, тестирования производительности и многих других функций.

При получении пакета EchoRequest в состоянии LCP Opened должен передаваться отклик EchoReply.

Пакеты EchoRequest и EchoReply должны передаваться из состояния LCP Opened. Пакеты EchoRequest и EchoReply, полученные в состоянии, отличном от Opened, следует отбрасывать без уведомления.

Формат пакетов EchoRequest и EchoReply показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Magic-Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

Code

9 (Echo-Request) или 10 (Echo-Reply).

Identifier

При передаче поле Identifier должно быть изменено при изменении содержимого поля Data или получении действительного отклика на предыдущий запрос. При повторе поле Identifier может сохраняться.

На приемной стороне поле Identifier копируется из пакета Echo-Request в пакет EchoReply.

MagicNumber

Четырехоктетное поле MagicNumber служит для детектирования наличия петли (loopback) на канале. Если не была согласована опция конфигурации MagicNumber, в поле MagicNumber должно помещаться значение 0. Дополнительная информация приведена в описании опции MagicNumber.

Data

Поле Data (возможно пустое) содержит неинтерпретируемые данные для использования отправителем. Поле может включать произвольное двоичное значение. Окончание данных указывается значением поля Length.

5.9 DiscardRequest

LCP включает код DiscardRequest, предоставляющий канальному уровню механизм проверки соединения в направлении от локального узла к удаленному. Механизм полезен для отладки, тестирования производительности и множества других функций.

Пакеты DiscardRequest должны передаваться только из состояния LCP Opened. Получатель пакета DiscardRequest должен отбрасывать его без уведомления.

Формат пакета DiscardRequest показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Code      |  Identifier   |            Length             |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|                         Magic-Number                          |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

Code

11 (DiscardRequest).

Identifier

Поле Identifier должно изменяться для каждого передаваемого пакета DiscardRequest.

MagicNumber

Четырехоктетное поле MagicNumber служит для детектирования наличия петли (loopback) на канале. Если не была согласована опция конфигурации MagicNumber, в поле MagicNumber должно помещаться значение 0. Дополнительная информация приведена в описании опции MagicNumber.

Data

Поле Data (возможно пустое) содержит неинтерпретируемые данные для использования отправителем. Поле может включать произвольное двоичное значение. Окончание данных указывается значением поля Length.

6. Конфигурационные опции LCP

Конфигурационные опции LCP позволяют согласовывать изменение принятых по умолчанию характеристик канала точка-точка. Если опция не включена в пакет ConfigureRequest, она будет иметь принятое по умолчанию значение.

Некоторые конфигурационные опции могут быть включены несколько раз. Результат этого зависит от опции и описан в определении опции (ни одна из включенных в эту спецификацию опций не может присутствовать многократно).

Конец списка конфигурационных опций определяется полем Length в пакете LCP.

Если не указано иное, все конфигурационные опции применяются в полудуплексном стиле — обычно это приемное направление с точки зрения отправителя ConfigureRequest.

Философия разработки.

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

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

За исключением явно указанных случаев, подтверждение опции не требует от партнера выполнения каких-либо дополнительных действий, кроме принятых по умолчанию.

Передача принятых по умолчанию значения в пакете ConfigureRequest не требуется.

Формат конфигурационных опций показан ниже. Поля передаются слева направо.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |    Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

Однооктетное поле Type указывает тип опции. Актуальные в настоящий момент опции LCP указаны в свежей версии RFC «Assigned Numbers» [2].

0 резерв;

1 Maximum-Receive-Unit;

3 Authentication-Protocol;

4 Quality-Protocol;

5 Magic-Number;

7 Protocol-Field-Compression;

8 Address-and-Control-Field-Compression.

Length

Однооктетное поле Length уоказывает размер опции с учетом полей Type, Length и Data.

Если в пакете ConfigureRequest получена согласуемая опция с некорректным или непонятным полем Length, следует передать пакет ConfigureNak, включающий желаемую опцию с подходящими полями Length и Data.

Data

Поле Data (возможно пустое) включает данные конкретной опции. Формат и размер поля Data определяется полями Type и Length.

Если размер поля Data, указанный в поле Length, выходит на пределы поля Information, пакет отбрасывается без уведомления и обработки.

6.1 MaximumReceiveUnit (MRU)

Эта конфигурационная опция может передаваться для информирования партнера о возможности приема более крупных пакетов или для запроса передачи более мелких пакетов.

По умолчанию используется значение 1500 октетов. Если запрошена передача более мелких пакетов, реализация должна сохранять возможность приема информационных полей размером 1500 октетов в случае потери синхронизации соединении.

Примечание для разработчиков. Эта опция служит для указания возможностей реализации. Партнер не обязан полностью использовать такую возможность. Например, при указании MRU в 2048 октетов, партнер не обязан передавать пакеты размером 2048 октетов. Партнер не обязан передавать пакет ConfigureNak для индикации того, что он будет передавать более мелкие пакеты, поскольку от реализации всегда требуется поддержка пакетов не менее 1500 октетов.

Формат опции MaximumReceiveUnit показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |      Maximum-Receive-Unit     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

1

Length

4

Maximum-Receive-Unit

Двухоктетное поле MaximumReceiveUnit указывает максимальное число октетов в полях Information и Padding. Размер не учитывает кадрирования, полей Protocol и FCS, а также биты и байты прозрачности.

6.2 AuthenticationProtocol

На некоторых соединениях может быть желательно потребовать от партнера подтверждения его подлинности до начала обмена пакетами сетевого уровня.

Эта опция обеспечивает способ согласования протокола аутентификации. По умолчанию аутентификация не нужна.

Реализациям недопустимо включать множество опций AuthenticationProtocol в пакеты ConfigureRequest. Вместо этого следует пытаться сначала настроить наиболее желанный протокол. Если этот протокол будет указан в ConfigureNak, следует попытаться согласовать другой приемлемый протокол в следующем пакете ConfigureRequest.

Реализация, передающая ConfigureRequest показывает, что она ожидает аутентификации партнера. Если реализация передает ConfigureAck, это означает ее согласие на аутентификацию по указанному протоколу. Реализации, получившей ConfigureAck, следует ожидать от партнера аутентификации по подтвержденному протоколу.

Не задается требований полнодуплексной аутентификации или использования одного протокола для обоих направления. Применение своего протокола для каждого направления является совершенно нормальным. Однако это зависит от согласованных протоколов.

Формат опции AuthenticationProtocol Configuration Option показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |     Authentication-Protocol   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

Type

3

Length

>= 4

Authentication-Protocol

Двухоктетное поле AuthenticationProtocol указывает желаемый протокол аутентификации. Для этого поля применяются те же значения, которые помещаются в поле PPP Protocol для того же протокола аутентификации.

Действующие значения поля AuthenticationProtocol указаны в RFC «Assigned Numbers» [2]. Выделенные в настоящее время значения приведены ниже.

Значение

Протокол

c023

Password Authentication Protocol (PAP)

c223

Challenge Handshake Authentication Protocol (CHAP)

Data

Поле Data (возможно пустое) содержит дополнительные данные, зависящие от протокола аутентификации.

6.3 QualityProtocol

На некоторых соединениях желательно определить, когда и как часто канал отбрасывает данные. Этот процесс называется мониторингом качества канала.

Это опция позволяет согласовать использование конкретного протокола для мониторинга качества канала. По умолчанию мониторинг не применяется.

Реализация, передающая ConfigureRequest, показывает, что она ожидает получения данных мониторинга от своего партнера. Передача пакета ConfigureAck означает согласие реализации на применение этого протокола. Реализации, получившей ConfigureAck, следует ожидать от партнера пакетов подтвержденного протокола.

Не задается требований полнодуплексного мониторинга или использования одного протокола в обоих направлениях. Применение своего протокола для каждого направления является совершенно нормальным. Однако это зависит от согласованных протоколов.

Формат опции QualityProtocol показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |        Quality-Protocol       |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    Data ...
+-+-+-+-+

Type

4

Length

>= 4

Quality-Protocol

Двухоктетное поле QualityProtocol указывает желательный протокол мониторинга качества канала. Для этого поля применяются те же значения, которые помещаются в поле PPP Protocol для того же протокола мониторинга.

Действующие значения поля QualityProtocol указаны в RFC «Assigned Numbers» [2]. Выделенные в настоящее время значения приведены ниже.

Значение

Протокол

c025

Link Quality Report

Data

Поле Data (возможно пустое) содержит дополнительные данные, зависящие от протокола.

6.4 MagicNumber

Эта опция предоставляет метод детектирования шлейфовых петель (loopback) и других аномалий канального уровня. Опция может быть нужна для других опций конфигурации, например, QualityProtocol. По умолчанию значение MagicNumber не согласовывается и вместо него используется 0.

До того, как эта опция будет запрошена, реализация должна выбрать значение MagicNumber. Рекомендуется задавать MagicNumber случайным образом для получения высокой вероятности выбора уникального значения. Хорошим способом получить уникальное случайное число является использование «затравки» (seed). Источниками уникальности могут быть серийные номера машин, аппаратные сетевые адреса, показания часов и т.п. Очень хорошей затравкой для случайных чисел служит точное измерение интервалов между физическими событиями, такими как получение пакетов в других присоединенных сетях, время отклика сервера или скорость нажатия клавиш человеком. Разумно использовать одновременно множество таких источников.

При получении ConfigureRequest с опцией MagicNumber, принятое значение MagicNumber сравнивается с MagicNumber в последнем пакете ConfigureRequest, переданном партнеру. Если значения MagicNumber различаются, это говорит об отсутствии петли на канале и MagicNumber следует подтвердить. Если два MagicNumber совпадают, это может говорить о наличии (не обязательно) петли на соединении, в результате чего полученный пакет ConfigureRequest является последним из отправленных. Для проверки этого должен быть передан пакет ConfigureNak с другим значением MagicNumber. Новые пакеты ConfigureRequest не следует передавать партнеру, пока этого не потребует обычный порядок обработки (т.е. до получения ConfigureNak или тайм-аута Restart).

Получение ConfigureNak с MagicNumber, отличным от переданного в последнем ConfigureNak, подтверждает отсутствие петли на канале и показывает уникальное значение MagicNumber. Если MagicNumber совпадает с переданным в последнем пакете ConfigureNak, вероятность наличия петли на канале увеличивается и должно быть выбрано новое значение MagicNumber. В любом случае новый пакет ConfigureRequest следует передавать с новым MagicNumber.

Если соединение действительно имеет петлю, последовательность (передача ConfigureRequest, прием ConfigureRequest, передача ConfigureNak, прием ConfigureNak) будет повторяться раз за разом. Если петли нет, последовательность может повториться несколько раз, но ее продолжительное повторение маловероятно. Скорее всего, значения MagicNumber, выбранные разными сторонами, быстро разойдутся и последовательность прервется. В таблице показаны вероятности совпадения MagicNumber на разных сторонах канала при однородном распределении.

Числоконфликтов

Вероятность

1

1/232=2,3 E-10

2

1/(232)2=5,4 E-20

3

1/(232)3=1,3 E-29

Для такой дивергенции нужен хороший источник уникальности или случайности. Если такого источника нет, рекомендуется не применять эту опцию — пакеты ConfigureRequest пакеты с этой опцией не следует передавать, а все опции MagicNumber от партнера следует применять после подтверждения или отбрасывать. В этом случае петли на канале не удастся надежно детектировать, хотя для партнера эта возможность сохранится.

Если реализация передает ConfigureRequest с опцией MagicNumber, ей недопустимо отвечать пакетом ConfigureReject на получение ConfigureRequest с опцией MagicNumber. Если реализация желает использовать MagicNumber, то она должна разрешать это своему партнеру. Если реализация получила ConfigureReject в ответ на ConfigureRequest, это может означать лишь отсутствие петли на канале и отказ партнера от использования MagicNumber. В этом случае реализации следует вести себя как при успешном согласовании опций (получение ConfigureAck).

MagicNumber может также применяться для детектирования петель при нормальной работе и в процессе согласования конфигурационных опций. Все пакеты LCP Echo-Request, Echo-Reply и Discard-Request имеют поле Magic-Number. Если значение Magic-Number согласовано, реализация должна передавать такие пакеты с согласованным значением в поле Magic-Number.

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

Получение MagicNumber, совпадающего с согласованным локальным значением MagicNumber говорит о наличии петли на канале. Получение MagicNumber, отличного от согласованного локального значения, согласованного значения MagicNumber партнера или нуля при отсутствии согласования говорит о том, что соединение было настроено для взаимодействия с другим партнером.

Процедуры для восстановления для любого из этих случаев не описываются и могут отличаться в разных реализациях. Пессимистическим вариантом является допущение события LCP Down. Следующее событие Open начнет процесс повторной организации соединения, которой не может быть завершен без устранения петли и согласования MagicNumber. Более оптимистической процедурой (при наличии петли) является начало передачи пакетов LCP EchoRequest, продолжающейся по получения приемлемого отклика EchoReply, указывающего на устранение петли.

Формат опции MagicNumber показан ниже. Поля передаются слева направо.

 0                   1                   2                   3
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |          Magic-Number
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      Magic-Number (продолж.)   |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

5

Length

6

Magic-Number

Четырехоктетное поле MagicNumber содержит значение, которое с большой вероятностью различается у партнеров соединения. Нулевое значение MagicNumber неприемлемо и в ответ должен передаваться пакет Nak, если не требуется отвергнуть пакет совсем.

6.5 ProtocolFieldCompression (PFC)

Эта опция позволяет согласовать метод сжатия поля PPP Protocol. По умолчанию, все реализации должны передавать пакеты с двухоктетными полями Protocol.

Номера протоколов PPP выбраны так, чтобы некоторые значения можно было сжать до 1 октета, что будет явно отличать их от двухоктетных полей. Эта опция служит для информирования партнера о возможности принимать поля Protocol размером 1 октет.

Как отмечено выше, поле Protocol использует механизм расширения, согласующийся с ISO 3309 для поля Address. Младший бит (LSB11) каждого октета служит для индикации расширения поля Protocol. Значение 0 в LSB показывает, что поле Protocol продолжается в следующем октете, а 1 — указывает последний октет поля Protocol. Отметим, что полю может предшествовать любой число октетов по значением 0 и номер протокола при этом не изменится (например, для протокола 3 могут использоваться представления 00000011 и 00000000 00000011).

На низкоскоростных каналах желательно сохранять полосу пропускания, передавая меньше избыточных данных. Опция ProtocolFieldCompression обеспечивает компромисс между простотой реализации и эффективностью использования полосы пропускания. Если эта опция согласованна, может применяться механизм расширения ISO 3309 для сжатия поля Protocol в один октет вместо двух. Для большинства пакетов такое сжатие возможно, поскольку значения поля Protocol меньше 256.

Сжатые поля Protocol недопустимо передавать, пока не согласована эта опция. При согласованной опции реализации PPP должны воспринимать PPP пакеты как с двумя, так и с одним октетом в поле Protocol, а различать такие пакеты недопустимо.

Поле Protocol никогда не сжимается при передаче пакетов LCP, это гарантирует их однозначное распознавание.

При сжатых полях Protocol значение FCS канального уровня рассчитывается для сжатого, а не исходного кадра.

Формат опции ProtocolFieldCompression показан ниже. Поля передаются слева направо.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

7

Length

2

6.6 Address-and-Control-Field-Compression (ACFC)

Эта опция позволяет согласовать метод сжатия полей канального уровня Address и Control. По умолчанию все реализации должны передавать кадры с полями Address и Control, соответствующими методу кадрирования.

Поскольку для соединений точка точка значения этих полей обычно постоянны, поля легко сжать. Эта опция передается для информирования партнера о возможности воспринимать сжатые поля Address и Control.

Если сжатый кадр был получен без согласованной опции AddressandControlFieldCompression, реализация может отбросить кадр без уведомления.

Поля Address и Control недопустимо сжимать для пакетов LCP пакет. Это правило гарантирует однозначное распознавание пакетов LCP.

При сжатых полях Address и Control значение FCS на канальном уровне рассчитывается для сжатого кадра.

Формат опции AddressandControlFieldCompression показан ниже. Поля передаются слева направо.

 0                   1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|     Type      |    Length     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type

8

Length

2

Вопросы безопасности

Вопросы безопасности кратко рассмотрены в разделах, описывающих фазу Authentication, событик Close и опцию AuthenticationProtocol.

Литература

[1] Perkins, D., «Requirements for an Internet Standard Point-to-Point Protocol», RFC 1547, Carnegie Mellon University, December 1993.

[2] Reynolds, J., and Postel, J., «Assigned Numbers», STD 212, RFC 1340, USC/Information Sciences Institute, July 1992

Благодарности

Этот документ подготовлен рабочей группой Point-to-Point Protocol под эгидой IETF. Комментарии следует направлять в списк рассылки ietf-ppp@merit.edu.

Значительная часть текста документа заимствована из требований рабочей группы [1], а также RFC 1171 и RFC 1172 от Drew Perkins из университета Carnegie Mellon и Russ Hobby из Калифорнийского университета в Дэвисе.

William Simpson отвечал за согласованность терминологии и философии, а также за устройство машин состояния фаз и согласования.

Множество людей потратили много времени разработку протокола РРР. Полный список людей слишком велик для перечисления здесь, но некоторых следует отметить. Это Rick Adams, Ken Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross, Kory Hamzeh, David Kaufman, Mark Lewis, John LoVerso, Bill Melohn, Mike Patton, Greg Satz, John Shriver, Vernon Schryver и Asher Waldfogel.

Отдельная благодарность Morning Star Technologies за предоставление компьютерных ресурсов и сетевого доступа при написании этой спецификации.

Адрес руководителя

С рабочей группой можно связаться через ее руководителя

Fred Baker
Advanced Computer Communications
315 Bollay Drive
Santa Barbara, California 93117
fbaker@acc.com

Адрес редактора

Вопросы по этому документу могут быть направлены по приведенному ниже адресу

William Allen Simpson
Daydreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
Bill.Simpson@um.cc.umich.edu bsimpson@MorningStar.com

Перевод на русский язык

Николай Малых

nmalykh@protocols.ru


1PointtoPoint Protocol – протокол соединений «точка-точка».

2Link Control Protocol.

3Network Control Protocol.

4Password Authentication Protocol – протокол аутентификации по паролю.

5Challenge Handshake Authentication Protocol – протокол аутентификации «запрос-отклик».

6Internet Assigned Numbers Authority.

7Maximum Receive Unit.

8Перезапуск опции. См. обсуждение состояния Open.

9Пассивная опция. См. обсуждение состояния Stopped.

10Пересекающееся соединение. См. обсуждение события RCA.

11Least Significant Bit.

12В соответствии с RFC 3232 документ «Assigned Numbers» утратил силу и заменен публикуемыми на сайте документами. Прим. перев.

 

Please follow and like us:
error
Запись опубликована в рубрике RFC. Добавьте в закладки постоянную ссылку.

Добавить комментарий