home *** CD-ROM | disk | FTP | other *** search
/ The Hacker's Encyclopedia 1998 / hackers_encyclopedia.iso / rfc / 3 / rfc2153.txt < prev    next >
Encoding:
Text File  |  2003-06-11  |  10.5 KB  |  460 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         W. Simpson
  8. Request for Comments: 2153                                    DayDreamer
  9. Updates: RFCs 1661, 1962                                        May 1997
  10. Category: Informational
  11.  
  12.  
  13.                          PPP Vendor Extensions
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document provides information for the Internet community.  It
  19.    does not specify an Internet standard of any kind.  Distribution of
  20.    this memo is unlimited.
  21.  
  22. Abstract
  23.  
  24.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  25.    transporting multi-protocol datagrams over point-to-point links.  PPP
  26.    defines an extensible Link Control Protocol (LCP) for establishing,
  27.    configuring, and testing the data-link connection; and a family of
  28.    Network Control Protocols (NCPs) for establishing and configuring
  29.    different network-layer protocols.
  30.  
  31.    This document defines a general mechanism for proprietary vendor
  32.    extensions.
  33.  
  34.  
  35.  
  36.  
  37.  
  38.  
  39.  
  40.  
  41.  
  42.  
  43.  
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. Simpson                      Informational                      [Page i]
  59.  
  60.  
  61.  
  62.  
  63.  
  64. RFC 2153                 PPP vendor extensions                  May 1997
  65.  
  66.  
  67.                            Table of Contents
  68.  
  69.  
  70.  
  71.      1.     Control Packets .......................................    1
  72.         1.1       Vendor Specific Packet ..........................    1
  73.  
  74.      2.     Configuration Options .................................    3
  75.         2.1       Vendor-Specific Option ..........................    3
  76.  
  77.      3.     Organizationally Unique Identifiers ...................    4
  78.  
  79.      SECURITY CONSIDERATIONS ......................................    5
  80.  
  81.      REFERENCES ...................................................    5
  82.  
  83.      CONTACTS .....................................................    6
  84.  
  85.  
  86.  
  87.  
  88.  
  89.  
  90.  
  91.  
  92.  
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99.  
  100.  
  101.  
  102.  
  103.  
  104.  
  105.  
  106.  
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114.  
  115.  
  116.  
  117.  
  118. Simpson                      Informational                     [Page ii]
  119.  
  120.  
  121.  
  122.  
  123.  
  124. RFC 2153                 PPP vendor extensions                  May 1997
  125.  
  126.  
  127. 1.  Control Packets
  128.  
  129.    The Packet format and basic facilities are already defined for LCP
  130.    [1] and related NCPs.
  131.  
  132.    Up-to-date values of the LCP Code field are specified in the most
  133.    recent "Assigned Numbers" [2].  This document concerns the following
  134.    values:
  135.  
  136.        0      Vendor Specific
  137.  
  138.  
  139.  
  140. 1.1.  Vendor Specific Packet
  141.  
  142.    Description
  143.  
  144.       Some implementors might not need nor want to publish their
  145.       proprietary algorithms and attributes.  This mechanism is
  146.       available to specify these without encumbering the IANA with
  147.       proprietary number requests.
  148.  
  149.       Vendor Specific packets MAY be sent at any time, including before
  150.       LCP has reached the Opened state.
  151.  
  152.       The sender transmits a LCP or NCP packet with the Code field set
  153.       to 0 (Vendor Specific), the Identifier field set, the local
  154.       Magic-Number (if any) inserted, the OUI and Kind fields set, and
  155.       the Value(s) field filled with any desired data, but not exceeding
  156.       the default MRU minus twelve.
  157.  
  158.       Receipt of a Vendor Specific packet causes the RXR or RUC event.
  159.       The response to the Vendor Specific packet is vender specific.
  160.  
  161.       Receipt of a Code-Reject for the packet SHOULD generate the RXJ+
  162.       (permitted) event.
  163.  
  164.    Rationale:
  165.  
  166.       This is defined as general feature of all PPP Control Protocols,
  167.       to avoid future conflicts in vendor secretly self-assigned Code
  168.       numbers.
  169.  
  170.    A summary of the Vendor Specific packet format is shown below.  The
  171.    fields are transmitted from left to right.
  172.  
  173.  
  174.  
  175.  
  176.  
  177.  
  178. Simpson                      Informational                      [Page 1]
  179.  
  180. RFC 2153                 PPP vendor extensions                  May 1997
  181.  
  182.  
  183.  
  184.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  185.    |     Code      |  Identifier   |            Length             |
  186.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  187.    |                         Magic-Number                          |
  188.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  189.    |                      OUI                      |     Kind      |
  190.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  191.    |    Value(s) ...
  192.    +-+-+-+-+-+-+-+-+
  193.  
  194.    Code
  195.  
  196.        0 for Vendor Specific
  197.  
  198.    Identifier
  199.  
  200.       The Identifier field MUST be changed for each Vendor Specific
  201.       packet sent.
  202.  
  203.    Length
  204.  
  205.       >= 12
  206.  
  207.       When the Length is twelve, no Value(s) field is present.
  208.  
  209.    Magic-Number
  210.  
  211.       The Magic-Number field is four octets and aids in detecting links
  212.       that are in the looped-back condition.  Until the Magic-Number
  213.       Configuration Option has been successfully negotiated, the Magic-
  214.       Number MUST be transmitted as zero.  See the Magic-Number
  215.       Configuration Option for further explanation.
  216.  
  217.    OUI
  218.  
  219.       three octets.  The vendor's Organizationally Unique Identifier.
  220.       The bits within the octet are in canonical order, and the most
  221.       significant octet is transmitted first.
  222.  
  223.    Kind
  224.  
  225.       one octet.  Indicates a sub-type for the OUI.  There is no
  226.       standardization for this field.  Each OUI implements its own
  227.       values.
  228.  
  229.       The Kind field may be extended by the vendor to include zero or
  230.       more octets of the Value(s) field.
  231.  
  232.  
  233.  
  234. Simpson                      Informational                      [Page 2]
  235.  
  236. RFC 2153                 PPP vendor extensions                  May 1997
  237.  
  238.  
  239.    Value(s)
  240.  
  241.       Zero or more octets.  The details are implementation specific.
  242.  
  243.  
  244. 2.  Configuration Options
  245.  
  246.    The Configuration Option format and basic options are already defined
  247.    for LCP [1].
  248.  
  249.    Up-to-date values of the LCP Option Type field are specified in the
  250.    most recent "Assigned Numbers" [2].  This document concerns the
  251.    following values:
  252.  
  253.        0      Vendor-Specific
  254.  
  255.  
  256.  
  257. 2.1.  Vendor-Specific Option
  258.  
  259.    Description
  260.  
  261.       Some implementors might not need nor want to publish their
  262.       proprietary algorithms and attributes.  This mechanism is
  263.       available to specify these without encumbering the IANA with
  264.       proprietary number requests.
  265.  
  266.       Before accepting this option, the implementation must verify that
  267.       the Organizationally Unique Identifier and Kind specify a known
  268.       mechanism, and that any vendor specific negotiation values are
  269.       fully understood.
  270.  
  271.    Rationale:
  272.  
  273.       This is defined as general feature of all PPP Control Protocols,
  274.       to avoid future conflicts in vendor secretly self-assigned Type
  275.       numbers.
  276.  
  277.    A summary of the Vendor-Specific Configuration Option format is shown
  278.    below.  The fields are transmitted from left to right.
  279.  
  280.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  281.    |     Type      |    Length     |              OUI
  282.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  283.           ...      |     Kind      |  Value(s) ...
  284.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-
  285.  
  286.  
  287.  
  288.  
  289.  
  290. Simpson                      Informational                      [Page 3]
  291.  
  292. RFC 2153                 PPP vendor extensions                  May 1997
  293.  
  294.  
  295.    Type
  296.  
  297.        0
  298.  
  299.    Length
  300.  
  301.       >= 6
  302.  
  303.       When the Length is six, no Value(s) field is present.
  304.  
  305.    OUI
  306.  
  307.       three octets.  The vendor's Organizationally Unique Identifier.
  308.       The bits within the octet are in canonical order, and the most
  309.       significant octet is transmitted first.
  310.  
  311.    Kind
  312.  
  313.       one octet.  Indicates a sub-type for the OUI.  There is no
  314.       standardization for this field.  Each OUI implements its own
  315.       values.
  316.  
  317.       The Kind field may be extended by the vendor to include zero or
  318.       more octets of the Value(s) field.
  319.  
  320.    Value(s)
  321.  
  322.       Zero or more octets.  The details are implementation specific.
  323.  
  324.  
  325. 3.  Organizationally Unique Identifiers
  326.  
  327.    The three-octet Organizationally Unique Identifier (OUI) identifies
  328.    an organization that administers the meaning of the message.  This
  329.    OUI is based on IEEE 802 vendor assignments.
  330.  
  331.    IEEE contact details for assignment of an OUI are given in [RFC-
  332.    1700].  Vendors that desire to use their IEEE 802 OUI for PPP Vendor
  333.    Extensions should also register the OUI with IANA.
  334.  
  335.    In the alternative, a vendor that does not otherwise need an IEEE
  336.    assigned OUI can request a PPP specific OUI from IANA.  This OUI
  337.    shall be assigned from the 'CF0000' series.  This has both the
  338.    "locally-assigned" and "broadcast/multicast" bits set to 1; that is,
  339.    the least significant two bits of the most significant octet are both
  340.    set to 1.
  341.  
  342.    Appearance in memory, bits transmitted right-to-left within octets,
  343.  
  344.  
  345.  
  346. Simpson                      Informational                      [Page 4]
  347.  
  348. RFC 2153                 PPP vendor extensions                  May 1997
  349.  
  350.  
  351.    octets transmitted left-to-right:
  352.  
  353.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  354.    |1 1 0 0 1 1 1 1|x x x x x x x x|x x x x x x x x|
  355.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  356.                 | |
  357.                 | Multicast
  358.                 Local
  359.  
  360.    Rationale:
  361.  
  362.       This is defined for vendors that are not able to use IEEE
  363.       assignments, such as software-only vendors.
  364.  
  365.       It is not clear how the IEEE assigns blocks.  In some instances,
  366.       the "locally-assigned" bit is known to have been used.
  367.  
  368.       However, multicast has no meaning in PPP.  Therefore, an IEEE
  369.       assigned OUI would have the multicast bit cleared to 0.
  370.  
  371.       The 'CF0000' series was arbitrarily chosen to match the PPP NLPID
  372.       'CF', as a matter of mnemonic convenience.
  373.  
  374.  
  375. Security Considerations
  376.  
  377.    Security issues are not discussed in this document.
  378.  
  379.  
  380. References
  381.  
  382.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", STD
  383.          51, RFC 1661, DayDreamer, July 1994.
  384.  
  385.    [2]   Reynolds, J.K., Postel, J.B., "Assigned Numbers", RFC-1700,
  386.          July 1992.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394.  
  395.  
  396.  
  397.  
  398.  
  399.  
  400.  
  401.  
  402. Simpson                      Informational                      [Page 5]
  403.  
  404. RFC 2153                 PPP vendor extensions                  May 1997
  405.  
  406.  
  407. Contacts
  408.  
  409.    Comments about this document should be discussed on the ietf-
  410.    ppp@merit.edu mailing list.
  411.  
  412.    This document was reviewed by the Point-to-Point Protocol Working
  413.    Group of the Internet Engineering Task Force (IETF).  The working
  414.    group can be contacted via the current chair:
  415.  
  416.       Karl Fox
  417.       Ascend Communications
  418.       655 Metro Place South, Suite 379
  419.       Dublin, Ohio  43017
  420.  
  421.           karl@Ascend.com
  422.  
  423.  
  424.    Questions about this document can also be directed to:
  425.  
  426.       William Allen Simpson
  427.       DayDreamer
  428.       Computer Systems Consulting Services
  429.       1384 Fontaine
  430.       Madison Heights, Michigan  48071
  431.  
  432.           wsimpson@UMich.edu
  433.           wsimpson@GreenDragon.com (preferred)
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444.  
  445.  
  446.  
  447.  
  448.  
  449.  
  450.  
  451.  
  452.  
  453.  
  454.  
  455.  
  456.  
  457.  
  458. Simpson                      Informational                      [Page 6]
  459.  
  460.