Network Working Group L. Mamakos
Request for Comments: 2516 K. Lidl
Category: Informational J. Evarts
UUNET Technologies, Inc.
D. Carrel
D. Simone
RedBack Networks, Inc.
R. Wheeler
RouterWare, Inc.
February 1999
Метод передачи PPP через Ethernet (PPPoE)
A Method for Transmitting PPP Over Ethernet (PPPoE)
Статус документа
В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться без ограничений.
Авторские права
Copyright (C) The Internet Society (1999). All Rights Reserved.
Аннотация
Протокол PPP1 [1] обеспечивает стандартный метод передачи дейтаграмм различных протоколов через соединения «точка-точка». В этом документе описано как создавать сессии PPP и инкапсулировать пакеты PPP в сетях Ethernet.
Применимость
Назначением этой спецификации является задание таких, определенных для PPP функций, как протокол управления каналом LCP2, протоколы управления на сетевом уровне NLCP3, аутентификация и т. п. Поддержка этих функций требуют создания парных отношений между партнерами и не предназначена для групповых взаимодействий, которые возможны в сетях Ethernet и других средах с множественным доступом.
Данная спецификация может использоваться множеством хостов разделяемой среды Ethernet для создания сессий PPP с многочисленными адресатами через один или множество модемов со встроенными мостами. Спецификация предназначена для использования с широкополосными технологиями удаленного доступа, создающими топологию Ethernet с соединениями на основе мостов4, когда поставщики услуг доступа хотят поддерживать абстракции сессий, связанные с PPP.
Документ описывает инкапсуляцию PPPoE5, которая развернута в сетях RedBack Networks, RouterWare, UUNET и других операторов.
1. Введение
Требования к современным технологиям доступа в некоторой степени противоречивы. Желательно подключить множество хостов удаленного сайта через одно устройство доступа, находящееся на этом сайте. Желательно также обеспечить контроль доступа и функциональность, подобные предоставлению услуг по коммутируемым каналам на базе PPP. В большинстве вариантов наиболее эффективным экономически является метод подключения множества хостов к одному устройству доступа на стороне абонента через сеть Ethernet. Весьма желательно также обеспечить невысокую цену для устройства доступа, вкупе с простотой настройки или возможностью обойтись вообще без настройки конфигурации этого устройства.
PPPoE обеспечивает возможность подключения сети хостов через одно простое устройство доступа, обеспечивающее функции моста, к удаленному концентратору доступа6. В этой модели каждый хост использует свой стек PPP и пользователь представляется с обычным интерфейсом. Контроль доступа, учет работы (billing) и тип обслуживания могут осуществляться для отдельных пользователей, а не для сайта в целом.
Для обеспечения соединений «точка-точка» через сеть Ethernet каждая сессия PPP должна узнать Ethernet-адрес удаленного партнера, а также создать уникальный идентификатор сессии. PPPoE включает протокол обнаружения для решения этих задач7.
2. Уровни требований
Ключевые слова: необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [2].
3. Обзор протокола
Работа PPPoE включает два разных этапа – обнаружение8 и сеанс PPP9. Хост, желающий организовать сеанс PPPoE, должен выполнить этап Discovery для определения MAC-адреса партнера и создания идентификатора сеанса PPPoE SESSION_ID. Хотя PPP определяет равноправное взаимодействие, этап Discovery использует отношения «клиент-сервер». В процессе обнаружения хост (клиент) отыскивает концентратор доступа (сервер). В зависимости от топологии сети в ней может присутствовать более одного концентратора доступа, с которым может взаимодействовать хост. Этап Discovery позволяет хосту обнаружить концентраторы доступа и выбрать один из них. После успешного завершения этапа Discovery хост и выбранный им концентратор доступа имеют информацию, которая требуется для организации соединения «точка-точка» через сеть Ethernet.
Этап Discovery не задает какого-либо состояния, пока не будет организован сеанс PPP. После организации сеанса PPP хост и концентратор доступа должны выделить ресурсы для виртуального интерфейса PPP.
4. Информационное поле пакетов
В этом параграфе определен формат пакетов. Содержимое информационного поля определено ниже при описании этапов Discovery и PPP.
Формат кадра Ethernet показан на рисунке.
1
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DESTINATION_ADDR |
| (6 октетов) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_ADDR |
| (6 октетов) |
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| ETHER_TYPE (2 октета) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ ~
~ payload ~
~ ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CHECKSUM |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Поле DESTINATION_ADDR содержит индивидуальный Ethernet-адрес10 получателя или широковещательный адрес Ethernet (0xffffffff). Для пакетов Discovery адрес может быть индивидуальным или широковещательным, как описано в параграфе 5. Этап Discovery. Для трафика сеансов PPP это поле должно содержать индивидуальный адрес партнера, определенный на этапе Discovery.
Поле SOURCE_ADDR должно содержать MAC-адрес отправителя.
Поле ETHER_TYPE имеет значение 0x8863 (Discovery) или 0x8864 (PPP Session).
Данные кадра Ethernet для PPPoE имеют следующий формат:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| VER | TYPE | CODE | SESSION_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LENGTH | payload ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Поле VER имеет размер 4 бита и должно иметь значение 0x1 для данной версии спецификации PPPoE.
4-битовое поле TYPE должно иметь значение 0x1 для данной версии спецификации PPPoE.
8-битовое поле CODE определено ниже при описании этапов Discovery и PPP Session.
Поле SESSION_ID имеет размер 16 битов и трактуется как целое число без знака с сетевым порядком байтов. Значения поля для этапа Discovery определены ниже. Значение этого поля фиксируется для данной сессии PPP и, фактически, определяет связь пакета с сессией PPP вместе с полями SOURCE_ADDR и DESTINATION_ADDR кадра Ethernet. Значение 0xffff зарезервировано и его использование недопустимо.
Поле LENGTH имеет размер 16 битов. Значение этого поля (сетевой порядок байтов) определяет размер информационного поля PPPoE. Значение поля не учитывает размер заголовков Ethernet и PPPoE.
5. Этап Discovery
Этап обнаружения (Discovery) состоит из 4 частей. По завершении этого этапа оба партнера получают значение идентификатора сессии PPPoE (SESSION_ID) и Ethernet-адрес своего партнера, которые совместно обеспечивают уникальную идентификацию сеансов PPPoE. Процесс обнаружения включает широковещательную передачу хостом пакета Initiation, передачу одним или несколькими концентраторами доступа пакетов Offer, передачу хостом пакета Session Request по индивидуальному адресу и передачу выбранным концентратором доступа пакета Confirmation (подтверждение). Когда хост получает пакет Confirmation, он может переходить к этапу PPP Session. Концентратор доступа, передав пакет Confirmation, может переходить к этапу PPP Session.
Все кадры Ethernet на этапе Discovery имеют значение ETHER_TYPE = 0x8863.
Информационное поле PPPoE может содержать теги, представляющие собой триплеты TLV11, формат которых показан ниже.
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 ... ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
16-битовое поле TAG_TYPE использует сетевой порядок байтов. Список значений полей TAG_TYPE и TAG_VALUE приведен в Приложении A.
Поле TAG_LENGTH имеет размер 16 битов. Это целое число без знака с сетевым порядком байтов показывает число октетов в поле TAG_VALUE.
Если на этапе обнаружения получен пакет с тегом неизвестного типа, данный тег должен игнорироваться, если в этом документе явно не указано иное. Такое поведение обеспечит обратную совместимость в случае добавления новых тегов. При добавлении новых тегов со статусом обязательных (mandatory) будет изменен номер версии.
Примеры пакетов Discovery приводятся в Приложении B.
5.1 Пакет PADI
Хост передает пакет PADI12 с широковещательным адресом в поле DESTINATION_ADDR. Поле CODE имеет значение 0x09, а поле SESSION_ID должно иметь значение 0x0000.
Пакет PADI должен включать в точности единственный тег типа Service-Name, показывающий запрашиваемый хостом тип сервиса, и может также содержать произвольное число тегов иных типов. Размер пакета PADI в целом (включая заголовок PPPoE) не может превышать 1484 октетов, чтобы транслирующий пакет агент мог добавить тег Relay-Session-Id.
5.2 Пакет PADO
Когда концентратор доступа получает пакет PADI, который он может обслужить, этот концентратор передает в ответ пакет PADO13. Поле DESTINATION_ADDR в этом пакете содержит индивидуальный адрес хоста, передавшего пакет PADI. Поле CODE имеет значение 0x07, а поле SESSION_ID должно иметь значение 0x0000.
Пакет PADO должен содержать один тег AC-Name, указывающий имя концентратора доступа, и тег Service-Name из полученного пакета PADI, а также может включать произвольное число тегов Service-Name, показывающих другие типы сервиса, предоставляемого данным концентратором доступа. Если концентратор доступа не может обслужить пакет PADI, для него недопустимо передавать в ответ пакет PADO.
5.3 Пакет PADR
Поскольку пакет PADI передается с использованием широковещательного адреса, хост может получить в ответ более одного пакета PADO. Хост просматривает полученные пакеты PADO и выбирает один из них. Выбор может основываться на включенных в эти пакеты тегах AC-Name или предлагаемых концентратором услугах. После этого хост передает выбранному концентратору доступа один пакет PADR14. Поле DESTINATION_ADDR в этом пакете содержит индивидуальный Ethernet-адрес выбранного концентратора доступа из пакета PADO. Поле CODE имеет значение 0x19, а поле SESSION_ID должно иметь значение 0x0000.
Пакет PADR должен включать в точности один тег типа Service-Name, показывающий запрашиваемый хостом сервис, и может также включать произвольное число тегов иных типов.
5.4 Пакет PADS
Когда концентратор доступа получает пакет PADR, он готовится к началу сеанса PPP. Концентратор генерирует уникальное значение SESSION_ID для сеанса PPPoE и отвечает хосту пакетом PADS15. Поле DESTINATION_ADDR в этом пакете содержит индивидуальный Ethernet-адрес хоста из пакета PADR. Поле CODE имеет значение 0x65, а поле SESSION_ID должно содержать уникальный идентификатор, созданный для сеанса PPPoE.
Пакет PADS содержит единственный один тег типа Service-Name, показывающий тип сервиса, для которого концентратор доступа организовал сеанс PPPoE, и может также включать произвольное число тегов иных типов.
Если концентратор доступа не устраивает значение Service-Name из пакета PADR, он должен ответить пакетом PADS, содержащим тег типа Service-Name-Error (и произвольное количество прочих тегов). В этом случае поле SESSION_ID должно иметь значение 0x0000.
5.5 Пакет PADT
Пакет этого типа может передаваться после организации сеанса PPPoE для индикации разрыва сессии. Такие пакеты могут передаваться как хостом, так и концентратором доступа. Поле DESTINATION_ADDR содержит индивидуальный адрес Ethernet, поле CODE имеет значение 0xa7, а поле SESSION_ID должно содержать идентификатор прерываемой сессии. Тегов для пакетов этого типа не требуется.
При получении пакета PADT16 не допускается дальнейшая передача трафика PPP в данной сессии. Для нормального завершения сеанса PPP недопустимо использовать пакеты PADT. Узлу PPP следует использовать средства протокола PPP для завершения сессии PPPoE, однако пакеты PADT могут применяться в тех случаях, когда невозможно использовать средства протокола PPP.
6. Этап PPP Session
После организации сеанса PPPoE данные PPP передаются как обычно (инкапсуляция PPP). Все кадры Ethernet используют индивидуальные адреса. Для поля ETHER_TYPE устанавливается значение 0x8864. Поле CODE пакетов PPPoE должно иметь значение 0x00. Значение поля SESSION_ID недопустимо изменять с течение сеанса PPPoE и это значение должно совпадать с идентификатором, полученным на этапе Discovery. Информационное поле пакетов PPPoE содержит кадр PPP, начинающийся с идентификатора Protocol-ID. Примеры пакетов показаны в Приложении B.
7. Вопросы управления каналом (LCP)
Рекомендуется использовать конфигурационную опцию LCP Magic Number и не рекомендуется использовать опцию PFC17. Для реализаций недопустимо запрашивать любые из перечисленных ниже опций и требуется отвергать запросы на такие опции:
Для опции MRU21 недопустимо согласовывать значения более 149222. Поскольку кадр Ethernet может включать не более 1500 октетов полезной информации, заголовок PPPoE занимает 6 октетов, а поле PPP Protocol ID – 2 октета, значение PPP MTU недопустимо делать более 1492.
Концентраторам доступа рекомендуется время от времени передавать хосту пакеты Echo-Request для определения состояния сеанса. В противном случае, если хост прервал сессию без передачи пакета Terminate-Request, концентратор доступа не сможет определить, что сессия уже разорвана.
При прерывании LCP хост и концентратор доступа должны прекратить использование сессии PPPoE. Если хост желает организовать другой сеанс PPP, он должен вернуться к этапу PPPoE Discovery.
8. Прочие вопросы
Если хост не получает пакета PADO в течение заданного интервала времени, ему следует заново передать свой пакет PADI и удвоить период ожидания. Эта процедура может повторяться желаемое количество раз. При ожидании хостом пакета PADS следует применять аналогичную процедуру с повтором передачи пакета PADR. После заданного числа попыток хосту следует повторить передачу пакета PADI.
Значения ETHER_TYPE, используемые в данном документе (0x8863 и 0x8864), были выделены IEEE для использования с PPPoE. Эти значения в комбинации с полем PPPoE VER (версия) служат уникальным идентификатором протокола.
В данном документе используется кодировка UTF-8 [5] взамен ASCII. UTF-8 поддерживает весь набор символов ASCII, а также символы других языков. Дополнительную информацию об этой кодировке можно найти в документе [5].
9. Вопросы безопасности
Для защиты от DoS-атак23 концентраторы доступа могут использовать тег AC-Cookie. Концентраторам следует обеспечивать возможность повторной генерации уникальных значений поля TAG_VALUE на основе значения поля SOURCE_ADDR в пакете PADR. Такой подход обеспечивает гарантию того, что поле SOURCE_ADDR в пакете PADI содержит доступный адрес, и позволяет ограничить число одновременных сессий для этого адреса. Выбор алгоритма не задается спецификацией и остается за разработчиками. Примером алгоритма может служить использование HMAC [3] применительно к MAC-адресу хоста с ключом, который известен лишь концентратору доступа. Тег AC-Cookie помогает предотвратить некоторые типы DoS-атак, но он не может защитить от всех атак на службы и концентраторы доступа могут применять также другие механизмы защиты.
Многие концентраторы доступа не захотят сообщать информацию о поддерживаемых услугах непроверенным хостам. В таких случаях концентратору следует реализовать один из двух вариантов политики:
-
концентратору ни в коем случае не следует отвергать запросы на основании тега Service-Name и всегда следует возвращать значение TAG_VALUE, которое было передано концентратору;
-
концентратору следует принимать только запросы, в которых тег Service-Name имеет поле TAG_LENGTH=0 (любой сервис).
Рекомендуется использовать второй вариант.
10. Благодарности
Этот документ основан на результатах дискуссий в нескольких форумах, включая ADSL forum.
Часть текста документа была заимствована из RFC 1661, RFC 1662 и RFC 2364.
11. Литература
[1] Simpson, W., Editor, “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, July 1994
[2] Bradner, S., “Key words for use in RFCs to Indicate Requirement Levels”, BCP 14, RFC 2119, March 1997.
[3] Krawczyk, H., Bellare, M. and R. Canetti, “HMAC: Keyed-Hashing for Message Authentication”, RFC 2104, February 1998.
[4] Reynolds, J. and J. Postel, “Assigned Numbers”, STD 2, RFC 170025, October 1994. См. также http://www.iana.org/numbers.html
[5] Yergeau, F., “UTF-8, a transformation format of ISO 10646”, RFC 2279, January 1998.
Приложение A
Типы и значения тегов
0x0000 End-Of-List
Этот тег показывает завершение списка имеющихся тегов. Поле TAG_LENGTH для этого тега всегда должно иметь нулевое значение. Использование этого тега не обязательно, но рекомендуется с точки зрения совместимости со старыми версиями.
0x0101 Service-Name
Этот тег показывает, что далее следует имя сервиса. Поле TAG_VALUE представляет собой строку символов UTF-8 без завершающего NULL-символа. Нулевое значение поля TAG_LENGTH служит для индикации приемлемости любого сервиса. Примером использования тега Service-Name может служить индикация имени ISP26, класса или качества обслуживания.
0x0102 AC-Name
Этот тег показывает, что далее следует строка, являющаяся уникальным идентификатором данного концентратора доступа. Эта строка может представлять собой, например, комбинацию торговой марки, модели и серийного номера устройства или просто задавать MAC-адрес концентратора в кодировке UTF-8. Строка не завершается NULL-символом.
0x0103 Host-Uniq
Этот тег используется хостом для того, чтобы однозначно (уникально) связать отклик концентратора доступа (PADO или PADS) с определенным запросом хоста (PADI или PADR). Значение TAG_VALUE представляет собой бинарные данные произвольного размера, выбранные хостом. Значение этого поля не интерпретируется концентратором доступа. Хост может включать тег Host-Uniq в пакеты PADI или PADR. Если концентратор доступа получает такой тег, он должен без изменений скопировать его в соответствующий отклик PADO или PADS.
0x0104 AC-Cookie
Этот тег используется концентраторами доступа для защиты от атак на службы (см. параграф 9. Вопросы безопасности). Концентратор может включать этот тег в пакет PADO. Если хост получает пакет с таким тегом, он должен без изменений скопировать тег в соответствующий пакет PADR. Поле TAG_VALUE представляет собой бинарные данные произвольной длины, которые не интерпретируются хостом.
0x0105 Vendor-Specific
Этот тег используется для передачи фирменной (proprietary) информации от производителя. Первые 4 октета поля TAG_VALUE содержат идентификатор производителя, а остальные могут быть произвольными (не задаются спецификацией). Старший октет идентификатора производителя имеет значение 0, а остальные 3 октета содержат значение SMI Network Management Private Enterprise Code для данного производителя с использованием сетевого порядка байтов. Коды определены в документе Assigned Numbers [4].
Использование этого тега не рекомендуется. В целях обеспечения взаимодействия реализация может игнорировать тег Vendor-Specific.
0x0110 Relay-Session-Id
Этот тег может добавляться к любым пакетам обнаружения на промежуточных агентах, транслирующих трафик. Поле TAG_VALUE не интерпретируется хостом и концентратором доступа. Если хост или концентратор получает пакет с таким тегом, он должен скопировать тег без изменений в передаваемый пакет отклика. Во всех пакетах PADI должно резервироваться место для добавления тега Relay-Session-Id TAG с полем TAG_VALUE размером 12 октетов.
Тег Relay-Session-Id недопустимо добавлять, если в пакете обнаружения уже имеется такой тег. В этом случае промежуточному транслятору следует использовать существующий тег Relay-Session-Id. Если существующий тег нельзя использовать или в пакете нет места для добавления тега Relay-Session-Id, отправителю пакета следует отправить пакет с тегом Generic-Error.
0x0201 Service-Name-Error
Этот тег TAG (обычно с полем данных нулевого размера) показывает, что по той или иной причине запрос Service-Name не может быть удовлетворен.
Если тег содержит данные и их первый октет отличается от нуля, эти данные должны представлять собой строку в кодировке UTF-8, которая объясняет причину отказа. Строка может не содержать завершающего NULL-символа.
0x0202 AC-System-Error
Этот тег показывает, что концентратор доступа столкнулся с той или иной ошибкой при выполнении запроса хоста (например, нехватка ресурсов для создания виртуального устройства). Тег может включаться в пакеты PADS.
Если тег включает данные, первый октет которых отличается от 0, эти данные должны представлять собой строку в кодировке UTF-8, объясняющую причину ошибки. Строка может не содержать завершающего NULL-символа.
0x0203 Generic-Error
Этот тег указывает на наличие ошибки. Тег может включаться в пакеты PADO, PADR или PADS при возникновении неисправимой ошибки и отсутствии иных тегов, подходящих для объяснения причин ошибки. Если тег содержит данные, последние должны представлять собой строку в кодировке UTF-8, объясняющую причину ошибки. Строка может не содержать завершающего NULL-символа.
Приложение B
Ниже приводятся примеры некоторых пакетов.
Пакет 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 (продолжение) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (продолжение)| Access_Concentrator_mac_addr |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Access_Concentrator_mac_addr (продолжение) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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 (payload) не приводятся. Такие пакеты передаются от хоста концентратору доступа.
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 (продолжение) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 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
United States of America
EMail: louie@uu.net
Kurt Lidl
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: lidl@uu.net
Jeff Evarts
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: jde@uu.net
David Carrel
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
EMail: carrel@RedBack.net
Dan Simone
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
EMail:dan@RedBack.net
Ross Wheeler
RouterWare, Inc.
3961 MacArthur Blvd., Suite 212
Newport Beach, CA 92660
United States of America
EMail: ross@routerware.com
Перевод на русский язык
Николай Малых
Полное заявление авторских прав
Copyright (C) The Internet Society (1999). Все права защищены.
Этот документ и его переводы могут копироваться и предоставляться другим лицам, а производные работы, комментирующие или иначе разъясняющие документ или помогающие в его реализации, могут подготавливаться, копироваться, публиковаться и распространяться целиком или частично без каких-либо ограничений при условии сохранения указанного выше уведомления об авторских правах и этого параграфа в копии или производной работе. Однако сам документ не может быть изменён каким-либо способом, таким как удаление уведомления об авторских правах или ссылок на Internet Society или иные организации Internet, за исключением случаев, когда это необходимо для разработки стандартов Internet (в этом случае нужно следовать процедурам для авторских прав, заданных процессом Internet Standards), а также при переводе документа на другие языки.
Предоставленные выше ограниченные права являются бессрочными и не могут быть отозваны Internet Society или правопреемниками.
Этот документ и содержащаяся в нем информация представлены “как есть” и автор, организация, которую он/она представляет или которая выступает спонсором (если таковой имеется), Internet Society и IETF отказываются от каких-либо гарантий (явных или подразумеваемых), включая (но не ограничиваясь) любые гарантии того, что использование представленной здесь информации не будет нарушать чьих-либо прав, и любые предполагаемые гарантии коммерческого использования или применимости для тех или иных задач.
1Point-to-Point Protocol.
2Link Control Protocol.
3Network-layer Control Protocols.
4Bridged Ethernet topology.
5PPP Over Ethernet.
6Access Concentrator.
7Discovery protocol.
8Discovery stage.
9PPP Session stage.
10MAC-адрес. Прим. перев.
11Type-length-value – тип-размер-значение.
12PPPoE Active Discovery Initiation – инициирование процесса обнаружения PPPoE. Прим. перев.
13PPPoE Active Discovery Offer.
14PPPoE Active Discovery Request.
15PPPoE Active Discovery Session-confirmation.
16PPPoE Active Discovery Terminate.
17Protocol Field Compression – сжатие полей протокола.
18Field Check Sequence – контрольная сумма поля.
19Address-and-Control-Field-Compression – сжатие адресных и управляющих полей.
20Asynchronous-Control-Character-Map – отображение символов асинхронного управления.
21Maximum-Receive-Unit – максимальный размер принимаемого пакета.
23Denial of Service – атака, направленная на отказ служб.
25В соответствии с RFC 3232 документ RFC 1700 утратил статус стандарта. Выделенные значения доступны на сайте, указанном ссылкой. Прим. перев.
26Internet Service Provider – поставщик услуг Internet. Прим. перев.
