AAA

RFC 2516 — Метод передачи PPP через Ethernet (PPPoE)

Статус документа

В этом документе содержится информация для сообщества Internet. Документ не задает каких-либо стандартов Internet и может распространяться без ограничений.

Тезисы

Point-to-Point Protocol обеспечивает стандартный метод передачи дейтаграмм различных протоколов через соединения «точка-точка». В этом документе описано как создавать сессии PPP и инкапсулировать пакеты PPP в сетях Ethernet.

Применимость

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

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

Документ описывает инкапсуляцию PPPoE, которая развернута в сетях RedBack Networks, RouterWare, UUNET и других операторов.

1. Введение

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

PPPoE обеспечивает возможность подключения сети хостов через одно простое устройство доступа, обеспечивающее функции моста, к удаленному концентратору доступа6. В этой модели каждый хост использует свой стек PPP и пользователь представляется с обычным интерфейсом. Контроль доступа, учет работы (billing) и тип обслуживания могут осуществялться для отдельных пользователей, а не для сайта в целом.

Для обеспечения соединений «точка-точка» через сеть Ethernet каждая сессия PPP должна узнать Ethernet-адрес удаленного партнера, а также создать уникальный идентификатор сессии. PPPoE включает протокол обнаружения для решения этих задач.

2. Уровни требований

Ключевые слова: необходимо (MUST), недопустимо (MUST NOT), требуется (REQUIRED), нужно (SHALL), не нужно (SHALL NOT), следует (SHOULD), не следует (SHOULD NOT), рекомендуется (RECOMMENDED), возможно (MAY), необязательно (OPTIONAL) в данном документе интерпретируются в соответствии с [2].

3. Обзор протокола

Работа PPPoE включает два разных этапа — обнаружение и сеанс PPP. Хост, желающий организовать сеанс PPPoE, должен выполнить этап Discovery для определения MAC-адреса партнера и создания идентификатора сеанса PPPoE SESSION_ID. Хотя PPP определяет равноправное взаимодействие (peer-to-peer relationship), этап Discovery использует отношения «клиент-сервер». В процессе обнаружения хост (клиент) отыскивает концентратор доступа (сервер). В зависимости от топологии сети в ней может присутствовать более одного концентратора доступа, с которым может взаимодействовать хост. Этап Discovery позволяет хосту обнаружить концентраторы доступа и выбрать один из них. После успешного завершения этапа Discovery хост и выбранный им концентратор доступа имеют информацию, которая требуется для организации соединения «точка-точка» через сеть Ethernet.

Этап Discovery не задает какого-либо состояния (stateless), пока не будет организован сеанс PPP. После организации сеанса PPP хост и концентратор доступа должны выделить ресурсы для виртуального интерфейса PPP.

4. Информационное поле пакетов

В этом параграфе определен формат пакетов. Содержимое информационного поля (payload) определено ниже при описании этапов Discovery и PPP.

Формат кадра Ethernet показан на рисунке:

                     1
 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|       DESTINATION_ADDR        |
|          (6 octets)           |
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|         SOURCE_ADDR           |
|          (6 octets)           |
|                               |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|    ETHER_TYPE  (2 octets)     |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~                               ~
~           payload             ~
~                               ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|           CHECKSUM            |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Поле DESTINATION_ADDR содержит индивидуальный (unicast) Ethernet-адрес получателя или широковещательный адрес Ethernet (0xffffffff). Для пакетов Discovery адрес может быть индивидуальным или широковещательным, как описано в параграфе «Этап Discovery». Для трафика сеансов PPP это поле должно содержать индивидуальный адрес партнера, определенный на этапе Discovery.

Поле SOURCE_ADDR должно содержать MAC-адрес отправителя.

Поле ETHER_TYPE имеет значение 0x8863 (Discovery) или 0x8864 (PPP Session).

Данные (payload) кадра 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 битов. Значение этого поля (сетевой порядок байтов) определяет размер информационного поля (payload) PPPoE. Значение пол не учитывает размер заголовков Ethernet и PPPoE.

5. Этап Discovery

Этап обнаружения (Discovery) состоит из 4 частей. По завершении этого этапа оба партнера знают значение идентификатора сессии PPPoE (SESSION_ID) и Ethernet-адрес своего партнера, которые совместно обеспечивают уникальную идентификацию сеансов PPPoE. Процесс обнаружения включает широковещательную передачу хостом пакета Initiation, передачу одним или несколькими концентраторами доступа пакетов Offer, передачу хостом пакета Session Request по индивидуальному (unicast) адресу и передачей выбранным концентратором доступа пакета Confirmation (подтверждение). Когда хост получает пакет Confirmation, он может переходить к этапу PPP Session. Концентратор доступа, передав пакет Confirmation, также может переходить к этапу PPP Session.

Все кадры Ethernet на этапе Discovery имеют значение ETHER_TYPE = 0x8863.

Информационное поле PPPoE может содержать теги (TAG), которые представляют собой триплеты 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 ...                                        ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

16-битовое поле TAG_TYPE использует сетевой порядок байтов. Список значений полей TAG_TYPE и TAG_VALUE приведен в Приложении A.

Поле TAG_LENGTH имеет размер 16 битов. Это целое число без знака с сетевым порядком байтов показывает число октетов в поле TAG_VALUE.

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

Примеры пакетов Discovery приводятся в Приложении B.

5.1 Пакет PADI

Хост передает пакет PADI с широковещательным адресом в поле DESTINATION_ADDR. Поле CODE имеет значение 0x09, а поле SESSION_ID должно иметь значение 0x0000.

Пакет PADI должен в точности 1 тег типа Service-Name, показывающий запрашиваемый хостом тип сервиса, и может также содержать произвольное число тегов иных типов. Размер пакета PADI в целом (включая заголовок PPPoE) не может превышать 1484 октетов, чтобы транслирующий пакет агент мог добавить тег Relay-Session-Id.

5.2 Пакет PADO

Когда концентратор доступа получает пакет PADI, который он может обслужить, этот концентратор передает в ответ пакет PADO. Поле 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 или предлагаемых концентратором услугах. После этого хост передает выбранному концентратору доступа один пакет PADR. Поле DESTINATION_ADDR в этом пакете содержит индивидуальный Ethernet-адрес выбранного концентратора доступа из пакета PADO. Поле CODE имеет значение 0x19, а поле SESSION_ID должно иметь значение 0x0000.

Пакет PADR должен включать в точности один тег типа Service-Name, показывающий запрашиваемый хостом сервис, и может также включать произвольное число тегов иных типов.

5.4 Пакет PADS

Когда концентратор доступа получает пакет PADR, он готовится к началу сеанса PPP. Концентратор генерирует уникальное значение SESSION_ID для сеанса PPPoE и отвечает хосту пакетом PADS. Поле 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 должно содержать идентификатор прерываемой сессии. Тегов для пакетов этого типа не требуется.

При получении пакета PADT не допускается дальнейшая передача трафика PPP в данной сессии. Для нормального завершения сеанса PPP недопустимо использовать пакеты PADT. Узлу PPP следует использовать средства протокола PPP для завершения сессии PPPoE, однако пакеты PADT могут применяться в тех случаях, когда невозможно использовать средства протокола PPP.

6. Этап PPP Session

После организации сеанса PPPoE данные PPP передаются как обычно (инкапсуляция PPP). Все кадры Ethernet используют индивидуальные (unicast) адреса. Для поля ETHER_TYPE устанавливается значение 0x8864. Поле CODE пакетов PPPoE должно иметь значение 0x00. Значение поля SESSION_ID недопустимо изменять с течение сеанса PPPoE и это значение должно совпадать с идентификатором, полученным на этапе Discovery. Информационное поле пакетов PPPoE содержит кадр PPP, начинающийся с идентификатора Protocol-ID. Примеры пакетов показаны в Приложении B.

7. Вопросы управления каналом (LCP)

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

Для опции MRU недопустимо согласовывать значения более 1492. Поскольку кадр 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-атак концентраторы доступа могут использовать тег AC-Cookie. Концентраторам следует обеспечивать возможность повторной генерации уникальных значений поля TAG_VALUE на основе значения поля SOURCE_ADDR в пакете PADR. Такой подход обеспечивает гарантию того, что поле SOURCE_ADDR в пакете PADI содержит доступный адрес, и позволяет ограничить число одновременных сессий для этого адреса. Выбор алгоритма не задается спецификацией и остается за разработчиками. Примером алгоритма может служить использование HMAC [3] применительно к MAC-адресу хоста с ключом, который известен лишь концентратору доступа. Тег AC-Cookie помогает предотвратить некоторые типы DoS-атак, но он не может защитить от всех атак на службы и концентраторы доступа могут применять также другие механизмы защиты.

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

Рекомендуется использовать второй вариант.

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 1700, October 1994. See also: http://www.iana.org/numbers.html
  5. Yergeau, F., "UTF-8, a transformation format of ISO 10646", RFC 2279, January 1998.

Приложение A

Типы и значения тегов:

Приложение 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 (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 (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 (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
United States of America
EMail: ten.uu@eiuol

Kurt Lidl
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: ten.uu@ldil

Jeff Evarts
UUNET Technologies, Inc.
3060 Williams Drive
Fairfax, VA 22031-4648
United States of America
EMail: ten.uu@edj

David Carrel
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
EMail: ten.kcabder@lerrac

Dan Simone
RedBack Networks, Inc.
1389 Moffett Park Drive
Sunnyvale, CA 94089-1134
United States of America
EMail: ten.kcabder@nad

Ross Wheeler
RouterWare, Inc.
3961 MacArthur Blvd., Suite 212
Newport Beach, CA 92660
United States of America
EMail: moc.erawretuor@ssor

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

Николай Малых, moc.milib@hkylamn