[Docs] [txt|pdf] [Tracker] [WG] [Email] [Nits]

Versions: 00 RFC 2153

Network Working Group                                         W. Simpson
Internet Draft                                                DayDreamer
expires in six months                                          June 1996


                         PPP Vendor Extensions
                    draft-ietf-pppext-vendor-00.txt


Status of this Memo

   Distribution of this memo is unlimited.

   This document is an Internet-Draft.  Internet Drafts are working doc-
   uments of the Internet Engineering Task Force (IETF), its Areas, and
   its Working Groups.  Note that other groups may also distribute work-
   ing documents as Internet Drafts.

   Internet Drafts are draft documents valid for a maximum of six
   months, and may be updated, replaced, or obsoleted by other documents
   at any time.  It is not appropriate to use Internet Drafts as refer-
   ence material, or to cite them other than as a ``working draft'' or
   ``work in progress.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the internet-drafts Shadow
   Directories on:

      ftp.is.co.za (Africa)
      nic.nordu.net (Europe)
      ds.internic.net (US East Coast)
      ftp.isi.edu (US West Coast)
      munnari.oz.au (Pacific Rim)


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                   expires in six months                 [Page i]

DRAFT                     PPP vendor extensions                June 1996


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 propri-
      etary 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                   expires in six months                 [Page 1]

DRAFT                     PPP vendor extensions                June 1996


   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     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 Configu-
      ration Option for further explanation.

   OUI

      three octets.  The vendor's Organizationally Unique Identifier,
      assigned by IEEE 802 (see [RFC-1700] for contact details).  The
      bits within the octet are in canonical order, and the most signif-
      icant octet is transmitted first.

   Kind

      one octet.  Indicates a sub-type for the OUI.  There is no stan-
      dardization for this field.  Each OUI implements its own values.







Simpson                   expires in six months                 [Page 2]

DRAFT                     PPP vendor extensions                June 1996


   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 fol-
   lowing values:

       0      Vendor-Specific



2.1.  Vendor-Specific Option

   Description

      Some implementors might not need nor want to publish their propri-
      etary 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) ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-





Simpson                   expires in six months                 [Page 3]

DRAFT                     PPP vendor extensions                June 1996


   Type

       0

   Length

      >= 6

      When the Length is six, no Value(s) field is present.

   OUI

      three octets.  The vendor's Organizationally Unique Identifier,
      assigned by IEEE 802 (see [RFC-1700] for contact details).  The
      bits within the octet are in canonical order, and the most signif-
      icant octet is transmitted first.

   Kind

      one octet.  Indicates a sub-type for the OUI.  There is no stan-
      dardization for this field.  Each OUI implements its own values.

   Value(s)

      Zero or more octets.  The details are implementation specific.


Security Considerations

   Security issues are not discussed in this document.


References

   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)",
         RFC-1661, December 1993.

   [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,
         July 1992.












Simpson                   expires in six months                 [Page 4]

DRAFT                     PPP vendor extensions                June 1996


Contacts

   Comments about this document should be discussed on the ietf-
   ppp@merit.edu mailing list.

   This document is a submission to 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
      Morning Star Technologies
      3518 Riverside Drive  Suite 101
      Columbus, Ohio  43221

          karl@MorningStar.com
          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)























Simpson                   expires in six months                 [Page 5]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/