Network Working Group W. Simpson
Request for Comments: 2153 DayDreamer
Updates: RFCs 1661, 1962 May 1997
Category: Informational
Расширения поставщиками ПО протокола PPP
PPP Vendor Extensions
Статус этого документа
Этот документ предоставляет информацию для сообщества Интернет. Он не описывает стандарты Интернет ни в каком виде. Распространение этого документа не ограничено.
Аннотация
Протокол точка-точка (Point-to-Point Protocol-PPP) [1] предоставляет стандартный метод для транспортировки мультипротокольных дейтаграмм через соединения точка-точка. РРР определяет расширяемый протокол LCP (Link Control Protocol) для установления, конфигурирования и тестирования соединений канального уровня; и семейство протоколов NCP (Network Control Protocol) для установления и конфигурирования различных протоколов сетевого уровня.
Этот документ определяет общий механизм для пропроетарных расширений.
1 Управляющие пакеты
Формат пакетов и основные и основные возможности определены уже для LCP [1] и для соответствующих протоков NCP.
Современные значения LCP полей Code определены в [1]. Этот документ описывает следующие значения:
0 Vendor Specific
1.1 Пакеты Vendor Specific
Описание
Некоторые разработчики могут не хотеть или не нуждаться в публикации их фирменных алгоритмов или атрибутов. Этот механизм предназначен для того, чтобы сделать возможным их описание, не обременяя IANA запросами на фирменные номера.
Пакеты Vendor Specific МОГУТ быть посланы в любое время, включая период перед состоянием Opened.
Отправитель передает LCP или NCP пакеты с полем Code, установленным в 0 (Vendor Specific), устанавливается поле Identifier, вставляется локальный Magic-Number, устанавливаются поля OUI и Kind, и поле Value(s) заполняется любыми данными, не выходя за границу MRU-12.
Получение пакета Vendor Specific вызывает событие RXR или RUC. Ответ на пакет Vendor Specific является пакетом Vendor Specific.
На получение Code-Reject для пакета СЛЕДУЕТ сгенерировать событие RXJ+ (разрешенное).
Логическое обоснование
Это определено как основная особенность всех управляющих протоколов PPP для предотвращения возможных конфликтов в будущем в самостоятельно назначаемых разработчиками номерах Code.
Формат пакета Vendor Specific показан ниже. Поля передаются слева направо.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value(s) ...
+-+-+-+-+-+-+-+-+
Code
0 для Vendor Specific
Identifier
Поле Identifier ДОЛЖНО быть изменено при отправке каждого пакета Vendor Specific.
Length
>= 12
Когда Length=12, поле Value(s) отсутствует.
Magic-Number
Поле Magic-Number состоит из четырех октетов и предназначено для детектирования соединений, на которых возникли условия для образования петли. Пока конфигурационная опция Magic-Number не согласована, Magic-Number ДОЛЖЕН передаваться как ноль. Подробности смотри в разделе «Конфигурационная опция Magic-Number».
OUI
Три октета. Organizationally Unique Identifier производителя. Биты в пределах октета находятся в каноническом порядке, старший октет передается первым.
Kind
Один октет. Показывает подтип OUI. Это поле не стандартизовано. Каждый OUI реализует свои собственные значения.
Поле Kind может быть расширено разработчиком включением нуля или больше октетов поля Value(s).
Value(s)
Нуль или больше октетов. Детали зависят от реализации.
2 Конфигурационные опции
Формат конфигурационных опций и основных опций уже определен для LCP [1].
Современные значения LCP поля Option Type определены в [2]. Этот документ описывает следующие значения:
0 Vendor Specific
2.1 Опции Vendor-Specific
Описание
Некоторые разработчики могут не хотеть или не нуждаться в публикации их фирменных алгоритмов или атрибутов. Этот механизм предназначен для того, чтобы сделать возможным их описание, не обременяя IANA запросами на фирменные номера.
Перед подтверждением этой опции реализация должна проверить, что Organizationally Unique Identifier и Kind указывают на знакомый механизм и что согласуемые vendor specific значения полностью понятны.
Логическое обоснование
Это определено как основная особенность для всех управляющих протоколов PPP для предотвращения возможных конфликтов в будущем в самостоятельно назначаемых разработчиками номерах Type.
Формат Vendor-Specific конфигурационной опции показан ниже. Поля передаются слева направо.
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | OUI
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
Code
0 для Vendor Specific
Length
>= 6
Когда Length=6, поле Value(s) отсутствует.
OUI
Три октета. Organizationally Unique Identifier производителя. Биты в пределах октета находятся в каноническом порядке, старший октет передается первым.
Kind
Один октет. Показывает подтип OUI. Это поле не стандартизовано. Каждый OUI реализует свои собственные значения.
Поле Kind может быть расширено разработчиком включением нуля или больше октетов поля Value(s).
Value(s)
Нуль или больше октетов. Детали зависят от реализации.
3 Organizationally Unique Identifiers
Трехоктетный Organizationally Unique Identifier (OUI) определяет организацию, которая администрирует значения сообщения. Этот OUI основан на назначениях производителей IEEE 802.
Детали для контакта с IEEE для присвоения OUI даны в [RFC-1700]. Производители, которые желают использовать их IEEE 802 OUI для расширений PPP должны также зарегистрировать OUI в IANA.
В качестве альтернативы, производители, которые не нуждаются в OUI, назначенном IEEE, могут запросить OUI, специфичный для PPP в IANA. Этот OUI должен быть назначен из серии CF0000. Он имеет биты «locally-assigned» и «broadcast/multicast» установленные в 1. Два младшие бита в старшем октете устанавливаются в 1.
Появившись в памяти, биты в пределах октета передаются справа налево, октеты передаются слева направо:
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
| Multicast
Local
Логическое обоснование
Это определено для производителей не могут использовать назначения IEEE, такие как производители только-програмного обеспечения.
Неясно, как IEEE назначает блоки. В некоторых случаях известно, что будет использован бит «locally-assigned».
Конечно, multicast не имеет значения в PPP. Следовательно, OUI назначенные IEEE будут иметь бит multicast сброшенный в 0.
Серия CF0000 была выбрана для удобства запоминания, чтобы соответствовать PPP NLPID ‘CF’.
Обсуждение вопросов безопасности
Проблемы безопасности не обсуждаются в этом документе.
Ссылки
[1] Simpson, W., Editor, “The Point-to-Point Protocol (PPP)”, STD 51, RFC 1661, DayDreamer, July 1994.
[2] Reynolds, J.K., Postel, J.B., “Assigned Numbers”, RFC-1700, July 1992.
Контакты
Комментарии об этом документе следует обсуждать в листе рассылки ietf-ppp@merit.edu
Этот документ рецензирован Point-to-Point Protocol Working Group of the Internet Engineering Task Force (IETF). Контактировать с рабочей группой можно через ее текущего председателя:
Karl Fox
Ascend Communications
655 Metro Place South, Suite 379
Dublin, Ohio 43017
Вопросы об этом документе могут быть направлены:
William Allen Simpson
DayDreamer
Computer Systems Consulting Services
1384 Fontaine
Madison Heights, Michigan 48071
wsimpson@UMich.edu wsimpson@GreenDragon.com (предпочтительнее)
Перевод на русский язык
Игорь Шеваров
