RFC2153
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]
Table of Contents
Simpson Informational [Page ii]
Contents
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
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.
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
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.
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 1|x x x x x x x x|x 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, RFC 1661, 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- [email protected] 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
[email protected]
Questions about this document can also be directed to:
William Allen Simpson DayDreamer Computer Systems Consulting Services 1384 Fontaine Madison Heights, Michigan 48071
[email protected] [email protected] (preferred)
