GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc: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
 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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc2153.txt · Last modified: 1997/05/31 00:25 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki