RFC relevance of extensions

As per Relevance of the word extensions, we have this rfc below:

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

PPP Vendor

Status of this

This document provides information for the Internet community.
does not specify an Internet standard of any kind. Distribution
this memo is unlimited

The Point-to-Point Protocol (PPP) [1] provides a standard method
transporting multi-protocol datagrams over point-to-point links.
defines an extensible Link Control Protocol (LCP) for establishing
configuring, and testing the data-link connection; and a family
Network Control Protocols (NCPs) for establishing and
different network-layer protocols

This document defines a general mechanism for proprietary
extensions

Simpson Informational [Page i

RFC 2153 PPP vendor extensions May 1997

Table of

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

RFC 2153 PPP vendor extensions May 1997

1. Control

The Packet format and basic facilities are already defined for
[1] and related NCPs

Up-to-date values of the LCP Code field are specified in the
recent "Assigned Numbers" [2]. This document concerns the
values

0 Vendor

1.1. Vendor Specific

Some implementors might not need nor want to publish
proprietary algorithms and attributes. This mechanism
available to specify these without encumbering the IANA
proprietary number requests

Vendor Specific packets MAY be sent at any time, including
LCP has reached the Opened state

The sender transmits a LCP or NCP packet with the Code field
to 0 (Vendor Specific), the Identifier field set, the
Magic-Number (if any) inserted, the OUI and Kind fields set,
the Value(s) field filled with any desired data, but not
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
numbers

A summary of the Vendor Specific packet format is shown below.
fields are transmitted from left to right

Simpson Informational [Page 1]

RFC 2153 PPP vendor extensions May 1997

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Kind |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Value(s) ...
+-+-+-+-+-+-+-+-+

0 for Vendor

The Identifier field MUST be changed for each Vendor
packet sent

>= 12

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

Magic-

The Magic-Number field is four octets and aids in detecting
that are in the looped-back condition. Until the Magic-
Configuration Option has been successfully negotiated, the Magic
Number MUST be transmitted as zero. See the Magic-
Configuration Option for further explanation

three octets. The vendor's Organizationally Unique Identifier
The bits within the octet are in canonical order, and the
significant octet is transmitted first

one octet. Indicates a sub-type for the OUI. There is
standardization for this field. Each OUI implements its
values

The Kind field may be extended by the vendor to include zero
more octets of the Value(s) field

Simpson Informational [Page 2]

RFC 2153 PPP vendor extensions May 1997

Value(s

Zero or more octets. The details are implementation specific

2. Configuration

The Configuration Option format and basic options are already
for LCP [1].

Up-to-date values of the LCP Option Type field are specified in
most recent "Assigned Numbers" [2]. This document concerns
following values

0 Vendor-

2.1. Vendor-Specific

Some implementors might not need nor want to publish
proprietary algorithms and attributes. This mechanism
available to specify these without encumbering the IANA
proprietary number requests

Before accepting this option, the implementation must verify
the Organizationally Unique Identifier and Kind specify a
mechanism, and that any vendor specific negotiation values
fully understood

Rationale

This is defined as general feature of all PPP Control Protocols
to avoid future conflicts in vendor secretly self-assigned
numbers

A summary of the Vendor-Specific Configuration Option format is
below. The fields are transmitted from left to right

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
... | Kind | Value(s) ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-

Simpson Informational [Page 3]

RFC 2153 PPP vendor extensions May 1997

0

>= 6

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

three octets. The vendor's Organizationally Unique Identifier
The bits within the octet are in canonical order, and the
significant octet is transmitted first

one octet. Indicates a sub-type for the OUI. There is
standardization for this field. Each OUI implements its
values

The Kind field may be extended by the vendor to include zero
more octets of the Value(s) field

Value(s

Zero or more octets. The details are implementation specific

3. Organizationally Unique

The three-octet Organizationally Unique Identifier (OUI)
an organization that administers the meaning of the message.
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
Extensions should also register the OUI with IANA

In the alternative, a vendor that does not otherwise need an
assigned OUI can request a PPP specific OUI from IANA. This
shall be assigned from the 'CF0000' series. This has both
"locally-assigned" and "broadcast/multicast" bits set to 1; that is
the least significant two bits of the most significant octet are
set to 1.

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

Simpson Informational [Page 4]

RFC 2153 PPP vendor extensions May 1997

octets transmitted left-to-right

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
|

Rationale

This is defined for vendors that are not able to use
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
assigned OUI would have the multicast bit cleared to 0.

The 'CF0000' series was arbitrarily chosen to match the PPP
'CF', as a matter of mnemonic convenience

Security

Security issues are not discussed in this document

[1] Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
51, RFC 1661, DayDreamer, July 1994.

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

Simpson Informational [Page 5]

RFC 2153 PPP vendor extensions May 1997

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
Group of the Internet Engineering Task Force (IETF). The
group can be contacted via the current chair

Karl
Ascend
655 Metro Place South, Suite 379
Dublin, Ohio 43017

karl@Ascend.

Questions about this document can also be directed to

William Allen

Computer Systems Consulting
1384
Madison Heights, Michigan 48071

wsimpson@UMich.
wsimpson@GreenDragon.com (preferred

Simpson Informational [Page 6]

if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.

RFC documents can be found at I.E.T.F.

Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX