PPP Vendor Extensions
A standard way for vendors to add their own private packets and options to the Point-to-Point Protocol without asking IANA for numbers.
Simpson, W., "PPP Vendor Extensions", RFC 2153, DOI 10.17487/RFC2153, May 1997, <https://www.rfc-editor.org/info/rfc2153>.
@misc{rfc2153,
series = {Request for Comments},
number = 2153,
howpublished = {RFC 2153},
publisher = {RFC Editor},
doi = {10.17487/RFC2153},
url = {https://www.rfc-editor.org/info/rfc2153},
author = {W. Simpson},
title = {{PPP Vendor Extensions}},
pagetotal = 6,
year = 1997,
month = may,
} RFC text
Contents
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]
RFC 2153 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]
RFC 2153 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 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-
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)
ISO Plain Language
On this page
§1Vendor-Specific Control Packets
The Point-to-Point Protocol provides a standard method for carrying 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 memo defines a general mechanism for proprietary vendor extensions to those control protocols.
Some implementors may not need or want to publish their proprietary algorithms and attributes. The mechanism lets them specify these things without burdening IANA with requests for proprietary numbers. When the code field of an LCP or NCP packet is set to 0, the packet is vendor-specific: the sender fills in the identifier, inserts the local Magic-Number if there is one, sets the OUI and Kind fields, and puts any desired data in the value field.
Vendor-specific packets may be sent at any time, including before LCP has reached the Opened state. Each packet sent must use a fresh identifier. The receiver's response is up to the vendor, and the value field must not exceed the default maximum receive unit minus twelve.
Control messages that manage a PPP link can carry a special code, the number zero, meaning this message is private to a particular vendor. The sender says who it is and what kind of private message this is, and the rest of the message holds whatever that vendor defines.
§2Organizationally Unique Identifiers
The three-octet Organizationally Unique Identifier (OUI) identifies the organization that administers the meaning of the message, and it is based on IEEE 802 vendor assignments. A vendor that wants to use its existing IEEE 802 OUI for PPP vendor extensions should also register that OUI with IANA. A vendor that does not otherwise need an IEEE-assigned number can instead request a PPP-specific OUI from IANA, assigned from the CF0000 series.
That CF0000 series has both the locally assigned and the broadcast or multicast bits set to one, that is, the least significant two bits of the most significant octet are both one. The choice of CF0000 is a mnemonic convenience, chosen to match the PPP NLPID CF. The reasoning is that multicast has no meaning in PPP, so an IEEE-assigned OUI would have the multicast bit cleared, making a set multicast bit a clear mark of a locally assigned value. The RFC also notes that it is not clear how IEEE assigns blocks and that the locally assigned bit is known to have been used in some cases.
Inside the packet, the OUI's bits are in canonical order and the most significant octet is transmitted first.
Each vendor is named by a three-byte identifier that normally comes from the IEEE, the same kind of identifier used for hardware addresses. A vendor with no such number can get one from IANA instead, from a range whose first byte marks it as locally assigned. The bytes are sent most significant first.
§3Packet Layout and Configuration Options
The vendor-specific packet begins with the usual Code, Identifier and Length fields of a control packet. The Length must be at least twelve, and when it is exactly twelve there is no value field. The Magic-Number is four octets and helps detect links that are looped back; until the Magic-Number Configuration Option has been successfully negotiated it must be transmitted as zero. The OUI is three octets and the Kind is one octet, and the Kind field may be extended by the vendor using zero or more octets of the value field. The value field is zero or more octets whose details are implementation specific.
The same idea applies to configuration options. The Option Type field value 0 marks a vendor-specific option, whose Length must be at least six, with no value field when the length is exactly six. Before accepting such an option an implementation must verify that the OUI and Kind specify a known mechanism and that any vendor-specific negotiation values are fully understood. Both mechanisms exist to avoid conflicts from vendors secretly assigning their own packet codes and option types.
The Kind field is what gives each vendor room to grow: because a vendor controls its own OUI, it can define as many kinds and as much value data as it needs, and the number zero in the standard fields keeps that private space from colliding with future standard extensions.
Each message starts with the normal PPP fields and then carries the vendor's identifier, a single byte saying which of that vendor's message types this is, and any data the vendor wants. The same pattern is used for link setup options, and a device must not accept an option unless it recognizes the vendor and the sub-type and understands the values.
| Field | Name | Size | Value | Description |
|---|---|---|---|---|
CODE | Code | 1 byte | 0 | 0 marks the packet as vendor specific. |
IDENTIFIER | Identifier | 1 byte | A new value for each packet sent. | |
LENGTH | Length | 2 bytes | 12 | At least 12; 12 means no value data. |
MAGIC | Magic-Number | 4 bytes | Loopback detection; zero until negotiated. | |
OUI | OUI | 3 bytes | The vendor's Organizationally Unique Identifier. | |
KIND | Kind | 1 byte | Vendor-defined sub-type. |
§4Security Considerations
The RFC states plainly that security issues are not discussed in this document. That brevity is worth noting rather than glossing over. The mechanism hands control of message meaning to each vendor, so the safeguards are the receiving implementation's own: it must confirm that an OUI and Kind identify a mechanism it knows and that the negotiation values are fully understood before acting on them. Because vendor-specific packets may arrive before LCP reaches the Opened state and may be sent at any time, a device must be prepared for them from either peer.
The document is a small extension to existing protocols rather than a standalone security protocol. It updates RFC 1661, the PPP specification, and RFC 1962, the compression control protocol, by adding this vendor-specific facility to their control packets and configuration options.
The memo says nothing about security, which means the work of staying safe falls on the device itself: it should only act on vendor messages it recognizes and understands. The change itself just adds a private slot to rules that already existed.