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

Document Type RFC - Proposed Standard (May 2004; No errata)
Last updated 2013-03-02
Stream IETF
Formats plain text pdf html
Stream WG state (None)
Consensus Unknown
Document shepherd No shepherd assigned
IESG IESG state RFC 3772 (Proposed Standard)
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
Show full document text