IT. Expert System.

RFC (informational status)

PPP Vendor Extensions. W. Simpson. May 1997. RFC2153. (Format: TXT=10780 bytes) (Updates RFC1661, RFC1962) (Updated by RFC5342, RFC7042) (Status: INFORMATIONAL) (DOI: 10.17487 / RFC2153)


 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
      significant octet is transmitted first.
   Kind
      one octet.  Indicates a sub-type for the OUI.  There is no
      standardization for this field.  Each OUI implements its own
      values.
      The Kind field may be extended by the vendor to include zero or
      more octets of the Value(s) field.
Simpson                      Informational                      [Page 2]

RFC 2153                 PPP vendor extensions                  May 1997
   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
   following values:
       0      Vendor-Specific
2.1.  Vendor-Specific Option
   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.
      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                      Informational                      [Page 3]

RFC 2153                 PPP vendor extensions                  May 1997
   Type
       0
   Length
      >= 6
      When the Length is six, no Value(s) field is present.
   OUI
      three octets.  The vendor's Organizationally Unique Identifier.
      The bits within the octet are in canonical order, and the most
      significant octet is transmitted first.
   Kind
      one octet.  Indicates a sub-type for the OUI.  There is no
      standardization for this field.  Each OUI implements its own
      values.
      The Kind field may be extended by the vendor to include zero or
      more octets of the Value(s) field.
   Value(s)
      Zero or more octets.  The details are implementation specific.
3.  Organizationally Unique Identifiers
   The three-octet Organizationally Unique Identifier (OUI) identifies
   an organization that administers the meaning of the message.  This
   OUI is based on IEEE 802 vendor assignments.
   IEEE contact details for assignment of an OUI are given in [RFC-
   1700].  Vendors that desire to use their IEEE 802 OUI for PPP Vendor
   Extensions should also register the OUI with IANA.
   In the alternative, a vendor that does not otherwise need an IEEE
   assigned OUI can request a PPP specific OUI from IANA.  This OUI
   shall be assigned from the 'CF0000' series.  This has both the
   "locally-assigned" and "broadcast/multicast" bits set to 1; that is,
   the least significant two bits of the most significant octet are both
   set to 1.
   Appearance in memory, bits transmitted right-to-left within octets,
Simpson                      Informational                      [Page 4]

RFC 2153                 PPP vendor extensions                  May 1997
   octets transmitted left-to-right:
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                | |
                | Multicast
                Local
   Rationale:
      This is defined for vendors that are not able to use IEEE
      assignments, such as software-only vendors.
      It is not clear how the IEEE assigns blocks.  In some instances,
      the "locally-assigned" bit is known to have been used.
      However, multicast has no meaning in PPP.  Therefore, an IEEE
      assigned OUI would have the multicast bit cleared to 0.
      The 'CF0000' series was arbitrarily chosen to match the PPP NLPID
      'CF', as a matter of mnemonic convenience.
Security Considerations
   Security issues are not discussed in this document.
References
   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
         51, RFC 1661, DayDreamer, July 1994.
   [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,
         July 1992.
Simpson                      Informational                      [Page 5]

RFC 2153                 PPP vendor extensions                  May 1997
Contacts
   Comments about this document should be discussed on the ietf-
   ppp@merit.edu mailing list.
   This document was reviewed by 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
      Ascend Communications
      655 Metro Place South, Suite 379
      Dublin, Ohio  43017
          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                      Informational                      [Page 6] 


Content

Android Reference

Java basics

Java Enterprise Edition (EE)

Java Standard Edition (SE)

SQL

HTML

PHP

CSS

Java Script

MYSQL

JQUERY

VBS

REGEX

C

C++

C#

Design patterns

RFC (standard status)

RFC (proposed standard status)

RFC (draft standard status)

RFC (informational status)

RFC (experimental status)

RFC (best current practice status)

RFC (historic status)

RFC (unknown status)

IT dictionary

License.
All information of this service is derived from the free sources and is provided solely in the form of quotations. This service provides information and interfaces solely for the familiarization (not ownership) and under the "as is" condition.
Copyright 2016 © ELTASK.COM. All rights reserved.
Site is optimized for mobile devices.
Downloads: 240 / 159176744. Delta: 0.03302 с