Point-to-Point Protocol (PPP) Vendor Protocol
RFC 3772

Document Type RFC - Proposed Standard (May 2004; No errata)
Authors James Carlson  , Richard Winslow 
Last updated 2013-03-02
Stream IETF
Formats plain text html pdf htmlized bibtex
Stream WG state (None)
Document shepherd No shepherd assigned
IESG IESG state RFC 3772 (Proposed Standard)
Consensus Boilerplate Unknown
Telechat date
Responsible AD Thomas Narten
Send notices to (None)
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.


   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

Carlson & Winslow           Standards Track                     [Page 1]
RFC 3772                  PPP Vendor Protocol                   May 2004

   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

   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",
   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.

Carlson & Winslow           Standards Track                     [Page 2]
RFC 3772                  PPP Vendor Protocol                   May 2004

   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
Show full document text