RFC 2153 PPP Vendor Extensions

image_print
Network Working Group                                     W. Simpson
Request for Comments: 2153                                DayDreamer
Updates: RFCs 1661, 1962                                    May 1997
Category: Informational

Расширения поставщиками ПО протокола PPP

PPP Vendor Extensions

PDF

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

Этот документ предоставляет информацию для сообщества Интернет. Он не описывает стандарты Интернет ни в каком виде. Распространение этого документа не ограничено.

Краткий обзор

Протокол точка-точка (Point-to-Point Protocol-PPP) [1] предоставляет стандартный метод для транспортировки мультипротокольных дейтаграмм через соединения точка-точка. РРР определяет расширяемый протокол LCP (Link Control Protocol) для установления, конфигурирования и тестирования соединений канального уровня; и семейство протоколов NCP (Network Control Protocol) для установления и конфигурирования различных протоколов сетевого уровня.

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

Оглавление

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

1 Управляющие пакеты

Формат пакетов и основные и основные возможности определены уже для LCP [1] и для соответствующих протоков NCP.

Современные значения LCP полей Code определены в [2]. Этот документ описывает следующие значения:

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

karl@Ascend.com

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

William Allen Simpson

DayDreamer

Computer Systems Consulting Services

1384 Fontaine

Madison Heights, Michigan 48071

wsimpson@UMich.edu wsimpson@GreenDragon.com (предпочтительнее)


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

Игорь Шеваров

issh@onego.ru

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

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