1 files changed, 459 insertions, 0 deletions
diff --git a/doc/rfc/rfc2153.txt b/doc/rfc/rfc2153.txt
new file mode 100644
index 0000000..1439e89
--- /dev/null
+++ b/doc/rfc/rfc2153.txt
@@ -0,0 +1,459 @@
+
+
+
+
+
+
+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]
+