Авторские права.
Авторское право принадлежит " Обществу Интернет " (The Internet Society) (1999). Все права оговорены.

Краткий обзор.
Протокол двухточечной передачи данных (Point-to-Point Protocol (PPP)) представляет собой стандартный метод передачи многопротокольных (мультипротокольных) дейтаграмм1 через двухточечные линии передачи.
Этот документ описывает, как обеспечить РРР сессию и инкапсулировать пакеты РРР через Ethernet.

Применение.
Эта детализация предназначена для того, чтобы обеспечить такую возможность управления РРР, которая определена Протоколом Управления Связью (Link Control Protocol), Протоколом Контроля Загруженности Сети (Network-layer Control Protocol), аутентификацией и т. д. РРР предусматривает обмен данными только между двумя точками и не предназначен для многоточечной передачи данных, которая возможна в Ethernet и в других многодоступных средах.
Это руководство может быть использовано совместными Хостами со сложной структурой, Ethernet-ом для открытия РРР-сессий многоадресного доступа к информации посредством одного или нескольких объединенных модемов. Оно предназначено для использования в технологиях широкополосного доступа, которые представляют объединенную топологию Ethernet, когда провайдеры, предоставляющие такой доступ желают ассоциировать РРР-сессию с каждым клиентом.
Этот документ описывает технологию инкапсуляции РРР через Ethernet, которая внедрена такими компаниями как RedBack Networks, RouterWare, UUNET и другими.

1. Введение
Перед современными технологиями доступа стали несколько несовместимых целей. Желательно соединять Хосты со сложной структурой на отдаленных участках с помощью одного и того же клиентского устройства доступа. Предоставлять контроль над доступом и биллинговую функциональность в стиле "dial-up" с использованием РРР. Во многих технологиях доступа самый дешевый способ соединять Хосты с помощью одного и того же клиентского устройства - это способ с использованием Ethernet. Вдобавок, желательно сохранять низкую стоимость этого устройства до тех пор, пока спрос мал или оно не сконфигурировано.
РРРоЕ предоставляет возможность соединять сетевые Хосты с помощью нескольких объединенных устройств доступа в единый удаленный Узел доступа. C такой моделью, каждый Хост использует свой собственный РРР-стек, а пользователь работает со знакомым интерфейсом. Управление доступом, типом услуги и биллинг может осуществляться по каждому пользователю, а не по сайту.
Чтобы обеспечить двухточечное соединение через Ethernet, каждая РРР-сессия должна узнавать Ethernet-адрес удаленного пиринга, как только установлен уникальный идентификатор сессии. РРРоЕ включает Discovery-протокол, который это обеспечивает.

2. Обзор документа
РРРоЕ имеет два различных уровня. Это Discovery-уровень и уровень РРР-сессии. Когда Хост открывает новую РРР-сессию, сначала проходит идентификация MAC2 - адреса Ethernet на Discovery-уровне и идентифицируется РРР-сессия. Пока РРР определяет отношения между двумя точками, Discovery-уровень находится в неопределенных отношениях "клиент-сервер"3. Далее на Discovery-уровне Хост получает доступ на Сервер. В топологии сети может быть более одного Узла доступа, с которым Хост может общаться. Discovery-уровень предоставляет возможность Хосту связаться со всеми Узлами доступа и выбрать один. Когда процесс на Discovery-уровне успешно завершен и Хост и выбранный Узел доступа уже имеют информацию, которую они будут использовать при установлении двухточечного соединения через Ethernet.
Discovery-уровень остается в неопределенном состоянии, пока не установлена РРР-сессия. Как только РРР-сессия установлена и Хост, и Узел доступа распределяют ресурсы для создания виртуального интерфейса РРР.

3. Полезные сведения
Полезные сведения будут описаны применительно к Discovery-уровню и уровню РРР-сессии.

Фрейм Ethernet выглядит следующим образом
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
Адрес пункта назначения
(48 бит)
Адрес документа
(48 бит)
Тип Ethernet
(16 бит)
Полезные сведения
Контрольная сумма4

Поле "Адрес пункта назначения" содержит также адрес однонаправленной передачи Ethernet, или широковещательный адрес Ethernet (0хffffffff). Для пакетов Discovery-уровня объем является или unicast или широковещательным адресом как определено в Discovery-разделе. Для трафика РРР-сессии это поле должно содержать пиринговый unicast-адрес, который определяется из Discovery-уровня.

Поле "Адрес документа" должно содержать МАС-адрес Ethernet исходного устройства.

Значение поля "Тип Ethernet" устанавливается или 0х8863 (Discovery-уровень), или 0х8864 (уровень РРР-сессии).

Полезные сведения Ethernet для РРРоЕ выглядит следующим образом:
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
Версия Тип Код Идентификатор сессии
Длина Полезные сведения

Поле "Версия" четырехбитное и его значение должно быть 0х1 для этой версии РРРоЕ-детализации.

Поле "Тип" также четырехбитное и его значение должно быть 0х1 для этой версии РРРоЕ-детализации.

Поле "Код" восьмибитное и описывается ниже применительно к уровню Discovery и уровню РРР-сессии.

Поле "Идентификатор сессии" шестнадцатибитное. Оно имеет неопределенное значение в сетевом байтовом порядке. Это значение описывается ниже для пакетов уровня Discovery. Это значение зафиксировано для открытия РРР-сессии и, фактически определяет РРР-сессию вместе с адресом пункта назначения и адресом документа Ethernet. Значение 0хffffff зарезервировано для использования в будущем и не используется.

Поле "Длина" шестнадцатибитное. Значение в сетевом байтовом порядке показывает продолжительность полезной сведений РРРоЕ.

4. Уровень Discovery
Уровень Discovery проходит в четыре этапа. Когда эти этапы завершены, обе точки знают идентификатор РРР-сессии и адрес пиринга Ethernet, который однозначно описывается вместе с РРРоЕ -сессией. Этапы содержат Хост, транслирующий пакет Инициации, один или более Узлов Доступа, посылающих пакет-Предложение, Хост, посылающий unicast-пакет-Запрос Сессии и выбранный Узел Доступа, посылающий пакет-Подтверждение. Когда Хост получает пакет-Подтверждение, он может переходить на уровень РРР-сессии. Когда Узел Доступа посылает пакет-Подтверждение, он также может переходить на уровень РРР-сессии.
Все фреймы Ethernet Discovery-уровня имеют значение поля "Тип Ethernet" 0х8863. Полезные сведения РРРоЕ содержат в себе 0 или более ТЭГов. Любой ТЭГ является ТЭГом TLV (тип-длина-значение) и выглядит следующим образом:
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
Тип (TAG_TYPE) Длина (TAG_LENGTH)
Значение (TAG_VALUE)

"Тип" - это шестнадцатибитное поле в сетевом байтовом порядке. Приложение А содержит список всех типов ТЭГов и их значений.

"Длина" - это также шестнадцатибитное поле. Оно не прописано в сетевом байтовом порядке, указывает длину значения ТЭГа в байтах

Если Discovery-пакет получен c ТЭГом неизвестного типа, то это ТЭГ игнорируется, если только не будет задан иным способом в данном документе. Это обеспечивает обратную совместимость, если/когда новый ТЭГ добавлен. Если обязательные ТЭГи добавлены, то номер версии будет расти.

Некоторые примеры Discovery-пакетов представлены в Приложении Б.

4.1 PADI5 - пакет
Хост посылает PADI-пакет с адресом места назначения, установленного для адреса вещания. Поле "Код" имеет значение 0х09, а Идентификатор Сессии устанавливается 0х0000.

PADI-пакет должен содержать ровно один ТЭГ типа "Service Name", указывающий услугу, которую запрашивает Хост и любой номер других типов ТЭГов. Входной PADI-пакет (включающий заголовок РРРоЕ) не должен превышать 1484 байта, чтобы сохранить достаточно места для смены агента, чтобы добавить RSI6 ТЭГ.

4.2 PADO7 - пакет
Когда Узел Доступа получает PADI-пакет, которым он может оперировать, в ответ он посылает PADO-пакет. Адрес Места Назначения - это Unicast-адрес Хоста, который посылает PADI-пакет. Значение поля "Код" устанавливается 0х07, а Идентификатор Сессии остается - 0х0000.

PADO-пакет должен содержать один AC-name ТЭГ, содержащий в себе название Узла Доступа, Service Name ТЭГ тот же, что и для PADI-пакетов, и несколько других Service Name ТЭГов, содержащие другие услуги, которые предлагает Узел Доступа. Если Узел Доступа не может оперировать PADI, то он не посылает ответ с PADO.

4.3 PADR8 - пакет
Как только PADI был передан, Хост может получить более одного PADO. Хост просматривает все PADO-пакеты, которые получает и выбирает один. Выбор может основываться на AC-name или на названии предложенных услуг. Затем Хост посылает один PADR-пакет Узлу Доступа, который был выбран. Поле "Адрес места назначения" устанавливается для unicast-адреса Ethernet Узла Доступа, который посылает PADO. Значение кодового поля устанавливается 0х19, а "Идентификатор сессии" - 0х0000.

PADR-пакет должен содержать только один ТЭГ типа "Service Name", указывая услугу, Хост запрашивает и любое число других типов ТЭГов.

4.4 PADS9 - пакет
Когда Узел Доступа получает PADR-пакет, он готовится открыть РРР-сессию. Он генерирует уникальный Идентификатор для РРРоЕ-сессии и отвечает Хосту, посылая PADS-пакет. Поле "Адрес места назначения" - это unicast-адрес Ethernet Хоста, посылающего PADR-пакет. Значение поля "Код" устанавливается 0х65, а значение "Идентификатора сессии" должно устанавливаться в уникальной форме, сгенерированной для этой РРРоЕ-сессии.

PADS-пакет содержит только один ТЭГ типа "Service Name", указывая услугу, под которой Узел Доступа принимает РРРоЕ-сессию и любое число других типов ТЭГов.

Если Узлу Доступа не подходит "Service Name" PADR-пакета, то он в ответ посылает PADS-пакет, содержащий ТЭГ типа "Ошибка Service Name" (и любое число других типов ТЭГов). В этом случае значение Идентификатора сессии устанавливается 0х0000.

4.5 PADT10 - пакет
Этот пакет может быть послан в любое время после основания сессии для указания того, что РРРоЕ-сессия была закончена. Он может быть послан или Хостом, или Узлом Доступа. "Адрес места назначения" - unicast-адрес Ethernet, значение кодового поля устанавливается 0ха7, а значение "Идентификатора сессии" устанавливается для того, чтобы указать, какая именно сессия была закончена, при этом ТЭГи не требуются.

Когда PADT-пакет получен, никакого дальнейшего РРР-трафика, который бы отсылался, используя эту РРР-сессию, не допускается. Даже обычные РРР-пакеты окончания сессии не должны отсылаться, когда послан или получен PADT-пакет. PPP peer должен использовать сам протокол PPP, чтобы снизить PPPoE-сессию, но PADT-пакет может использоваться, когда PPP не может быть использован.

6. Уровень РРР-сессии
Если PPPoE-сессия начинается, данные PPP посылаются как при любой другой инкапсуляции PPP. Все Ethernet-пакеты являются unicast-пакетами. Значение "Тип Ethernet" устанавливается 0х8864. Код РРРоЕ устанавливается 0х00. "Идентификатор сессии" не меняется для этой РРРоЕ-сессии, а назначается на Discovery-уровне. Полезные сведения РРРоЕ содержат РРР-фрейм, который начинается с идентификатора протокола РРР.

Пакет-пример показан в Приложении Б.

7. Анализ LCP
Рекомендуется выбор системного кода11 LCP-конфигурации, но не рекомендуется выбор (PFC)12. При выполнении запрос о любом из следующих выборов отвергается, а именно:

выбор FCS13 , ACFC14 , ACCM15 .

При выборе, MRU16 не должен иметь больший размер, чем 1492 байта. Поскольку Ethernet имел максимальный размер полезной информации 1500 байт, PPPoE-заголовок - 6 байт, а идентификатор протокола PPP - 2 байта, PPP MRU не должен превышать 1492 байта.

Желательно, чтобы Узел Доступа время от времени послал Echo-Request-пакеты Хосту, чтобы определить состояние сессии. Иначе Хост закрывает сессию без отсылки Terminate-Request-пакета и Узел Доступа не сможет определить, что сессия закрыта.

Когда LCP закрывается, Хост и Узел Доступа должны прекратить использование данной РРР-сессии. Если Хост желает открыть другую РРР-сессию, то он должен вернуться на Discovery-уровень.

8. Прочая информация
Когда Хост не получает PADO-пакет в пределах заданного времени, он пересылает PADI-пакет и удваивает период ожидания. Это повторяется столько, сколько требуется. Если Хост ожидает получения PADS-пакета, используется аналогичный механизм тайм-аута, а Хост постоянно посылает PADR-пакеты. После определенного числа повторных попыток, Хост должен заново передать PADI-пакет.

Поля "Тип Ethernet", использованные в этом документе (0x8863 and 0x8864), назначены IEEE для использования РРР с Ethernet (PPPoE). Использование этих значений и поля "Версия" РРРоЕ однозначно оговорены в данном протоколе.

UTF-8 [5] используется в этом документе вместо ASCII. UTF-8 поддерживает целый набор ASCII символов, а также наборы международных символов. См. [5] для более подробной информации.

9. Безопасность
Чтобы защититься от атаки DOS17, Узел Доступа может применить AC-Cookie ТЭГ. Узел Доступа должен однозначно регенерировать ТЭГ-Значение, который базируется на адресе PADR-пакета. Используя это, Узел Доступа может гарантировать, что адрес PADI-пакета доступен и затем может ограничить параллельные сессии для этого адреса. Какой алгоритм использовать не оговаривается, а оставляется как часть процесса выполнения. Как пример можно рассматривать HMAC [3] через МАС-адрес Хоста, использующий ключ, известный только Узлу Доступа.

Пока AC-Cookie полезен при защите только от некоторых DOS-атак, он не может защитить от всех DOS-атак и Узел Доступа может применить другие средства, чтобы защитить ресурсы.

Многие Узлы Доступа не захотят предоставить информацию относительно тех услуг, которые они предлагают. В таком случае Узел Доступа должен применить одну из двух политик. Он никогда не должен отклонять запросы, основанные на Service-Name-ТЭГе и должен всегда возвращать ТЭГ-Значение, который ему был послан. Или он должен принимать запросы, основанные на Service-Name-ТЭГе c нулевым ТЭГом-длиной (указание любой услуги). Но первое решение предпочтительнее.

10. Уведомления
Этот документ базируется на концепциях, обсуждавшихся на различных форумах, включая ADSL18 -форум. Огромное количество информации было взято из RFC 1661, RFC 1662 и RFC 2364.

11. Ссылки
1. Simpson W., Редактор, " The Point-to-Point Protocol (PPP)", STD 51, RFC 1661, Июль 1994

2. Bradner, S., "Ключевые термины используемые в RFC для указания уровней запроса", BCP 14, RFC 2119, Март 1997.

3. Krawczyk, H., Bellare, M. и R. Canetti, "HMAC: Хэширование по ключу для аутентификации сообщения", RFC 2104, Февраль 1998.

4. Reynolds, J. И J. Postel, "Стандартная нумерация19 ", STD 2, RFC 1700, Октябрь 1994. Смотри также: http://www.iana.org/numbers.html

5. Yergeau, F., "UTF-8, Формат преобразования ISO 10646", RFC 2279, Январь 1998.

Приложение A
ТЭГ-Тип и ТЭГ-Значение TAG_TYPES and TAG_VALUES

0x0000 - Конец списка (End-Of-List)

Этот ТЭГ указывает, что больше в списке ТЭГов нет. ТЭГ-Длина (TAG_LENGTH) в этом ТЭГе всегда равен нулю. Использование этого ТЭГа не требуется, но оставляется для обратной совместимости.
0x0101 Название услуги (Service-Name)
Этот ТЭГ указывает имя услуги. ТЭГ-Значение (TAG_VALUE) в строке UTF-8 указывает, что строка не заканчивается на ноль. Когда ТЭГ-Длина (TAG_LENGTH) равен нулю, то он используется, чтобы указать, что любая услуга приемлема. Например, Service-Name-TAG указывает в ISP имя или класс, или качество услуги.
0x0102 AC-Name
Этот ТЭГ указывает, что следующая строка однозначно идентифицирует Узел Доступа от всех других. Это может быть комбинацией торговой марки, модели, серийной информации идентификатора или просто преобразованием MAC-адреса в строке UTF-8. Эта строка не должна заканчиваться нулем.
0x0103 Уникальность Хоста (Host-Uniq)
Эта ТЭГ используется Хостом, чтобы однозначно ассоциировать ответ Узла Доступа (PADO или PADS) и индивидуальный запрос Хоста (PADI или PADR). ТЭГ-Значение (TAG_VALUE) представляет собой двоичные данные любой величины и длины, которую выбирает Хост. Это не интерпретируется Узлом Доступа. Хост может включить Host-Uniq TAG в PADI или PADR. Если Узел Доступа получает этот ТЭГ, он должен включить исходный ТЭГ в ассоциированный ответ PADO или PADS-пакетов.
0x0104 AC-Cookie
Этот ТЭГ используется Узлом Доступа, чтобы помочь в защите против DOS (см. раздел "Безопасность"). Узел Доступа может включить этот ТЭГ в PADO-пакет. Если Хост получает этот ТЭГ, он должен вернуть исходный ТЭГ в следующий PADR-пакет. ТЭГ-Значение (TAG_VALUE) - это двоичные данные любой значения и длины, не интерпретируемые Хостом.
0x0105 Vendor-Specific
Этот ТЭГ используется, чтобы передать конфиденциальную информацию поставщика услуг. Первые четыре байта ТЭГа-Значения (TAG_VALUE) содержат идентификатор поставщика, а все остальное не расматривается. Старший байт идентификатора поставщика, равный 0 и младший - 3 байта управляют Сетевым Код-Поставщиком SMI Частных Предприятий в сетевом байтовом порядке, как определено в Стандартных Числах RFC [4].

Использование этого ТЭГа не рекомендуется. Чтобы гарантировать внутреннюю работоспособность, при исполнении Vendor-Specific-TAG может проигнорироваться.
0x0110 Смена идентификатора сессии (Relay-Session-Id)
Этот ТЭГ может быть добавлен к любому Discovery-пакету промежуточным агентом, который передает трафик. ТЭГ-Значение (TAG_VALUE) в этом случае непонятен как Хосту, так и Узлу Доступа. Если или Хост, или Узел Доступа получает этот ТЭГ, то они включают исходный ТЭГ в любой Discovery-пакет, который они посылают как ответ. Все PADI-пакеты должны гарантировать достаточное место для добавления ТЭГа смены идентификатора сессии (Relay-Session-Id) с ТЭГом-Длиной (TAG_VALUE), равным 12 байт.

ТЭГ смены идентификатора сессии (Relay-Session-Id) не включается в Discovery-пакет, если он уже содержит его. В этом случае промежуточный агент должен использовать существующий ТЭГ смены идентификатора сессии (Relay-Session-Id). Если он не может использовать существующий ТЭГ, или недостаточно места, чтобы добавить Relay-Session-Id-ТЭГ, тогда промежуточный агент возвращает ТЭГ Общей Ошибки (Generic-Error TAG) отправителю.
0x0201 Ошибка названия услуги (Service-Name-Error)
Этот ТЭГ (обычно с разделом нулевых данных) указывает, что по той или иной причине, запрос данного Названия Услуги не может быть выполнен. Если есть данные, и первый байт данных ненулевой, тогда они выводятся в строке UTF-8, в которой объясняется, почему запрос был отвергнут. Эта строка не должна заканчиваться нулем.
0x0202 AC-System-Error
Этот ТЭГ указывает, что на Узле Доступа имеется какая-то ошибка в выполнении запроса Хоста. (например, недостаточно ресурсов, чтобы создать виртуальный канал.) Этот ТЭГ может быть включен в PADS-пакеты.

Если есть данные, и первый байт данных ненулевой, тогда они выводятся в строке UTF-8, в которой объясняется природа ошибки. Эта строка не должна заканчиваться нулем.
0x0203 Общая ошибка (Generic-Error)
Этот ТЭГ указывает ошибку. Он может быть добавлен к PADO, PADR или PADS-пакетам, когда происходит неисправимая ошибка и нет соответствующих ТЭГов, сообщающих о ней. Если есть данные, и первый байт данных ненулевой, тогда они выводятся в строке UTF-8, в которой объясняется природа ошибки. Эта строка не должна заканчиваться нулем.

Приложение Б
Следующие схемы являются примером некоторых пакетов.

PADI-пакет:
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
0xFFFFFFFF
0xFFFF Host_mac_addr
Host_mac_addr (cont)
ETHER_TYPE = 0x8863 v = 1 t = 1 CODE = 0x09
SESSION_ID = 0x0000 LENGTH = 0x0004
TAG_TYPE = 0x0101 TAG_LENGTH = 0x0000

PADO-пакет:
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
Host_mac_addr
Host_mac_addr (cont) Access_Concentrator_mac_addr
Access_Concentrator_mac_addr (cont)
ETHER_TYPE = 0x8863 v = 1 t = 1 CODE = 0x07
SESSION_ID = 0x0000 LENGTH = 0x0020
TAG_TYPE = 0x0101 TAG_LENGTH = 0x0000
TAG_TYPE = 0x0102 TAG_LENGTH = 0x0018
0x47 0x6f 0x20 0x52
0x65 0x64 0x42 0x61
0x63 0x6b 0x20 0x2d
0x20 0x65 0x73 0x68
0x73 0x68 0x65 0x73
0x68 0x6f 0x6f 0x74

PPP LCP-пакет: значение протокола PPP установлено (0xc021), но полезная нагрузка PPP оставлены получателю. Это пакет, который Хост посылает Узлу Доступа:
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
Access_Concentrator_mac_addr
Access_Concentrator_mac_addr(c) Host_mac_addr
Host_mac_addr (cont)
ETHER_TYPE = 0x8864 v = 1 t = 1 CODE = 0x00
SESSION_ID = 0x1234 LENGTH = 0x????
PPP PROTOCOL = 0xc021 PPP payload

Адреса авторов:
Louis Mamakos
UUNET Technologies, Inc.
3060 Williams Drive Fairfax, VA 22031-4648 США
EMail: louie@uu.net

Kurt Lidl
UUNET Technologies, Inc.
3060 Williams Drive Fairfax, VA 22031-4648 США
EMail: lidl@uu.net

Jeff Evarts
UUNET Technologies, Inc.
3060 Williams Drive Fairfax, VA 22031-4648 США
EMail: jde@uu.net

David Carrel
RedBack Networks, Inc.
1389 Moffett Park Drive Sunnyvale, CA 94089-1134 США
EMail: carrel@RedBack.net

Dan Simone
RedBack Networks, Inc.
1389 Moffett Park Drive Sunnyvale, CA 94089-1134 США
EMail:dan@RedBack.net

Ross Wheeler
RouterWare, Inc.
3961 MacArthur Blvd., Suite 212 Newport Beach, CA 92660 США
EMail: ross@routerware.com

Источник: http://www.nag.ru/goodies/articles/pppoe.html