datatracker.ietf.org
Sign in
Version 5.7.1.p2, 2014-10-29
Report a bug

PPP Vendor Extensions
RFC 2153

Document type: RFC - Informational (May 1997; No errata)
Updated by RFC 5342, RFC 7042
Document stream: IETF
Last updated: 2013-03-02
Other versions: plain text, pdf, html

IETF State: (None)
Document shepherd: No shepherd assigned

IESG State: RFC 2153 (Informational)
Responsible AD: (None)
Send notices to: No addresses provided

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.

Simpson                      Informational                      [Page 1]
RFC 2153                 PPP vendor extensions                  May 1997

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     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

[include full document text]