Point-to-Point Protocol (PPP) Vendor Protocol
Four reserved PPP protocol numbers that let vendors run their own network, control and authentication protocols.
Carlson, J. and R. Winslow, "Point-to-Point Protocol (PPP) Vendor Protocol", RFC 3772, DOI 10.17487/RFC3772, May 2004, <https://www.rfc-editor.org/info/rfc3772>.
@misc{rfc3772,
series = {Request for Comments},
number = 3772,
howpublished = {RFC 3772},
publisher = {RFC Editor},
doi = {10.17487/RFC3772},
url = {https://www.rfc-editor.org/info/rfc3772},
author = {J. Carlson and R. Winslow},
title = {{Point-to-Point Protocol (PPP) Vendor Protocol}},
pagetotal = 10,
year = 2004,
month = may,
} RFC text
Contents
Network Working Group J. Carlson
Request for Comments: 3772 Sun Microsystems
Category: Standards Track R. Winslow
L-3 Communications
May 2004
Point-to-Point Protocol (PPP) Vendor Protocol
Status of this Memo
This document specifies an Internet standards track protocol for the
Internet community, and requests discussion and suggestions for
improvements. Please refer to the current edition of the "Internet
Official Protocol Standards" (STD 1) for the standardization state
and status of this protocol. Distribution of this memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004). All Rights Reserved.
Abstract
The Point-to-Point Protocol (PPP) defines a Link Control Protocol
(LCP) and a method for negotiating the use of multi-protocol traffic
over point-to-point links. The PPP Vendor Extensions document adds
vendor-specific general-purpose Configuration Option and Code
numbers. This document extends these features to cover vendor-
specific Network, Authentication, and Control Protocols.
1. Introduction
PPP's [1] Vendor Extensions [3] defines a general-purpose mechanism
for the negotiation of various vendor-proprietary options and
extensions to the kinds of control messages that may be sent via the
Code field.
Some implementors may want to define proprietary network and control
protocols in addition to the already-described features. While it
would be possible for such an implementor to use the existing LCP
Vendor-Specific Option to enable the use of the proprietary protocol,
this staged negotiation (enable via LCP, then negotiate via some
locally-assigned protocol number) suffers from at least three
problems:
First, because it would be in LCP, the negotiation of the use of the
protocol would begin before identification and authentication of the
peer had been done. This complicates the security analysis of the
feature and constrains the way in which the protocol might be
deployed.
Second, where compulsory tunneling is in use, the system performing
the initial LCP negotiation may be unrelated to the system that uses
the proprietary protocol. In such a scenario, enabling the protocol
at LCP time would require either LCP renegotiation or support of the
proprietary protocol in the initial negotiator, both of which raise
deployment problems.
Third, the fact that any protocol negotiated via such a mechanism
would necessarily use a protocol number that is not assigned by IANA
complicates matters for diagnostic tools used to monitor the
datastream. Having a fixed number allows these tools to display such
protocols in a reasonable, albeit limited, format.
A cleaner solution is thus to define a set of vendor-specific
protocols, one in each of the four protocol number ranges defined by
[1]. This specification reserves the following values:
Value (in hex) Protocol Name
005b Vendor-Specific Network Protocol (VSNP)
405b Vendor-Specific Protocol (VSP)
805b Vendor-Specific Network Control Protocol (VSNCP)
c05b Vendor-Specific Authentication Protocol (VSAP)
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in BCP 14, RFC 2119 [2].
2. PPP Vendor-Specific Network Control Protocol (VSNCP)
The Vendor-Specific Network Control Protocol (VSNCP) is responsible
for negotiating the use of the Vendor-Specific Network Protocol
(VSNP). VSNCP uses the same packet exchange and option negotiation
mechanism as LCP, but with a different set of options.
VSNCP packets MUST NOT be exchanged until PPP has reached the
Network-Layer Protocol phase. Any VSNCP packets received when not in
that phase MUST be silently ignored. If a VSNCP packet with an
unrecognized OUI is received, an LCP Protocol-Reject SHOULD be sent
in response.
The network layer data, carried in VSNP packets, MUST NOT be sent
unless VSNCP is in Opened state. If a VSNP packet is received when
VSNCP is not in Opened state and LCP is Opened, the implementation
MAY respond using LCP Protocol-Reject.
2.1. VSNCP Packet Format
Exactly one VSNCP packet is carried in the PPP Information field,
with the PPP Protocol field set to hex 805b (VSNCP). A summary of
the VSNCP packet format is shown below. The fields are transmitted
from left to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code
Only LCP Code values 1 through 7 (Configure-Request, Configure-
Ack, Configure-Nak, Configure-Reject, Terminate-Request,
Terminate-Ack, and Code-Reject) are used. All other codes SHOULD
result in a VSNCP Code-Reject reply.
Identifier and Length
These are as documented for LCP.
OUI
This three-octet field contains the vendor's Organizationally
Unique Identifier. The bits within the octet are in canonical
order, and the most significant octet is transmitted first. See
Section 5 below for more information on OUI values.
Data
This field contains data in the same format as for the
corresponding LCP Code numbers.
2.2. VSNP Packet Format
When VSNCP is in Opened state, VSNP packets may be sent by setting
the PPP Protocol field to hex 005b (VSNP) and placing the vendor-
specific data in the PPP Information field. No restrictions are
placed on this data.
3. PPP Vendor-Specific Protocol (VSP)
The Vendor-Specific Protocol (VSP) is intended for use in situations
where the implementation of a complete Network Layer Protocol is
unnecessary, or where per-link signaling is required (see Section 7
below).
VSP packets MUST NOT be sent until PPP has reached either Network-
Layer Protocol or Authentication phase. VSP packets received before
those phases MUST be silently ignored. Once the proper phase has
been reached, a VSP packet containing an unrecognized OUI value
SHOULD be returned using LCP Protocol-Reject.
Exactly one VSP packet is carried in the PPP Information field, with
the PPP Protocol field set to 405b (VSP). A summary of the VSP
packet format is shown below. The fields are transmitted from left
to right.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Magic-Number |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Reserved |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+
Magic-Number
The four-octet Magic-Number field is used to detect looped-back
links. If the Magic-Number Option was not negotiated by LCP, then
this field MUST be set to 0. Implementation of the LCP Magic-
Number Option is RECOMMENDED.
OUI
This three-octet field contains the vendor's Organizationally
Unique Identifier. The bits within the octet are in canonical
order, and the most significant octet is transmitted first. See
Section 5 below for more information on OUI values.
Reserved
Reserved for future definition. Must be zero on transmit and
ignored on reception.
Data
Vendor-specific data.
4. PPP Vendor-Specific Authentication Protocol (VSAP)
The Vendor-Specific Authentication Protocol (VSAP) is used in two
ways. First, it is used with the LCP Authentication Option in order
to negotiate the use of a vendor-specific authentication protocol to
be used during the PPP Authentication phase. Second, it is used in
the PPP Protocol field to carry those proprietary authentication
messages during the PPP Authentication phase.
4.1. VSAP Authentication Option Format
This option is used in LCP Configure-Request, -Ack, -Nak, and -Reject
messages.
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Length | Authentication-Protocol |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OUI | Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Type
3
Length
>=7
Authentication-Protocol
The hex value c05b, in Network Byte Order.
OUI
This three-octet field contains the vendor's Organizationally
Unique Identifier. The bits within the octet are in canonical
order, and the most significant octet is transmitted first. See
Section 5 below for more information on OUI values.
Data
This optional field contains options or other information specific
to the operation of the vendor-specific authentication protocol.
4.2. VSAP Authentication Data Format
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | Identifier | Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Data ...
+-+-+-+-+
The Identifier and Length fields are as for LCP. The Code and Data
fields and the processing of the messages are defined by the vendor-
specific protocol.
However, it is RECOMMENDED that vendor-specific protocols use Code 3
for "Success" and Code 4 for "Failure," as with [4] and [5], in order
to simplify the design of network monitoring equipment.
5. Organizationally Unique Identifiers
The three-octet Organizationally Unique Identifier (OUI) used in the
messages described in this document identifies an organization
("vendor") that defines the meaning of the message. This OUI is
based on IEEE 802 vendor assignments.
Vendors that desire to use their IEEE 802 OUI for a PPP Vendor
Protocol SHOULD also register the assigned OUI with IANA for the
benefit of the community.
A vendor that does not otherwise need an IEEE-assigned OUI can
request a PPP-specific OUI from the IANA. This OUI shall be assigned
from the CF0000 series. This procedure is defined for vendors that
are not able to use IEEE assignments, such as software-only vendors.
6. Multiple Vendor-Specific Protocols
Vendors are encouraged to define their protocols to allow for future
expansion, where necessary. For example, it may be appropriate for a
VSNP to include a locally-defined selector field to distinguish among
multiple proprietary protocols carried via this mechanism, and
appropriate Configuration Options in VSNCP to enable and disable
these sub-protocols. Because the requirements of such a selector are
known only to the vendor defining such protocols, they are not
described further in this document.
An implementation MAY also support more than one vendor-specific
protocol, distinguished by OUI. In this case, the implementation
MUST also treat LCP Protocol-Reject specially by examining the OUI
field in the rejected message and disabling only the protocol to
which it refers, rather than all use of the vendor-specific protocol
number. Note that such an implementation is compatible with a simple
implementation that supports only one OUI: that implementation will
respond with LCP Protocol-Reject for unrecognized OUIs and otherwise
leave the negotiation state unmodified.
An OUI-distinguished mechanism is expected to be used only in the
case of cooperating vendors. Vendors are encouraged to use just a
single OUI for all protocols defined by that vendor, if possible.
7. Multilink, Compression, and Encryption Considerations
The Vendor-Specific Network Protocol (VSNP) is defined to operate at
the bundle level if Multilink PPP [6] is in use, and also above any
Compression Protocols [7] and Encryption Protocols [8] in use.
The Vendor-Specific Protocol (VSP) is defined to operate at the per-
link level if Multilink PPP is in use, and MUST NOT be subjected to
data compression. If a per-link encryption protocol is in use, then
VSP packets MUST be encrypted.
Note that because VSP is defined at the per-link level, bundle level
encryption does not affect VSP.
8. Security Considerations
The security of any vendor-specific authentication protocol is
subject to the provisions of that proprietary mechanism.
Implementations that wish to avoid security problems associated with
such protocols SHOULD send LCP Configure-Nak in response to an LCP
Configure-Request specifying VSAP, or MAY terminate operation.
When operating with PPP encryption, but without Multilink PPP, VSP
packets are sent in the clear. Implementations that require PPP
encryption as part of a security mechanism should consider whether to
employ per-link encryption or forego use of VSP in favor of VSNP.
The security of vendor-specific networking protocols is likewise
subject to the security mechanisms defined by those protocols.
Independent analysis of the security of any such protocol is
RECOMMENDED.
9. IANA Considerations
IANA has assigned four similarly-numbered PPP Protocol field values,
005b, 405b, 805b, and c05b, as described in Section 1 of this
document.
As described in Section 5 above and in [3], the IANA also maintains a
CF0000 series block of non-IEEE OUIs that may be allocated for
vendors that do not otherwise need an IEEE-assigned OUI.
10. References
10.1. Normative References
[1] Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994.
[2] Bradner, S., "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
10.2. Informative References
[3] Simpson, W., "PPP Vendor Extensions", RFC 2153, May 1997.
[4] Simpson, W., "PPP Challenge Handshake Authentication Protocol
(CHAP)", RFC 1994, August 1996.
[5] Blunk, L. and J. Vollbrecht, "PPP Extensible Authentication
Protocol (EAP)", RFC 2284, March 1998.
[6] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T. Coradetti,
"The PPP Multilink Protocol (MP)", RFC 1990, August 1996.
[7] Rand, D., "The PPP Compression Control Protocol (CCP)", RFC
1962, June 1996.
[8] Meyer, G., "The PPP Encryption Control Protocol (ECP)", RFC
1968, June 1996.
11. Acknowledgments
The authors thank Karl Fox and Thomas Narten for their comments and
help in preparing this document.
Some of the language and phrasing has been borrowed from RFC 1332,
written by Glenn McGregor, and RFC 2153, written by William Allen
Simpson.
12. Authors
Questions about this document should be addressed to the IETF pppext
working group or the authors listed below.
James Carlson
Sun Microsystems
1 Network Drive MS UBUR02-212
Burlington MA 01803-2757
Phone: +1 781 442 2084
Fax: +1 781 442 1677
EMail: james.d.carlson@sun.com
Richard Winslow
L-3 Communications Systems - East
1 Federal Street A&E-2NE
Camden, NJ 08102
EMail: richard.winslow@l-3com.com
13. Full Copyright Statement
Copyright (C) The Internet Society (2004). This document is subject
to the rights, licenses and restrictions contained in BCP 78, and
except as set forth therein, the authors retain all their rights.
This document and the information contained herein are provided on an
"AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
Intellectual Property
The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights
might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79.
Copies of IPR disclosures made to the IETF Secretariat and any
assurances of licenses to be made available, or the result of an
attempt made to obtain a general license or permission for the use of
such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at ietf-
ipr@ietf.org.
Acknowledgement
Funding for the RFC Editor function is currently provided by the
Internet Society.
AI ELI5
On this page
§1Why Vendor Protocols Need Their Own Numbers
The PPP Vendor Extensions already let vendors add proprietary options and Code values to the Link Control Protocol (LCP). Some implementors also want whole proprietary network and control protocols. They could enable such a protocol with the LCP Vendor-Specific Option and then negotiate it using a locally assigned protocol number, but the RFC names three problems with that staged approach.
- LCP negotiation happens before the peer has been identified and authenticated, which complicates the security analysis.
- With compulsory tunneling, the system doing the first LCP negotiation may be unrelated to the system that uses the proprietary protocol.
- A protocol number not assigned by IANA makes life harder for diagnostic tools, which can show a fixed number in a reasonable, if limited, format.
Before, a company had to sneak its secret game rules in before anyone showed ID, and nobody could tell what the game was called. Now there are official, labelled slots.
§2Four Reserved Protocol Numbers
The cleaner solution is a set of vendor-specific protocols, one in each of the four protocol number ranges defined by RFC 1661. The RFC reserves these values.
005b: Vendor-Specific Network Protocol (VSNP)405b: Vendor-Specific Protocol (VSP)805b: Vendor-Specific Network Control Protocol (VSNCP)c05b: Vendor-Specific Authentication Protocol (VSAP)
Each message carries a three-octet OUI, the Organizationally Unique Identifier of the vendor that defines the meaning of the message. A vendor's own data follows the OUI, and the RFC places no restrictions on it for VSNP.
There are four numbered slots, each for a different kind of job. Every note put in a slot has the company's name on it.
- 005bVSNP — Vendor-Specific Network Protocol
- 405bVSP — Vendor-Specific Protocol
- 805bVSNCP — Vendor-Specific Network Control Protocol
- c05bVSAP — Vendor-Specific Authentication Protocol
§3VSNCP and VSNP: Vendor Network Layer
VSNCP negotiates the use of VSNP. It uses the same packet exchange and option negotiation mechanism as LCP, but with a different set of options. Exactly one VSNCP packet is carried in the PPP Information field, with the PPP Protocol field set to hex 805b.
The packet has Code, Identifier, Length, a three-octet OUI and Data. Only LCP Code values 1 through 7 are used (Configure-Request, Configure-Ack, Configure-Nak, Configure-Reject, Terminate-Request, Terminate-Ack and Code-Reject); all other codes SHOULD result in a VSNCP Code-Reject reply.
VSNCP packets MUST NOT be exchanged until PPP has reached the Network-Layer Protocol phase, and ones received earlier MUST be silently ignored. An unrecognized OUI SHOULD draw an LCP Protocol-Reject. VSNP packets, with Protocol field 005b, MUST NOT be sent unless VSNCP is in the Opened state.
First the two sides agree, politely, that they will use a company's special language. Only after they both say yes do they start sending messages in it.
§4VSP: Per-Link Vendor Messages
The Vendor-Specific Protocol (VSP) is meant for cases where a full network layer protocol is unnecessary, or where per-link signaling is required. It uses Protocol field value 405b and carries exactly one packet in the Information field.
The packet holds a four-octet Magic-Number, a three-octet OUI, a one-octet Reserved field and Data. The Magic-Number detects looped-back links; if the LCP Magic-Number Option was not negotiated, it MUST be set to 0, and implementing that option is RECOMMENDED. Reserved MUST be zero on transmit and is ignored on reception.
VSP packets MUST NOT be sent until PPP has reached the Network-Layer Protocol or Authentication phase, and earlier arrivals MUST be silently ignored. After that, a VSP packet with an unrecognized OUI SHOULD be returned using LCP Protocol-Reject.
VSP is a quick note passed along one single road, with no big agreement needed first. The note carries a tag so the sender can tell if their own note came right back.
§5VSAP: Vendor Authentication
The Vendor-Specific Authentication Protocol (VSAP) is used in two ways. First, an LCP Authentication Option negotiates a vendor-specific authentication protocol for the Authentication phase. Second, VSAP packets carry the proprietary authentication messages during that phase.
The option appears in LCP Configure-Request, -Ack, -Nak and -Reject. Its Type is 3, its Length is 7 or more, and the Authentication-Protocol field is hex c05b in network byte order, followed by the OUI and optional Data.
The authentication data has Code, Identifier, Length and Data. The vendor defines Code, Data and the processing. The RFC does RECOMMEND Code 3 for Success and Code 4 for Failure, as with CHAP (RFC 1994) and EAP (RFC 2284), to simplify network monitoring equipment.
Some companies have their own secret handshake to prove who you are. This lets them use it, and suggests the same words for yes and no that other handshakes use.
§6OUIs and Multiple Vendors
The OUI is based on IEEE 802 vendor assignments. Vendors using their IEEE OUI SHOULD also register it with IANA. A vendor without an IEEE OUI, such as a software-only vendor, can request a PPP-specific OUI from IANA, assigned from the CF0000 series.
An implementation MAY support more than one vendor protocol, told apart by OUI. It MUST then handle LCP Protocol-Reject specially, reading the OUI in the rejected message and disabling only that protocol, not all use of the vendor number. This stays compatible with simple implementations that support one OUI. The mechanism is expected only for cooperating vendors, and vendors are encouraged to use a single OUI for all their protocols.
The company name tag comes from an official list. If a company has no tag yet, it can ask for one from a special set.
§7Multilink, Compression and Encryption
VSNP operates at the bundle level if Multilink PPP is in use, and above any compression and encryption protocols in use.
VSP operates at the per-link level under Multilink PPP and MUST NOT be subjected to data compression. If a per-link encryption protocol is in use, VSP packets MUST be encrypted. Because VSP is per-link, bundle-level encryption does not affect it.
One kind of message travels with the whole group of roads, and the other travels on just one road, so they get treated differently.
§8Security Considerations
The security of a vendor authentication protocol depends on that proprietary mechanism. An implementation wanting to avoid such problems SHOULD send LCP Configure-Nak in response to a Configure-Request specifying VSAP, or MAY terminate operation.
When PPP encryption is used without Multilink PPP, VSP packets are sent in the clear. Implementations that need PPP encryption for security should consider per-link encryption or using VSNP instead of VSP. Vendor networking protocols are also only as secure as their own mechanisms, and independent analysis is RECOMMENDED.
VSP can travel unencrypted when only PPP encryption (without Multilink PPP) is in use.
A secret handshake is only as safe as the company that made it up, so you can politely say no thanks. And one kind of note may not be locked up, so check first.