分享
 
 
 

RFC2153 - PPP Vendor Extensions

王朝other·作者佚名  2008-05-31
窄屏简体版  字體: |||超大  

Network Working Group W. Simpson

Request for Comments: 2153 DayDreamer

Updates: RFCs 1661, 1962 May 1997

Category: Informational

PPP Vendor Extensions

Status of this Memo

This document provides information for the Internet community. It

does not specify an Internet standard of any kind. Distribution of

this memo is unlimited.

Abstract

The Point-to-Point Protocol (PPP) [1] provides a standard method for

transporting multi-protocol datagrams over point-to-point links. PPP

defines an extensible Link Control Protocol (LCP) for establishing,

configuring, and testing the data-link connection; and a family of

Network Control Protocols (NCPs) for establishing and configuring

different network-layer protocols.

This document defines a general mechanism for proprietary vendor

extensions.

Simpson Informational [Page i]

RFC2153 PPP vendor extensions May 1997

Table of Contents

1. Control Packets ....................................... 1

1.1 Vendor Specific Packet .......................... 1

2. Configuration Options ................................. 3

2.1 Vendor-Specific Option .......................... 3

3. Organizationally Unique Identifiers ................... 4

SECURITY CONSIDERATIONS ...................................... 5

REFERENCES ................................................... 5

CONTACTS ..................................................... 6

Simpson Informational [Page ii]

RFC2153 PPP vendor extensions May 1997

1. Control Packets

The Packet format and basic facilities are already defined for LCP

[1] and related NCPs.

Up-to-date values of the LCP Code field are specified in the most

recent "Assigned Numbers" [2]. This document concerns the following

values:

0 Vendor Specific

1.1. Vendor Specific Packet

Description

Some implementors might not need nor want to publish their

proprietary algorithms and attributes. This mechanism is

available to specify these without encumbering the IANA with

proprietary number requests.

Vendor Specific packets MAY be sent at any time, including before

LCP has reached the Opened state.

The sender transmits a LCP or NCP packet with the Code field set

to 0 (Vendor Specific), the Identifier field set, the local

Magic-Number (if any) inserted, the OUI and Kind fields set, and

the Value(s) field filled with any desired data, but not exceeding

the default MRU minus twelve.

Receipt of a Vendor Specific packet causes the RXR or RUC event.

The response to the Vendor Specific packet is vender specific.

Receipt of a Code-Reject for the packet SHOULD generate the RXJ+

(permitted) event.

Rationale:

This is defined as general feature of all PPP Control Protocols,

to avoid future conflicts in vendor secretly self-assigned Code

numbers.

A summary of the Vendor Specific packet format is shown below. The

fields are transmitted from left to right.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Code Identifier Length

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Magic-Number

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

OUI Kind

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Value(s) ...

+-+-+-+-+-+-+-+-+

Code

0 for Vendor Specific

Identifier

The Identifier field MUST be changed for each Vendor Specific

packet sent.

Length

>= 12

When the Length is twelve, no Value(s) field is present.

Magic-Number

The Magic-Number field is four octets and aids in detecting links

that are in the looped-back condition. Until the Magic-Number

Configuration Option has been successfully negotiated, the Magic-

Number MUST be transmitted as zero. See the Magic-Number

Configuration Option for further eXPlanation.

OUI

three octets. The vendor's Organizationally Unique Identifier.

The bits within the octet are in canonical order, and the most

significant octet is transmitted first.

Kind

one octet. Indicates a sub-type for the OUI. There is no

standardization for this field. Each OUI implements its own

values.

The Kind field may be extended by the vendor to include zero or

more octets of the Value(s) field.

Value(s)

Zero or more octets. The details are implementation specific.

2. Configuration Options

The Configuration Option format and basic options are already defined

for LCP [1].

Up-to-date values of the LCP Option Type field are specified in the

most recent "Assigned Numbers" [2]. This document concerns the

following values:

0 Vendor-Specific

2.1. Vendor-Specific Option

Description

Some implementors might not need nor want to publish their

proprietary algorithms and attributes. This mechanism is

available to specify these without encumbering the IANA with

proprietary number requests.

Before accepting this option, the implementation must verify that

the Organizationally Unique Identifier and Kind specify a known

mechanism, and that any vendor specific negotiation values are

fully understood.

Rationale:

This is defined as general feature of all PPP Control Protocols,

to avoid future conflicts in vendor secretly self-assigned Type

numbers.

A summary of the Vendor-Specific Configuration Option format is shown

below. The fields are transmitted from left to right.

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Type Length OUI

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

... Kind Value(s) ...

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Type

0

Length

>= 6

When the Length is six, no Value(s) field is present.

OUI

three octets. The vendor's Organizationally Unique Identifier.

The bits within the octet are in canonical order, and the most

significant octet is transmitted first.

Kind

one octet. Indicates a sub-type for the OUI. There is no

standardization for this field. Each OUI implements its own

values.

The Kind field may be extended by the vendor to include zero or

more octets of the Value(s) field.

Value(s)

Zero or more octets. The details are implementation specific.

3. Organizationally Unique Identifiers

The three-octet Organizationally Unique Identifier (OUI) identifies

an organization that administers the meaning of the message. This

OUI is based on IEEE 802 vendor assignments.

IEEE contact details for assignment of an OUI are given in [RFC-

1700]. Vendors that desire to use their IEEE 802 OUI for PPP Vendor

Extensions should also register the OUI with IANA.

In the alternative, a vendor that does not otherwise need an IEEE

assigned OUI can request a PPP specific OUI from IANA. This OUI

shall be assigned from the 'CF0000' series. This has both the

"locally-assigned" and "broadcast/multicast" bits set to 1; that is,

the least significant two bits of the most significant octet are both

set to 1.

Appearance in memory, bits transmitted right-to-left within octets,

octets transmitted left-to-right:

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

1 1 0 0 1 1 1 1x x x x x x x xx x x x x x x x

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Multicast

Local

Rationale:

This is defined for vendors that are not able to use IEEE

assignments, such as software-only vendors.

It is not clear how the IEEE assigns blocks. In some instances,

the "locally-assigned" bit is known to have been used.

However, multicast has no meaning in PPP. Therefore, an IEEE

assigned OUI would have the multicast bit cleared to 0.

The 'CF0000' series was arbitrarily chosen to match the PPP NLPID

'CF', as a matter of mnemonic convenience.

Security Considerations

Security issues are not discussed in this document.

References

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD

51, RFC1661, DayDreamer, July 1994.

[2] Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,

July 1992.

Contacts

Comments about this document should be discussed on the ietf-

ppp@merit.edu mailing list.

This document was reviewed by the Point-to-Point Protocol Working

Group of the Internet Engineering Task Force (IETF). The working

group can be contacted via the current chair:

Karl Fox

Ascend Communications

655 Metro Place South, Suite 379

Dublin, Ohio 43017

karl@Ascend.com

Questions about this document can also be directed to:

William Allen Simpson

DayDreamer

Computer Systems Consulting Services

1384 Fontaine

Madison Heights, Michigan 48071

wsimpson@UMich.edu

wsimpson@GreenDragon.com (preferred)

 
 
 
免责声明:本文为网络用户发布,其观点仅代表作者个人观点,与本站无关,本站仅提供信息存储服务。文中陈述内容未经本站证实,其真实性、完整性、及时性本站不作任何保证或承诺,请读者仅作参考,并请自行核实相关内容。
2023年上半年GDP全球前十五强
 百态   2023-10-24
美众议院议长启动对拜登的弹劾调查
 百态   2023-09-13
上海、济南、武汉等多地出现不明坠落物
 探索   2023-09-06
印度或要将国名改为“巴拉特”
 百态   2023-09-06
男子为女友送行,买票不登机被捕
 百态   2023-08-20
手机地震预警功能怎么开?
 干货   2023-08-06
女子4年卖2套房花700多万做美容:不但没变美脸,面部还出现变形
 百态   2023-08-04
住户一楼被水淹 还冲来8头猪
 百态   2023-07-31
女子体内爬出大量瓜子状活虫
 百态   2023-07-25
地球连续35年收到神秘规律性信号,网友:不要回答!
 探索   2023-07-21
全球镓价格本周大涨27%
 探索   2023-07-09
钱都流向了那些不缺钱的人,苦都留给了能吃苦的人
 探索   2023-07-02
倩女手游刀客魅者强控制(强混乱强眩晕强睡眠)和对应控制抗性的关系
 百态   2020-08-20
美国5月9日最新疫情:美国确诊人数突破131万
 百态   2020-05-09
荷兰政府宣布将集体辞职
 干货   2020-04-30
倩女幽魂手游师徒任务情义春秋猜成语答案逍遥观:鹏程万里
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案神机营:射石饮羽
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案昆仑山:拔刀相助
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案天工阁:鬼斧神工
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案丝路古道:单枪匹马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:与虎谋皮
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:李代桃僵
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案镇郊荒野:指鹿为马
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:小鸟依人
 干货   2019-11-12
倩女幽魂手游师徒任务情义春秋猜成语答案金陵:千金买邻
 干货   2019-11-12
 
推荐阅读
 
 
 
>>返回首頁<<
 
靜靜地坐在廢墟上,四周的荒凉一望無際,忽然覺得,淒涼也很美
© 2005- 王朝網路 版權所有