|
Network Working Group W. Simpson
Request for Comments: 2153 DayDreamer
Updates: RFCs 1661, 1962 May 1997 Category: Informational
PPP Vendor Extensions Расширения поставщиками ПО протокола PPP.
Статус этого документа
Этот документ предоставляет информацию для сообщества Интернет. Он не описывает стандарты Интернет ни в каком виде. Распространение этого документа не ограничено.
Краткий обзор
Протокол точка-точка (Point-to-Point Protocol-PPP) [1] предоставляет стандартный метод для транспортировки мультипротокольных датаграмм через соединения точка-точка. РРР определяет расширяемый протокол LCP (Link Control Protocol) для установления, конфигурирования и тестирования соединений канального уровня; и семейство протоколов NCP (Network Control Protocol) для установления и конфигурирования различных протоколов сетевого уровня.
Этот документ определяет общий механизм для пропроетарных расширений.
Контакты ......................................................................................................................................... 5
1 Управляющие пакеты
Формат пакетов и основные и основные возможности определены уже для LCP [1] и для соответствующих протоков NCP.
Современные значения LCP полей Code определены в [2]. Этот документ описывает следующие значения:
0 Vendor Specific
1.1 Пакеты Vendor Specific
Описание
Некоторые разработчики могут не хотеть или не нуждаться в публикации их пропроетарных алгоритмов или атрибутов. Этот механизм предназначен для того, чтобы сделать возможным их описание, не обременяя IANA запросами на пропроетарные номера.
|
||
|
|
||
|
1
|
||
|
|
||
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
Пакеты 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
|
||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
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
|
||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
2
|
||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
Один октет. Показывает подтип 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 конфигурационной опции показан ниже. Поля передаются с лева направо.
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
Code
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
0 для Vendor Specific
Length
>= 6
Когда Length=6, поле Value(s) отсутствует.
OUI
Три октета. Organizationally Unique Identifier производителя. Биты в пределах октета находятся в каноническом порядке, старший октет передается первым.
Kind
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
3
|
||||||||||||||||||||||
|
|
||||||||||||||||||||||
|
|
||
|
Один октет. Показывает подтип 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 001 111xxxxxxxx|xxxxxxxx|
.....Ill I I I I I I I I I I I I I I I I
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.
|
||
|
|
||
|
4
|
||
|
|
||
|
|
||
|
Контакты
|
||
|
|
||
|
Комментарии об этом документе следует обсуждать в листе рассылки 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 (предпочтительнее)
|
||
|
|
||
|
5
|
||
|
Проститутки Питера на http://sexdosug.com
|
||