home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / rfc / rfc1570 < prev    next >
Text File  |  1994-01-11  |  36KB  |  1,058 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                 W. Simpson, Editor
  8. Request for Comments: 1570                                    Daydreamer
  9. Updates: 1548                                               January 1994
  10. Category: Standards Track
  11.  
  12.  
  13.                            PPP LCP Extensions
  14.  
  15. Status of this Memo
  16.  
  17.    This document specifies an Internet standards track protocol for the
  18.    Internet community, and requests discussion and suggestions for
  19.    improvements.  Please refer to the current edition of the "Internet
  20.    Official Protocol Standards" (STD 1) for the standardization state
  21.    and status of this protocol.  Distribution of this memo is unlimited.
  22.  
  23. Abstract
  24.  
  25.    The Point-to-Point Protocol (PPP) [1] provides a standard method for
  26.    transporting multi-protocol datagrams over point-to-point links.  PPP
  27.    defines an extensible Link Control Protocol (LCP) for establishing,
  28.    configuring, and testing the data-link connection.  This document
  29.    defines several additional LCP features which have been suggested
  30.    over the past few years.
  31.  
  32.    This document is the product of the Point-to-Point Protocol Working
  33.    Group of the Internet Engineering Task Force (IETF).  Comments should
  34.    be submitted to the ietf-ppp@ucdavis.edu mailing list.
  35.  
  36. Table of Contents
  37.  
  38.      1.     Additional LCP Packets ................................    1
  39.         1.1       Identification ..................................    1
  40.         1.2       Time-Remaining ..................................    3
  41.      2.     Additional LCP Configuration Options ..................    6
  42.         2.1       FCS-Alternatives ................................    6
  43.            2.1.1  LCP considerations ..............................    7
  44.            2.1.2  Null FCS ........................................    8
  45.         2.2       Self-Describing-Padding .........................    9
  46.         2.3       Callback ........................................   11
  47.         2.4       Compound-Frames .................................   12
  48.            2.4.1  LCP considerations ..............................   14
  49.      APPENDICES ...................................................   15
  50.      A.     Fast Frame Check Sequence (FCS) Implementation ........   15
  51.         A.1       32-bit FCS Computation Method ...................   15
  52.      SECURITY CONSIDERATIONS ......................................   17
  53.      REFERENCES ...................................................   17
  54.      ACKNOWLEDGEMENTS .............................................   18
  55.      CHAIR'S ADDRESS ..............................................   18
  56.      EDITOR'S ADDRESS .............................................   18
  57.  
  58.  
  59.  
  60.  
  61.  
  62.  
  63.  
  64.  
  65. Simpson                                                         [Page i]
  66. RFC 1570                   PPP LCP extensions               January 1994
  67.  
  68.  
  69. 1.  Additional LCP Packets
  70.  
  71.    The Packet format and basic facilities are already defined for LCP
  72.    [1].
  73.  
  74.    Up-to-date values of the LCP Code field are specified in the most
  75.    recent "Assigned Numbers" RFC [2].  This specification concerns the
  76.    following values:
  77.  
  78.       12      Identification
  79.       13      Time-Remaining
  80.  
  81.  
  82.  
  83.  
  84. 1.1.  Identification
  85.  
  86.    Description
  87.  
  88.       This Code provides a method for an implementation to identify
  89.       itself to its peer.  This Code might be used for many diverse
  90.       purposes, such as link troubleshooting, license enforcement, etc.
  91.  
  92.       Identification is a Link Maintenance packet.  Identification
  93.       packets MAY be sent at any time, including before LCP has reached
  94.       the Opened state.
  95.  
  96.       The sender transmits a LCP packet with the Code field set to 12
  97.       (Identification), the Identifier field set, the local Magic-Number
  98.       (if any) inserted, and the Message field filled with any desired
  99.       data, but not exceeding the default MRU minus eight.
  100.  
  101.       Receipt of an Identification packet causes the RXR or RUC event.
  102.       There is no response to the Identification packet.
  103.  
  104.       Receipt of a Code-Reject for the Identification packet SHOULD
  105.       generate the RXJ+ (permitted) event.
  106.  
  107.       Rationale:
  108.  
  109.          This feature is defined as part of LCP, rather than as a
  110.          separate PPP Protocol, in order that its benefits may be
  111.          available during the earliest possible stage of the Link
  112.          Establishment phase.  It allows an operator to learn the
  113.          identification of the peer even when negotiation is not
  114.          converging.  Non-LCP packets cannot be sent during the Link
  115.          Establishment phase.
  116.  
  117.  
  118.  
  119.  
  120. Simpson                                                         [Page 1]
  121. RFC 1570                   PPP LCP extensions               January 1994
  122.  
  123.  
  124.          This feature is defined as a separate LCP Code, rather than a
  125.          Configuration-Option, so that the peer need not include it with
  126.          other items in configuration packet exchanges, and handle
  127.          "corrected" values or "rejection", since its generation is both
  128.          rare and in one direction.  It is recommended that
  129.          Identification packets be sent whenever a Configure-Reject is
  130.          sent or received, as a final message when negotiation fails to
  131.          converge, and when LCP reaches the Opened state.
  132.  
  133.    A summary of the Identification packet format is shown below.  The
  134.    fields are transmitted from left to right.
  135.  
  136.     0                   1                   2                   3
  137.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  138.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  139.    |     Code      |  Identifier   |            Length             |
  140.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  141.    |                         Magic-Number                          |
  142.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  143.    |    Message ...
  144.    +-+-+-+-+-+-+-+-+
  145.  
  146.  
  147.    Code
  148.  
  149.       12 for Identification
  150.  
  151.    Identifier
  152.  
  153.       The Identifier field MUST be changed for each Identification sent.
  154.  
  155.    Length
  156.  
  157.       >= 8
  158.  
  159.    Magic-Number
  160.  
  161.       The Magic-Number field is four octets and aids in detecting links
  162.       which are in the looped-back condition.  Until the Magic-Number
  163.       Configuration Option has been successfully negotiated, the Magic-
  164.       Number MUST be transmitted as zero.  See the Magic-Number
  165.       Configuration Option for further explanation.
  166.  
  167.    Message
  168.  
  169.       The Message field is zero or more octets, and its contents are
  170.       implementation dependent.  It is intended to be human readable,
  171.       and MUST NOT affect operation of the protocol.  It is recommended
  172.  
  173.  
  174.  
  175. Simpson                                                         [Page 2]
  176. RFC 1570                   PPP LCP extensions               January 1994
  177.  
  178.  
  179.       that the message contain displayable ASCII characters 32 through
  180.       126 decimal.  Mechanisms for extension to other character sets are
  181.       the topic of future research.  The size is determined from the
  182.       Length field.
  183.  
  184.       Implementation Note:
  185.  
  186.          The Message will usually contain such things as the sender's
  187.          hardware type, PPP software revision level, and PPP product
  188.          serial number, MIB information such as link speed and interface
  189.          name, and any other information that the sender thinks might be
  190.          useful in debugging connections.  The format is likely to be
  191.          different for each implementor, so that those doing serial
  192.          number tracking can validate their numbers.  A robust
  193.          implementation SHOULD treat the Message as displayable text,
  194.          and SHOULD be able to receive and display a very long Message.
  195.  
  196.  
  197.  
  198. 1.2.  Time-Remaining
  199.  
  200.    Description
  201.  
  202.       This Code provides a mechanism for notifying the peer of the time
  203.       remaining in this session.
  204.  
  205.       The nature of this information is advisory only.  It is intended
  206.       that only one side of the connection will send this packet
  207.       (generally a "network access server").  The session is actually
  208.       concluded by the Terminate-Request packet.
  209.  
  210.       Time-Remaining is a Link Maintenance packet.  Time-Remaining
  211.       packets may only be sent in the LCP Opened state.
  212.  
  213.       The sender transmits a LCP packet with the Code field set to 13
  214.       (Time-Remaining), the Identifier field set, the local Magic-Number
  215.       (if any) inserted, and the Message field filled with any desired
  216.       data, but not exceeding the peer's established MRU minus twelve.
  217.  
  218.       Receipt of an Time-Remaining packet causes the RXR or RUC event.
  219.       There is no response to the Time-Remaining packet.
  220.  
  221.       Receipt of a Code-Reject for the Time-Remaining packet SHOULD
  222.       generate the RXJ+ (permitted) event.
  223.  
  224.       Rationale:
  225.  
  226.          This notification is defined as a separate LCP Code, rather
  227.  
  228.  
  229.  
  230. Simpson                                                         [Page 3]
  231. RFC 1570                   PPP LCP extensions               January 1994
  232.  
  233.  
  234.          than a Configuration-Option, in order that changes and warning
  235.          messages may occur dynamically during the session, and that the
  236.          information might be determined after Authentication has
  237.          occurred.  Typically, this packet is sent when the link enters
  238.          Network-Layer Protocol phase, and at regular intervals
  239.          throughout the session, particularly near the end of the
  240.          session.
  241.  
  242.    A summary of the Time-Remaining packet format is shown below.  The
  243.    fields are transmitted from left to right.
  244.  
  245.     0                   1                   2                   3
  246.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  247.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  248.    |     Code      |  Identifier   |            Length             |
  249.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  250.    |                         Magic-Number                          |
  251.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  252.    |                       Seconds-Remaining                       |
  253.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  254.    |    Message ...
  255.    +-+-+-+-+-+-+-+-+
  256.  
  257.  
  258.    Code
  259.  
  260.       13 for Time-Remaining
  261.  
  262.    Identifier
  263.  
  264.       The Identifier field MUST be changed for each Time-Remaining sent.
  265.  
  266.    Length
  267.  
  268.       >= 12
  269.  
  270.    Magic-Number
  271.  
  272.       The Magic-Number field is four octets and aids in detecting links
  273.       which are in the looped-back condition.  Until the Magic-Number
  274.       Configuration Option has been successfully negotiated, the Magic-
  275.       Number MUST be transmitted as zero.  See the Magic-Number
  276.       Configuration Option for further explanation.
  277.  
  278.    Seconds-Remaining
  279.  
  280.       The Seconds-Remaining field is four octets and indicates the
  281.       number of integral seconds remaining in this session.  This 32 bit
  282.  
  283.  
  284.  
  285. Simpson                                                         [Page 4]
  286. RFC 1570                   PPP LCP extensions               January 1994
  287.  
  288.  
  289.       unsigned value is sent most significant octet first.  A value of
  290.       0xffffffff (all ones) represents no timeout, or "forever".
  291.  
  292.    Message
  293.  
  294.       The Message field is zero or more octets, and its contents are
  295.       implementation dependent.  It is intended to be human readable,
  296.       and MUST NOT affect operation of the protocol.  It is recommended
  297.       that the message contain displayable ASCII characters 32 through
  298.       126 decimal.  Mechanisms for extension to other character sets are
  299.       the topic of future research.  The size is determined from the
  300.       Length field.
  301.  
  302.  
  303.  
  304.  
  305.  
  306.  
  307.  
  308.  
  309.  
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338.  
  339.  
  340. Simpson                                                         [Page 5]
  341. RFC 1570                   PPP LCP extensions               January 1994
  342.  
  343.  
  344. 2.  Additional LCP Configuration Options
  345.  
  346.    The Configuration Option format and basic options are already defined
  347.    for LCP [1].
  348.  
  349.    Up-to-date values of the LCP Option Type field are specified in the
  350.    most recent "Assigned Numbers" RFC [2].  This document concerns the
  351.    following values:
  352.  
  353.       9       FCS-Alternatives
  354.       10      Self-Describing-Padding
  355.       13      Callback
  356.       15      Compound-Frames
  357.  
  358.  
  359.  
  360.  
  361. 2.1.  FCS-Alternatives
  362.  
  363.    Description
  364.  
  365.       This Configuration Option provides a method for an implementation
  366.       to specify another FCS format to be sent by the peer, or to
  367.       negotiate away the FCS altogether.
  368.  
  369.       This option is negotiated separately in each direction.  However,
  370.       it is not required that an implementation be capable of
  371.       concurrently generating a different FCS on each side of the link.
  372.  
  373.       The negotiated FCS values take effect only during Authentication
  374.       and Network-Layer Protocol phases.  Frames sent during any other
  375.       phase MUST contain the default FCS.
  376.  
  377.    A summary of the FCS-Alternatives Configuration Option format is
  378.    shown below.  The fields are transmitted from left to right.
  379.  
  380.     0                   1                   2
  381.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  382.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  383.    |     Type      |    Length     |    Options    |
  384.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  385.  
  386.  
  387.    Type
  388.  
  389.       9
  390.  
  391.  
  392.  
  393.  
  394.  
  395. Simpson                                                         [Page 6]
  396. RFC 1570                   PPP LCP extensions               January 1994
  397.  
  398.  
  399.    Length
  400.  
  401.       3
  402.  
  403.    Options
  404.  
  405.       This field is one octet, and is comprised of the "logical or" of
  406.       the following values:
  407.  
  408.           1   Null FCS
  409.           2   CCITT 16-bit FCS
  410.           4   CCITT 32-bit FCS
  411.  
  412.  
  413.    Implementation Note:
  414.  
  415.       For most PPP HDLC framed links, the default FCS is the CCITT 16-
  416.       bit FCS.  Some framing techniques and high speed links may use
  417.       another format as the default FCS.
  418.  
  419.  
  420. 2.1.1.  LCP considerations
  421.  
  422.    The link can be subject to loss of state, and the LCP can re-
  423.    negotiate at any time.  When the LCP begins renegotiation or
  424.    termination, it is recommended that the LCP Configure-Request or
  425.    Terminate-Request packet be sent with the last negotiated FCS, then
  426.    change to the default FCS, and a duplicate LCP packet is sent with
  427.    the default FCS.  The Identifier field SHOULD NOT be incremented for
  428.    each such duplicate packet.
  429.  
  430.    On receipt of a LCP Configure-Request or Terminate-Request packet,
  431.    the implementation MUST change to the default FCS for both
  432.    transmission and reception.  If a Request packet is received which
  433.    contains a duplicate Identifier field, a new reply MUST be generated.
  434.  
  435.    Implementation Notes:
  436.  
  437.       The need to send two packets is only necessary after the
  438.       Alternative-FCS has already been negotiated.  It need not occur
  439.       during state transitions when there is a natural indication that
  440.       the default FCS is in effect, such as the Down and Up events.  It
  441.       is necessary to send two packets in the Ack-Sent and Opened
  442.       states, since the peer could mistakenly believe that the link has
  443.       Opened.
  444.  
  445.       It is possible to send a single 48-bit FCS which is a combination
  446.       of the 16-bit and 32-bit FCS.  This may be sent instead of sending
  447.  
  448.  
  449.  
  450. Simpson                                                         [Page 7]
  451. RFC 1570                   PPP LCP extensions               January 1994
  452.  
  453.  
  454.       the two packets described above.  We have not standardized this
  455.       procedure because of intellectual property concerns.  If such a
  456.       48-bit FCS is used, it MUST only be used for LCP packets.
  457.  
  458.  
  459. 2.1.2.  Null FCS
  460.  
  461.    The Null FCS SHOULD only be used for those network-layer and
  462.    transport protocols which have an end-to-end checksum available, such
  463.    as TCP/IP, or UDP/IP with the checksum enabled.  That is, the Null
  464.    FCS option SHOULD be negotiated together with another non-null FCS
  465.    option in a heterogeneous environment.
  466.  
  467.    When a configuration (LCP or NCP) or authentication packet is sent,
  468.    the FCS MUST be included.  When a configuration (LCP or NCP) or
  469.    authentication packet is received, the FCS MUST be verified.
  470.  
  471.    There are several cases to be considered:
  472.  
  473.    Null FCS alone
  474.  
  475.       The sender generates the FCS for those frames which require the
  476.       FCS before sending the frame.
  477.  
  478.       When a frame is received, it is not necessary to check the FCS
  479.       before demultiplexing.  Any FCS is treated as padding.
  480.  
  481.       Receipt of an Authentication or Control packet would be discovered
  482.       after passing the frame to the demultiplexer.  Verification of the
  483.       FCS can easily be accomplished using one of the software
  484.       algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and
  485.       Appendix A (32-bit FCS).
  486.  
  487.    Null FCS with another FCS, using software
  488.  
  489.       This is similar to the above case.
  490.  
  491.       Those packets which are required to have the FCS (Authentication,
  492.       Control, or Network-Protocols lacking a checksum) are checked
  493.       using software after demultiplexing.  Packets which fail the FCS
  494.       test are discarded as usual.
  495.  
  496.    Null FCS with another FCS, using hardware
  497.  
  498.       A flag is passed with the frame, indicating whether or not it has
  499.       passed the hardware FCS check.  The incorrect FCS MUST be passed
  500.       with the rest of the data.  The frame MUST NOT be discarded until
  501.       after demultiplexing, and only those frames that require the FCS
  502.  
  503.  
  504.  
  505. Simpson                                                         [Page 8]
  506. RFC 1570                   PPP LCP extensions               January 1994
  507.  
  508.  
  509.       are discarded.
  510.  
  511.    All three FCS forms (Null, 16 and 32) may be used concurrently on
  512.    different frames when using software.  That is probably not possible
  513.    with most current hardware.
  514.  
  515.  
  516.  
  517. 2.2.  Self-Describing-Padding
  518.  
  519.    Description
  520.  
  521.       This Configuration Option provides a method for an implementation
  522.       to indicate to the peer that it understands self-describing pads
  523.       when padding is added at the end of the PPP Information field.
  524.  
  525.       This option is most likely to be used when some protocols, such as
  526.       network-layer or compression protocols, are configured which
  527.       require detection and removal of any trailing padding.  Such
  528.       special protocols are identified in their respective documents.
  529.  
  530.       If the option is Rejected, the peer MUST NOT add any padding to
  531.       the identified special protocols, but MAY add padding to other
  532.       protocols.
  533.  
  534.       If the option is Ack'd, the peer MUST follow the procedures for
  535.       adding self-describing pads, but only to the specifically
  536.       identified protocols.  The peer is not required to add any padding
  537.       to other protocols.
  538.  
  539.       Implementation Notes:
  540.  
  541.          This is defined so that the Reject handles either case where
  542.          the peer does not generate self-describing pads.  When the peer
  543.          never generates padding, it may safely Reject the option.  When
  544.          the peer does not understand the option, it also will not
  545.          successfully configure a special protocol which requires
  546.          elimination of pads.
  547.  
  548.          While some senders might only be capable of adding padding to
  549.          every protocol or not adding padding to any protocol, by design
  550.          the receiver need not examine those protocols which do not need
  551.          the padding stripped.
  552.  
  553.          To avoid unnecessary configuration handshakes, an
  554.          implementation which generates padding, and has a protocol
  555.          configured which requires the padding to be known, SHOULD
  556.          include this Option in its Configure-Request, and SHOULD
  557.  
  558.  
  559.  
  560. Simpson                                                         [Page 9]
  561. RFC 1570                   PPP LCP extensions               January 1994
  562.  
  563.  
  564.          Configure-Nak with this Option when it is not present in the
  565.          peer's Request.
  566.  
  567.       Each octet of self-describing pad contains the index of that
  568.       octet.  The first pad octet MUST contain the value one (1), which
  569.       indicates the Padding Protocol to the Compound-Frames option.
  570.       After removing the FCS, the final pad octet indicates the number
  571.       of pad octets to remove.  For example, three pad octets would
  572.       contain the values 1, 2, 3.
  573.  
  574.       The Maximum-Pad-Value (MPV) is also negotiated.  Only the values 1
  575.       through MPV are used.  When no padding would otherwise be
  576.       required, but the final octet of the PPP Information field
  577.       contains the value 1 through MPV, at least one self-describing pad
  578.       octet MUST be added to the frame.  If the final octet is greater
  579.       than MPV, no additional padding is required.
  580.  
  581.       Implementation Notes:
  582.  
  583.          If any of the pad octets contain an incorrect index value, the
  584.          entire frame SHOULD be silently discarded.  This is intended to
  585.          prevent confusion with the FCS-Alternatives option, but might
  586.          not be necessary in robust implementations.
  587.  
  588.          Since this option is intended to support compression protocols,
  589.          the Maximum-Pad-Value is specified to limit the likelihood that
  590.          a frame may actually become longer.
  591.  
  592.    A summary of the Self-Describing-Padding Configuration Option format
  593.    is shown below.  The fields are transmitted from left to right.
  594.  
  595.     0                   1                   2
  596.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
  597.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  598.    |     Type      |    Length     |    Maximum    |
  599.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  600.  
  601.  
  602.    Type
  603.  
  604.       10
  605.  
  606.    Length
  607.  
  608.       3
  609.  
  610.  
  611.  
  612.  
  613.  
  614.  
  615. Simpson                                                        [Page 10]
  616. RFC 1570                   PPP LCP extensions               January 1994
  617.  
  618.  
  619.    Maximum
  620.  
  621.       This field specifies the largest number of padding octets which
  622.       may be added to the frame.  The value may range from 1 to 255, but
  623.       values of 2, 4, or 8 are most likely.
  624.  
  625.  
  626.  
  627. 2.3.  Callback
  628.  
  629.    Description
  630.  
  631.       This Configuration Option provides a method for an implementation
  632.       to request a dial-up peer to call back.  This option might be used
  633.       for many diverse purposes, such as savings on toll charges.
  634.  
  635.       When Callback is successfully negotiated, and authentication is
  636.       complete, the Authentication phase proceeds directly to the
  637.       Termination phase, and the link is disconnected.
  638.  
  639.       Then, the peer re-establishes the link, without negotiating
  640.       Callback.
  641.  
  642.       Implementation Notes:
  643.  
  644.          A peer which agrees to this option SHOULD request the
  645.          Authentication-Protocol Configuration Option.  The user
  646.          information learned during authentication can be used to
  647.          determine the user location, or to limit a user to certain
  648.          locations, or merely to determine whom to bill for the service.
  649.  
  650.          Authentication SHOULD be requested in turn by the
  651.          implementation when it is called back, if mutual authentication
  652.          is desired.
  653.  
  654.    A summary of the Callback Option format is shown below.  The fields
  655.    are transmitted from left to right.
  656.  
  657.     0                   1                   2                   3
  658.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
  659.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  660.    |     Type      |    Length     |   Operation   |  Message ...
  661.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  662.  
  663.  
  664.    Type
  665.  
  666.       13
  667.  
  668.  
  669.  
  670. Simpson                                                        [Page 11]
  671. RFC 1570                   PPP LCP extensions               January 1994
  672.  
  673.  
  674.    Length
  675.  
  676.       >= 3
  677.  
  678.    Operation
  679.  
  680.       The Operation field is one octet and indicates the contents of the
  681.       Message field.
  682.  
  683.       0       location is determined by user authentication
  684.  
  685.       1       Dialing string, the format and contents of which assumes
  686.               configuration knowledge of the specific device which is
  687.               making the callback.
  688.  
  689.       2       Location identifier, which may or may not be human
  690.               readable, to be used together with the authentication
  691.               information for a database lookup to determine the
  692.               callback location.
  693.  
  694.       3       E.164 number.
  695.  
  696.       4       Distinguished name.
  697.  
  698.    Message
  699.  
  700.       The Message field is zero or more octets, and its general contents
  701.       are determined by the Operation field.  The actual format of the
  702.       information is site or application specific, and a robust
  703.       implementation SHOULD support the field as undistinguished octets.
  704.       The size is determined from the Length field.
  705.  
  706.       It is intended that only an authorized user will have correct site
  707.       specific information to make use of the Callback.  The
  708.       codification of the range of allowed usage of this field is
  709.       outside the scope of this specification.
  710.  
  711.  
  712.  
  713. 2.4.  Compound-Frames
  714.  
  715.    Description
  716.  
  717.       This Configuration Option provides a method for an implementation
  718.       to send multiple PPP encapsulated packets within the same frame.
  719.       This option might be used for many diverse purposes, such as
  720.       savings on toll charges.
  721.  
  722.  
  723.  
  724.  
  725. Simpson                                                        [Page 12]
  726. RFC 1570                   PPP LCP extensions               January 1994
  727.  
  728.  
  729.       Only those PPP Protocols which have determinate lengths or
  730.       integral length fields may be aggregated into a compound frame.
  731.  
  732.       When Compound-Frames is successfully negotiated, the sender MAY
  733.       add additional packets to the same frame.  Each packet is
  734.       immediately followed by another Protocol field, with its attendant
  735.       datagram.
  736.  
  737.       When padding is added to the end of the Information field, the
  738.       procedure described in Self-Describing-Padding is used.
  739.       Therefore, this option MUST be negotiated together with the Self-
  740.       Describing-Padding option.
  741.  
  742.       If the FCS-Alternatives option has been negotiated, self
  743.       describing padding MUST always be added.  That is, the final
  744.       packet MUST be followed by a series of octets, the first of which
  745.       contains the value one (1).
  746.  
  747.       On receipt, the first Protocol field is examined, and the packet
  748.       is processed as usual.  For those datagrams which have a
  749.       determinate length, the remainder of the frame is returned to the
  750.       demultiplexor.  Each succeeding Protocol field is processed as a
  751.       separate packet.  This processing is complete when a packet is
  752.       processed which does not have a determinate length, when the
  753.       remainder of the frame is empty, or when the Protocol field is
  754.       determined to have a value of one (1).
  755.  
  756.       The PPP Protocol value of one (1) is reserved as the Padding
  757.       Protocol.  Any following octets are removed as padding.
  758.  
  759.    A summary of the Compound-Frames Option format is shown below.  The
  760.    fields are transmitted from left to right.
  761.  
  762.     0                   1
  763.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  764.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  765.    |     Type      |    Length     |
  766.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  767.  
  768.  
  769.    Type
  770.  
  771.       15
  772.  
  773.    Length
  774.  
  775.       2
  776.  
  777.  
  778.  
  779.  
  780. Simpson                                                        [Page 13]
  781. RFC 1570                   PPP LCP extensions               January 1994
  782.  
  783.  
  784. 2.4.1.  LCP considerations
  785.  
  786.    During initial negotiation, the Compound-Frames option can be used to
  787.    minimize the negotiation latency, by reducing the number of frames
  788.    exchanged.
  789.  
  790.    The first LCP Configure-Request packet is sent as usual in a single
  791.    frame, including the Self-Describing-Padding and Compound-Frames
  792.    options.
  793.  
  794.    The peer SHOULD respond with a Configure-Ack, followed in a compound
  795.    frame by its LCP Configure-Request, and any NCP Configure-Requests
  796.    desired.
  797.  
  798.    Upon receipt, the local implementation SHOULD process the Configure-
  799.    Ack as usual.  Since the peer has agreed to send compound frames, the
  800.    implementation MUST examine the remainder of the frame for additional
  801.    packets.  If the peer also specified the Self-Describing-Padding and
  802.    Compound-Frames options in its Configure-Request, the local
  803.    implementation SHOULD retain its Configure-Ack, and further NCP
  804.    configuration packets SHOULD be added to the return frame.
  805.  
  806.    Together with the peer's final return frame, the minimum number of
  807.    frames to complete configuration is 4.
  808.  
  809.  
  810.  
  811.  
  812.  
  813.  
  814.  
  815.  
  816.  
  817.  
  818.  
  819.  
  820.  
  821.  
  822.  
  823.  
  824.  
  825.  
  826.  
  827.  
  828.  
  829.  
  830.  
  831.  
  832.  
  833.  
  834.  
  835. Simpson                                                        [Page 14]
  836. RFC 1570                   PPP LCP extensions               January 1994
  837.  
  838.  
  839. A.  Fast Frame Check Sequence (FCS) Implementation
  840.  
  841. A.1.  32-bit FCS Computation Method
  842.  
  843.    The following code provides a table lookup computation for
  844.    calculating the 32-bit Frame Check Sequence as data arrives at the
  845.    interface.
  846.  
  847.    /*
  848.     * u32 represents an unsigned 32-bit number.  Adjust the typedef for
  849.     * your hardware.
  850.     */
  851.    typedef unsigned long u32;
  852.  
  853.    static u32 fcstab_32[256] =
  854.       {
  855.       0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
  856.       0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
  857.       0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
  858.       0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
  859.       0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
  860.       0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
  861.       0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
  862.       0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
  863.       0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
  864.       0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
  865.       0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
  866.       0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
  867.       0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
  868.       0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
  869.       0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
  870.       0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
  871.       0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
  872.       0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
  873.       0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
  874.       0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
  875.       0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
  876.       0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
  877.       0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
  878.       0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
  879.       0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
  880.       0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
  881.       0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
  882.       0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
  883.       0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
  884.       0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
  885.       0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
  886.       0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
  887.  
  888.  
  889.  
  890. Simpson                                                        [Page 15]
  891. RFC 1570                   PPP LCP extensions               January 1994
  892.  
  893.  
  894.       0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
  895.       0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
  896.       0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
  897.       0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
  898.       0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
  899.       0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
  900.       0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
  901.       0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
  902.       0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
  903.       0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
  904.       0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
  905.       0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
  906.       0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
  907.       0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
  908.       0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
  909.       0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
  910.       0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
  911.       0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
  912.       0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
  913.       0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
  914.       0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
  915.       0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
  916.       0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
  917.       0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
  918.       0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
  919.       0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
  920.       0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
  921.       0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
  922.       0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
  923.       0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
  924.       0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
  925.       0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
  926.       };
  927.  
  928.    #define PPPINITFCS32  0xffffffff   /* Initial FCS value */
  929.    #define PPPGOODFCS32  0xdebb20e3   /* Good final FCS value */
  930.  
  931.    /*
  932.     * Calculate a new FCS given the current FCS and the new data.
  933.     */
  934.    u32 pppfcs32(fcs, cp, len)
  935.        register u32 fcs;
  936.        register unsigned char *cp;
  937.        register int len;
  938.        {
  939.        ASSERT(sizeof (u32) == 4);
  940.        ASSERT(((u32) -1) > 0);
  941.        while (len--)
  942.  
  943.  
  944.  
  945. Simpson                                                        [Page 16]
  946. RFC 1570                   PPP LCP extensions               January 1994
  947.  
  948.  
  949.            fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
  950.  
  951.        return (fcs);
  952.        }
  953.  
  954.    /*
  955.     * How to use the fcs
  956.     */
  957.    tryfcs32(cp, len)
  958.        register unsigned char *cp;
  959.        register int len;
  960.    {
  961.        u32 trialfcs;
  962.  
  963.        /* add on output */
  964.        trialfcs = pppfcs32( PPPINITFCS32, cp, len );
  965.        trialfcs ^= 0xffffffff;             /* complement */
  966.        cp[len] = (trialfcs & 0x00ff);      /* Least significant byte first */
  967.        cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
  968.        cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
  969.        cp[len+3] = ((trialfcs >> 8) & 0x00ff);
  970.  
  971.        /* check on input */
  972.        trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
  973.        if ( trialfcs == PPPGOODFCS32 )
  974.            printf("Good FCS\n");
  975.    }
  976.  
  977.  
  978. Security Considerations
  979.  
  980.    Security issues are briefly discussed in sections concerning the
  981.    Callback Configuration Option.
  982.  
  983.  
  984. References
  985.  
  986.    [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
  987.          1548, Daydreamer, December 1993.
  988.  
  989.    [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 
  990.          RFC 1340, USC/Information Sciences Institute, July 1992.
  991.  
  992.    [3]   Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, 
  993.          Daydreamer, December 1993.
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000. Simpson                                                        [Page 17]
  1001. RFC 1570                   PPP LCP extensions               January 1994
  1002.  
  1003.  
  1004. Acknowledgments
  1005.  
  1006.    The Identification feature was suggested by Bob Sutterfield (Morning
  1007.    Star Technologies).
  1008.  
  1009.    The Time-Remaining feature was suggested by Brad Parker (FCR).
  1010.  
  1011.    Some of the original text for FCS-Alternatives was provided by Arthur
  1012.    Harvey (then of DEC).  The Null FCS was requested by Peter Honeyman
  1013.    (UMich).  The 32-bit FCS example code was provided by Karl Fox
  1014.    (Morning Star Technologies).
  1015.  
  1016.    Self-Describing-Padding was suggested and named by Fred Baker (ACC).
  1017.  
  1018.    Compound-Frames was suggested by Keith Sklower (Berkeley).
  1019.  
  1020.    Special thanks to Morning Star Technologies for providing computing
  1021.    resources and network access support for writing this specification.
  1022.  
  1023.  
  1024. Chair's Address
  1025.  
  1026.    The working group can be contacted via the current chair:
  1027.  
  1028.       Fred Baker
  1029.       Advanced Computer Communications
  1030.       315 Bollay Drive
  1031.       Santa Barbara, California  93117
  1032.  
  1033.       EMail: fbaker@acc.com
  1034.  
  1035.  
  1036. Editor's Address
  1037.  
  1038.    Questions about this memo can also be directed to:
  1039.  
  1040.       William Allen Simpson
  1041.       Daydreamer
  1042.       Computer Systems Consulting Services
  1043.       1384 Fontaine
  1044.       Madison Heights, Michigan  48071
  1045.  
  1046.       EMail: Bill.Simpson@um.cc.umich.edu
  1047.              bsimpson@MorningStar.com
  1048.  
  1049.  
  1050.  
  1051.  
  1052.  
  1053.  
  1054.  
  1055. Simpson                                                        [Page 18]
  1056.  
  1057.  
  1058.