project cleanup and prepare to release

1 files changed, 0 insertions, 1057 deletions

diff --git a/doc/rfc1570.txt b/doc/rfc1570.txt
deleted file mode 100644
index edda5d99..00000000
--- a/doc/rfc1570.txt
+++ /dev/null
@@ -1,1057 +0,0 @@
-
-
-
-
-
-
-Network Working Group                                 W. Simpson, Editor
-Request for Comments: 1570                                    Daydreamer
-Updates: 1548                                               January 1994
-Category: Standards Track
-
-
-                           PPP LCP Extensions
-
-Status of this Memo
-
-   This document specifies an Internet standards track protocol for the
-   Internet community, and requests discussion and suggestions for
-   improvements.  Please refer to the current edition of the "Internet
-   Official Protocol Standards" (STD 1) for the standardization state
-   and status of this protocol.  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.  This document
-   defines several additional LCP features which have been suggested
-   over the past few years.
-
-   This document is the product of the Point-to-Point Protocol Working
-   Group of the Internet Engineering Task Force (IETF).  Comments should
-   be submitted to the ietf-ppp@ucdavis.edu mailing list.
-
-Table of Contents
-
-     1.     Additional LCP Packets ................................    1
-        1.1       Identification ..................................    1
-        1.2       Time-Remaining ..................................    3
-     2.     Additional LCP Configuration Options ..................    6
-        2.1       FCS-Alternatives ................................    6
-           2.1.1  LCP considerations ..............................    7
-           2.1.2  Null FCS ........................................    8
-        2.2       Self-Describing-Padding .........................    9
-        2.3       Callback ........................................   11
-        2.4       Compound-Frames .................................   12
-           2.4.1  LCP considerations ..............................   14
-     APPENDICES ...................................................   15
-     A.     Fast Frame Check Sequence (FCS) Implementation ........   15
-        A.1       32-bit FCS Computation Method ...................   15
-     SECURITY CONSIDERATIONS ......................................   17
-     REFERENCES ...................................................   17
-     ACKNOWLEDGEMENTS .............................................   18
-     CHAIR'S ADDRESS ..............................................   18
-     EDITOR'S ADDRESS .............................................   18
-
-
-
-
-
-
-
-
-Simpson                                                         [Page i]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-1.  Additional LCP Packets
-
-   The Packet format and basic facilities are already defined for LCP
-   [1].
-
-   Up-to-date values of the LCP Code field are specified in the most
-   recent "Assigned Numbers" RFC [2].  This specification concerns the
-   following values:
-
-      12      Identification
-      13      Time-Remaining
-
-
-
-
-1.1.  Identification
-
-   Description
-
-      This Code provides a method for an implementation to identify
-      itself to its peer.  This Code might be used for many diverse
-      purposes, such as link troubleshooting, license enforcement, etc.
-
-      Identification is a Link Maintenance packet.  Identification
-      packets MAY be sent at any time, including before LCP has reached
-      the Opened state.
-
-      The sender transmits a LCP packet with the Code field set to 12
-      (Identification), the Identifier field set, the local Magic-Number
-      (if any) inserted, and the Message field filled with any desired
-      data, but not exceeding the default MRU minus eight.
-
-      Receipt of an Identification packet causes the RXR or RUC event.
-      There is no response to the Identification packet.
-
-      Receipt of a Code-Reject for the Identification packet SHOULD
-      generate the RXJ+ (permitted) event.
-
-      Rationale:
-
-         This feature is defined as part of LCP, rather than as a
-         separate PPP Protocol, in order that its benefits may be
-         available during the earliest possible stage of the Link
-         Establishment phase.  It allows an operator to learn the
-         identification of the peer even when negotiation is not
-         converging.  Non-LCP packets cannot be sent during the Link
-         Establishment phase.
-
-
-
-
-Simpson                                                         [Page 1]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-         This feature is defined as a separate LCP Code, rather than a
-         Configuration-Option, so that the peer need not include it with
-         other items in configuration packet exchanges, and handle
-         "corrected" values or "rejection", since its generation is both
-         rare and in one direction.  It is recommended that
-         Identification packets be sent whenever a Configure-Reject is
-         sent or received, as a final message when negotiation fails to
-         converge, and when LCP reaches the Opened state.
-
-   A summary of the Identification packet format is shown below.  The
-   fields are transmitted from left to right.
-
-    0                   1                   2                   3
-    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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Code      |  Identifier   |            Length             |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                         Magic-Number                          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |    Message ...
-   +-+-+-+-+-+-+-+-+
-
-
-   Code
-
-      12 for Identification
-
-   Identifier
-
-      The Identifier field MUST be changed for each Identification sent.
-
-   Length
-
-      >= 8
-
-   Magic-Number
-
-      The Magic-Number field is four octets and aids in detecting links
-      which 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.
-
-   Message
-
-      The Message field is zero or more octets, and its contents are
-      implementation dependent.  It is intended to be human readable,
-      and MUST NOT affect operation of the protocol.  It is recommended
-
-
-
-Simpson                                                         [Page 2]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-      that the message contain displayable ASCII characters 32 through
-      126 decimal.  Mechanisms for extension to other character sets are
-      the topic of future research.  The size is determined from the
-      Length field.
-
-      Implementation Note:
-
-         The Message will usually contain such things as the sender's
-         hardware type, PPP software revision level, and PPP product
-         serial number, MIB information such as link speed and interface
-         name, and any other information that the sender thinks might be
-         useful in debugging connections.  The format is likely to be
-         different for each implementor, so that those doing serial
-         number tracking can validate their numbers.  A robust
-         implementation SHOULD treat the Message as displayable text,
-         and SHOULD be able to receive and display a very long Message.
-
-
-
-1.2.  Time-Remaining
-
-   Description
-
-      This Code provides a mechanism for notifying the peer of the time
-      remaining in this session.
-
-      The nature of this information is advisory only.  It is intended
-      that only one side of the connection will send this packet
-      (generally a "network access server").  The session is actually
-      concluded by the Terminate-Request packet.
-
-      Time-Remaining is a Link Maintenance packet.  Time-Remaining
-      packets may only be sent in the LCP Opened state.
-
-      The sender transmits a LCP packet with the Code field set to 13
-      (Time-Remaining), the Identifier field set, the local Magic-Number
-      (if any) inserted, and the Message field filled with any desired
-      data, but not exceeding the peer's established MRU minus twelve.
-
-      Receipt of an Time-Remaining packet causes the RXR or RUC event.
-      There is no response to the Time-Remaining packet.
-
-      Receipt of a Code-Reject for the Time-Remaining packet SHOULD
-      generate the RXJ+ (permitted) event.
-
-      Rationale:
-
-         This notification is defined as a separate LCP Code, rather
-
-
-
-Simpson                                                         [Page 3]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-         than a Configuration-Option, in order that changes and warning
-         messages may occur dynamically during the session, and that the
-         information might be determined after Authentication has
-         occurred.  Typically, this packet is sent when the link enters
-         Network-Layer Protocol phase, and at regular intervals
-         throughout the session, particularly near the end of the
-         session.
-
-   A summary of the Time-Remaining packet format is shown below.  The
-   fields are transmitted from left to right.
-
-    0                   1                   2                   3
-    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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Code      |  Identifier   |            Length             |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                         Magic-Number                          |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |                       Seconds-Remaining                       |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |    Message ...
-   +-+-+-+-+-+-+-+-+
-
-
-   Code
-
-      13 for Time-Remaining
-
-   Identifier
-
-      The Identifier field MUST be changed for each Time-Remaining sent.
-
-   Length
-
-      >= 12
-
-   Magic-Number
-
-      The Magic-Number field is four octets and aids in detecting links
-      which 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.
-
-   Seconds-Remaining
-
-      The Seconds-Remaining field is four octets and indicates the
-      number of integral seconds remaining in this session.  This 32 bit
-
-
-
-Simpson                                                         [Page 4]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-      unsigned value is sent most significant octet first.  A value of
-      0xffffffff (all ones) represents no timeout, or "forever".
-
-   Message
-
-      The Message field is zero or more octets, and its contents are
-      implementation dependent.  It is intended to be human readable,
-      and MUST NOT affect operation of the protocol.  It is recommended
-      that the message contain displayable ASCII characters 32 through
-      126 decimal.  Mechanisms for extension to other character sets are
-      the topic of future research.  The size is determined from the
-      Length field.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Simpson                                                         [Page 5]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-2.  Additional LCP 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" RFC [2].  This document concerns the
-   following values:
-
-      9       FCS-Alternatives
-      10      Self-Describing-Padding
-      13      Callback
-      15      Compound-Frames
-
-
-
-
-2.1.  FCS-Alternatives
-
-   Description
-
-      This Configuration Option provides a method for an implementation
-      to specify another FCS format to be sent by the peer, or to
-      negotiate away the FCS altogether.
-
-      This option is negotiated separately in each direction.  However,
-      it is not required that an implementation be capable of
-      concurrently generating a different FCS on each side of the link.
-
-      The negotiated FCS values take effect only during Authentication
-      and Network-Layer Protocol phases.  Frames sent during any other
-      phase MUST contain the default FCS.
-
-   A summary of the FCS-Alternatives Configuration Option format is
-   shown below.  The fields are transmitted from left to right.
-
-    0                   1                   2
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |    Length     |    Options    |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   Type
-
-      9
-
-
-
-
-
-Simpson                                                         [Page 6]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-   Length
-
-      3
-
-   Options
-
-      This field is one octet, and is comprised of the "logical or" of
-      the following values:
-
-          1   Null FCS
-          2   CCITT 16-bit FCS
-          4   CCITT 32-bit FCS
-
-
-   Implementation Note:
-
-      For most PPP HDLC framed links, the default FCS is the CCITT 16-
-      bit FCS.  Some framing techniques and high speed links may use
-      another format as the default FCS.
-
-
-2.1.1.  LCP considerations
-
-   The link can be subject to loss of state, and the LCP can re-
-   negotiate at any time.  When the LCP begins renegotiation or
-   termination, it is recommended that the LCP Configure-Request or
-   Terminate-Request packet be sent with the last negotiated FCS, then
-   change to the default FCS, and a duplicate LCP packet is sent with
-   the default FCS.  The Identifier field SHOULD NOT be incremented for
-   each such duplicate packet.
-
-   On receipt of a LCP Configure-Request or Terminate-Request packet,
-   the implementation MUST change to the default FCS for both
-   transmission and reception.  If a Request packet is received which
-   contains a duplicate Identifier field, a new reply MUST be generated.
-
-   Implementation Notes:
-
-      The need to send two packets is only necessary after the
-      Alternative-FCS has already been negotiated.  It need not occur
-      during state transitions when there is a natural indication that
-      the default FCS is in effect, such as the Down and Up events.  It
-      is necessary to send two packets in the Ack-Sent and Opened
-      states, since the peer could mistakenly believe that the link has
-      Opened.
-
-      It is possible to send a single 48-bit FCS which is a combination
-      of the 16-bit and 32-bit FCS.  This may be sent instead of sending
-
-
-
-Simpson                                                         [Page 7]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-      the two packets described above.  We have not standardized this
-      procedure because of intellectual property concerns.  If such a
-      48-bit FCS is used, it MUST only be used for LCP packets.
-
-
-2.1.2.  Null FCS
-
-   The Null FCS SHOULD only be used for those network-layer and
-   transport protocols which have an end-to-end checksum available, such
-   as TCP/IP, or UDP/IP with the checksum enabled.  That is, the Null
-   FCS option SHOULD be negotiated together with another non-null FCS
-   option in a heterogeneous environment.
-
-   When a configuration (LCP or NCP) or authentication packet is sent,
-   the FCS MUST be included.  When a configuration (LCP or NCP) or
-   authentication packet is received, the FCS MUST be verified.
-
-   There are several cases to be considered:
-
-   Null FCS alone
-
-      The sender generates the FCS for those frames which require the
-      FCS before sending the frame.
-
-      When a frame is received, it is not necessary to check the FCS
-      before demultiplexing.  Any FCS is treated as padding.
-
-      Receipt of an Authentication or Control packet would be discovered
-      after passing the frame to the demultiplexer.  Verification of the
-      FCS can easily be accomplished using one of the software
-      algorithms defined in "PPP in HDLC Framing" [3] (16-bit FCS) and
-      Appendix A (32-bit FCS).
-
-   Null FCS with another FCS, using software
-
-      This is similar to the above case.
-
-      Those packets which are required to have the FCS (Authentication,
-      Control, or Network-Protocols lacking a checksum) are checked
-      using software after demultiplexing.  Packets which fail the FCS
-      test are discarded as usual.
-
-   Null FCS with another FCS, using hardware
-
-      A flag is passed with the frame, indicating whether or not it has
-      passed the hardware FCS check.  The incorrect FCS MUST be passed
-      with the rest of the data.  The frame MUST NOT be discarded until
-      after demultiplexing, and only those frames that require the FCS
-
-
-
-Simpson                                                         [Page 8]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-      are discarded.
-
-   All three FCS forms (Null, 16 and 32) may be used concurrently on
-   different frames when using software.  That is probably not possible
-   with most current hardware.
-
-
-
-2.2.  Self-Describing-Padding
-
-   Description
-
-      This Configuration Option provides a method for an implementation
-      to indicate to the peer that it understands self-describing pads
-      when padding is added at the end of the PPP Information field.
-
-      This option is most likely to be used when some protocols, such as
-      network-layer or compression protocols, are configured which
-      require detection and removal of any trailing padding.  Such
-      special protocols are identified in their respective documents.
-
-      If the option is Rejected, the peer MUST NOT add any padding to
-      the identified special protocols, but MAY add padding to other
-      protocols.
-
-      If the option is Ack'd, the peer MUST follow the procedures for
-      adding self-describing pads, but only to the specifically
-      identified protocols.  The peer is not required to add any padding
-      to other protocols.
-
-      Implementation Notes:
-
-         This is defined so that the Reject handles either case where
-         the peer does not generate self-describing pads.  When the peer
-         never generates padding, it may safely Reject the option.  When
-         the peer does not understand the option, it also will not
-         successfully configure a special protocol which requires
-         elimination of pads.
-
-         While some senders might only be capable of adding padding to
-         every protocol or not adding padding to any protocol, by design
-         the receiver need not examine those protocols which do not need
-         the padding stripped.
-
-         To avoid unnecessary configuration handshakes, an
-         implementation which generates padding, and has a protocol
-         configured which requires the padding to be known, SHOULD
-         include this Option in its Configure-Request, and SHOULD
-
-
-
-Simpson                                                         [Page 9]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-         Configure-Nak with this Option when it is not present in the
-         peer's Request.
-
-      Each octet of self-describing pad contains the index of that
-      octet.  The first pad octet MUST contain the value one (1), which
-      indicates the Padding Protocol to the Compound-Frames option.
-      After removing the FCS, the final pad octet indicates the number
-      of pad octets to remove.  For example, three pad octets would
-      contain the values 1, 2, 3.
-
-      The Maximum-Pad-Value (MPV) is also negotiated.  Only the values 1
-      through MPV are used.  When no padding would otherwise be
-      required, but the final octet of the PPP Information field
-      contains the value 1 through MPV, at least one self-describing pad
-      octet MUST be added to the frame.  If the final octet is greater
-      than MPV, no additional padding is required.
-
-      Implementation Notes:
-
-         If any of the pad octets contain an incorrect index value, the
-         entire frame SHOULD be silently discarded.  This is intended to
-         prevent confusion with the FCS-Alternatives option, but might
-         not be necessary in robust implementations.
-
-         Since this option is intended to support compression protocols,
-         the Maximum-Pad-Value is specified to limit the likelihood that
-         a frame may actually become longer.
-
-   A summary of the Self-Describing-Padding Configuration Option format
-   is shown below.  The fields are transmitted from left to right.
-
-    0                   1                   2
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |    Length     |    Maximum    |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   Type
-
-      10
-
-   Length
-
-      3
-
-
-
-
-
-
-Simpson                                                        [Page 10]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-   Maximum
-
-      This field specifies the largest number of padding octets which
-      may be added to the frame.  The value may range from 1 to 255, but
-      values of 2, 4, or 8 are most likely.
-
-
-
-2.3.  Callback
-
-   Description
-
-      This Configuration Option provides a method for an implementation
-      to request a dial-up peer to call back.  This option might be used
-      for many diverse purposes, such as savings on toll charges.
-
-      When Callback is successfully negotiated, and authentication is
-      complete, the Authentication phase proceeds directly to the
-      Termination phase, and the link is disconnected.
-
-      Then, the peer re-establishes the link, without negotiating
-      Callback.
-
-      Implementation Notes:
-
-         A peer which agrees to this option SHOULD request the
-         Authentication-Protocol Configuration Option.  The user
-         information learned during authentication can be used to
-         determine the user location, or to limit a user to certain
-         locations, or merely to determine whom to bill for the service.
-
-         Authentication SHOULD be requested in turn by the
-         implementation when it is called back, if mutual authentication
-         is desired.
-
-   A summary of the Callback Option format is shown below.  The fields
-   are transmitted from left to right.
-
-    0                   1                   2                   3
-    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
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |    Length     |   Operation   |  Message ...
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   Type
-
-      13
-
-
-
-Simpson                                                        [Page 11]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-   Length
-
-      >= 3
-
-   Operation
-
-      The Operation field is one octet and indicates the contents of the
-      Message field.
-
-      0       location is determined by user authentication
-
-      1       Dialing string, the format and contents of which assumes
-              configuration knowledge of the specific device which is
-              making the callback.
-
-      2       Location identifier, which may or may not be human
-              readable, to be used together with the authentication
-              information for a database lookup to determine the
-              callback location.
-
-      3       E.164 number.
-
-      4       Distinguished name.
-
-   Message
-
-      The Message field is zero or more octets, and its general contents
-      are determined by the Operation field.  The actual format of the
-      information is site or application specific, and a robust
-      implementation SHOULD support the field as undistinguished octets.
-      The size is determined from the Length field.
-
-      It is intended that only an authorized user will have correct site
-      specific information to make use of the Callback.  The
-      codification of the range of allowed usage of this field is
-      outside the scope of this specification.
-
-
-
-2.4.  Compound-Frames
-
-   Description
-
-      This Configuration Option provides a method for an implementation
-      to send multiple PPP encapsulated packets within the same frame.
-      This option might be used for many diverse purposes, such as
-      savings on toll charges.
-
-
-
-
-Simpson                                                        [Page 12]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-      Only those PPP Protocols which have determinate lengths or
-      integral length fields may be aggregated into a compound frame.
-
-      When Compound-Frames is successfully negotiated, the sender MAY
-      add additional packets to the same frame.  Each packet is
-      immediately followed by another Protocol field, with its attendant
-      datagram.
-
-      When padding is added to the end of the Information field, the
-      procedure described in Self-Describing-Padding is used.
-      Therefore, this option MUST be negotiated together with the Self-
-      Describing-Padding option.
-
-      If the FCS-Alternatives option has been negotiated, self
-      describing padding MUST always be added.  That is, the final
-      packet MUST be followed by a series of octets, the first of which
-      contains the value one (1).
-
-      On receipt, the first Protocol field is examined, and the packet
-      is processed as usual.  For those datagrams which have a
-      determinate length, the remainder of the frame is returned to the
-      demultiplexor.  Each succeeding Protocol field is processed as a
-      separate packet.  This processing is complete when a packet is
-      processed which does not have a determinate length, when the
-      remainder of the frame is empty, or when the Protocol field is
-      determined to have a value of one (1).
-
-      The PPP Protocol value of one (1) is reserved as the Padding
-      Protocol.  Any following octets are removed as padding.
-
-   A summary of the Compound-Frames Option format is shown below.  The
-   fields are transmitted from left to right.
-
-    0                   1
-    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-   |     Type      |    Length     |
-   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-   Type
-
-      15
-
-   Length
-
-      2
-
-
-
-
-Simpson                                                        [Page 13]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-2.4.1.  LCP considerations
-
-   During initial negotiation, the Compound-Frames option can be used to
-   minimize the negotiation latency, by reducing the number of frames
-   exchanged.
-
-   The first LCP Configure-Request packet is sent as usual in a single
-   frame, including the Self-Describing-Padding and Compound-Frames
-   options.
-
-   The peer SHOULD respond with a Configure-Ack, followed in a compound
-   frame by its LCP Configure-Request, and any NCP Configure-Requests
-   desired.
-
-   Upon receipt, the local implementation SHOULD process the Configure-
-   Ack as usual.  Since the peer has agreed to send compound frames, the
-   implementation MUST examine the remainder of the frame for additional
-   packets.  If the peer also specified the Self-Describing-Padding and
-   Compound-Frames options in its Configure-Request, the local
-   implementation SHOULD retain its Configure-Ack, and further NCP
-   configuration packets SHOULD be added to the return frame.
-
-   Together with the peer's final return frame, the minimum number of
-   frames to complete configuration is 4.
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-
-Simpson                                                        [Page 14]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-A.  Fast Frame Check Sequence (FCS) Implementation
-
-A.1.  32-bit FCS Computation Method
-
-   The following code provides a table lookup computation for
-   calculating the 32-bit Frame Check Sequence as data arrives at the
-   interface.
-
-   /*
-    * u32 represents an unsigned 32-bit number.  Adjust the typedef for
-    * your hardware.
-    */
-   typedef unsigned long u32;
-
-   static u32 fcstab_32[256] =
-      {
-      0x00000000, 0x77073096, 0xee0e612c, 0x990951ba,
-      0x076dc419, 0x706af48f, 0xe963a535, 0x9e6495a3,
-      0x0edb8832, 0x79dcb8a4, 0xe0d5e91e, 0x97d2d988,
-      0x09b64c2b, 0x7eb17cbd, 0xe7b82d07, 0x90bf1d91,
-      0x1db71064, 0x6ab020f2, 0xf3b97148, 0x84be41de,
-      0x1adad47d, 0x6ddde4eb, 0xf4d4b551, 0x83d385c7,
-      0x136c9856, 0x646ba8c0, 0xfd62f97a, 0x8a65c9ec,
-      0x14015c4f, 0x63066cd9, 0xfa0f3d63, 0x8d080df5,
-      0x3b6e20c8, 0x4c69105e, 0xd56041e4, 0xa2677172,
-      0x3c03e4d1, 0x4b04d447, 0xd20d85fd, 0xa50ab56b,
-      0x35b5a8fa, 0x42b2986c, 0xdbbbc9d6, 0xacbcf940,
-      0x32d86ce3, 0x45df5c75, 0xdcd60dcf, 0xabd13d59,
-      0x26d930ac, 0x51de003a, 0xc8d75180, 0xbfd06116,
-      0x21b4f4b5, 0x56b3c423, 0xcfba9599, 0xb8bda50f,
-      0x2802b89e, 0x5f058808, 0xc60cd9b2, 0xb10be924,
-      0x2f6f7c87, 0x58684c11, 0xc1611dab, 0xb6662d3d,
-      0x76dc4190, 0x01db7106, 0x98d220bc, 0xefd5102a,
-      0x71b18589, 0x06b6b51f, 0x9fbfe4a5, 0xe8b8d433,
-      0x7807c9a2, 0x0f00f934, 0x9609a88e, 0xe10e9818,
-      0x7f6a0dbb, 0x086d3d2d, 0x91646c97, 0xe6635c01,
-      0x6b6b51f4, 0x1c6c6162, 0x856530d8, 0xf262004e,
-      0x6c0695ed, 0x1b01a57b, 0x8208f4c1, 0xf50fc457,
-      0x65b0d9c6, 0x12b7e950, 0x8bbeb8ea, 0xfcb9887c,
-      0x62dd1ddf, 0x15da2d49, 0x8cd37cf3, 0xfbd44c65,
-      0x4db26158, 0x3ab551ce, 0xa3bc0074, 0xd4bb30e2,
-      0x4adfa541, 0x3dd895d7, 0xa4d1c46d, 0xd3d6f4fb,
-      0x4369e96a, 0x346ed9fc, 0xad678846, 0xda60b8d0,
-      0x44042d73, 0x33031de5, 0xaa0a4c5f, 0xdd0d7cc9,
-      0x5005713c, 0x270241aa, 0xbe0b1010, 0xc90c2086,
-      0x5768b525, 0x206f85b3, 0xb966d409, 0xce61e49f,
-      0x5edef90e, 0x29d9c998, 0xb0d09822, 0xc7d7a8b4,
-      0x59b33d17, 0x2eb40d81, 0xb7bd5c3b, 0xc0ba6cad,
-
-
-
-Simpson                                                        [Page 15]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-      0xedb88320, 0x9abfb3b6, 0x03b6e20c, 0x74b1d29a,
-      0xead54739, 0x9dd277af, 0x04db2615, 0x73dc1683,
-      0xe3630b12, 0x94643b84, 0x0d6d6a3e, 0x7a6a5aa8,
-      0xe40ecf0b, 0x9309ff9d, 0x0a00ae27, 0x7d079eb1,
-      0xf00f9344, 0x8708a3d2, 0x1e01f268, 0x6906c2fe,
-      0xf762575d, 0x806567cb, 0x196c3671, 0x6e6b06e7,
-      0xfed41b76, 0x89d32be0, 0x10da7a5a, 0x67dd4acc,
-      0xf9b9df6f, 0x8ebeeff9, 0x17b7be43, 0x60b08ed5,
-      0xd6d6a3e8, 0xa1d1937e, 0x38d8c2c4, 0x4fdff252,
-      0xd1bb67f1, 0xa6bc5767, 0x3fb506dd, 0x48b2364b,
-      0xd80d2bda, 0xaf0a1b4c, 0x36034af6, 0x41047a60,
-      0xdf60efc3, 0xa867df55, 0x316e8eef, 0x4669be79,
-      0xcb61b38c, 0xbc66831a, 0x256fd2a0, 0x5268e236,
-      0xcc0c7795, 0xbb0b4703, 0x220216b9, 0x5505262f,
-      0xc5ba3bbe, 0xb2bd0b28, 0x2bb45a92, 0x5cb36a04,
-      0xc2d7ffa7, 0xb5d0cf31, 0x2cd99e8b, 0x5bdeae1d,
-      0x9b64c2b0, 0xec63f226, 0x756aa39c, 0x026d930a,
-      0x9c0906a9, 0xeb0e363f, 0x72076785, 0x05005713,
-      0x95bf4a82, 0xe2b87a14, 0x7bb12bae, 0x0cb61b38,
-      0x92d28e9b, 0xe5d5be0d, 0x7cdcefb7, 0x0bdbdf21,
-      0x86d3d2d4, 0xf1d4e242, 0x68ddb3f8, 0x1fda836e,
-      0x81be16cd, 0xf6b9265b, 0x6fb077e1, 0x18b74777,
-      0x88085ae6, 0xff0f6a70, 0x66063bca, 0x11010b5c,
-      0x8f659eff, 0xf862ae69, 0x616bffd3, 0x166ccf45,
-      0xa00ae278, 0xd70dd2ee, 0x4e048354, 0x3903b3c2,
-      0xa7672661, 0xd06016f7, 0x4969474d, 0x3e6e77db,
-      0xaed16a4a, 0xd9d65adc, 0x40df0b66, 0x37d83bf0,
-      0xa9bcae53, 0xdebb9ec5, 0x47b2cf7f, 0x30b5ffe9,
-      0xbdbdf21c, 0xcabac28a, 0x53b39330, 0x24b4a3a6,
-      0xbad03605, 0xcdd70693, 0x54de5729, 0x23d967bf,
-      0xb3667a2e, 0xc4614ab8, 0x5d681b02, 0x2a6f2b94,
-      0xb40bbe37, 0xc30c8ea1, 0x5a05df1b, 0x2d02ef8d
-      };
-
-   #define PPPINITFCS32  0xffffffff   /* Initial FCS value */
-   #define PPPGOODFCS32  0xdebb20e3   /* Good final FCS value */
-
-   /*
-    * Calculate a new FCS given the current FCS and the new data.
-    */
-   u32 pppfcs32(fcs, cp, len)
-       register u32 fcs;
-       register unsigned char *cp;
-       register int len;
-       {
-       ASSERT(sizeof (u32) == 4);
-       ASSERT(((u32) -1) > 0);
-       while (len--)
-
-
-
-Simpson                                                        [Page 16]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-           fcs = (((fcs) >> 8) ^ fcstab_32[((fcs) ^ (*cp++)) & 0xff]);
-
-       return (fcs);
-       }
-
-   /*
-    * How to use the fcs
-    */
-   tryfcs32(cp, len)
-       register unsigned char *cp;
-       register int len;
-   {
-       u32 trialfcs;
-
-       /* add on output */
-       trialfcs = pppfcs32( PPPINITFCS32, cp, len );
-       trialfcs ^= 0xffffffff;             /* complement */
-       cp[len] = (trialfcs & 0x00ff);      /* Least significant byte first */
-       cp[len+1] = ((trialfcs >>= 8) & 0x00ff);
-       cp[len+2] = ((trialfcs >>= 8) & 0x00ff);
-       cp[len+3] = ((trialfcs >> 8) & 0x00ff);
-
-       /* check on input */
-       trialfcs = pppfcs32( PPPINITFCS32, cp, len + 4 );
-       if ( trialfcs == PPPGOODFCS32 )
-           printf("Good FCS\n");
-   }
-
-
-Security Considerations
-
-   Security issues are briefly discussed in sections concerning the
-   Callback Configuration Option.
-
-
-References
-
-   [1]   Simpson, W., Editor, "The Point-to-Point Protocol (PPP)", RFC
-         1548, Daydreamer, December 1993.
-
-   [2]   Reynolds, J., and J. Postel, "Assigned Numbers", STD 2, 
-         RFC 1340, USC/Information Sciences Institute, July 1992.
-
-   [3]   Simpson, W., Editor, "PPP in HDLC Framing", RFC 1549, 
-         Daydreamer, December 1993.
-
-
-
-
-
-
-Simpson                                                        [Page 17]
-RFC 1570                   PPP LCP extensions               January 1994
-
-
-Acknowledgments
-
-   The Identification feature was suggested by Bob Sutterfield (Morning
-   Star Technologies).
-
-   The Time-Remaining feature was suggested by Brad Parker (FCR).
-
-   Some of the original text for FCS-Alternatives was provided by Arthur
-   Harvey (then of DEC).  The Null FCS was requested by Peter Honeyman
-   (UMich).  The 32-bit FCS example code was provided by Karl Fox
-   (Morning Star Technologies).
-
-   Self-Describing-Padding was suggested and named by Fred Baker (ACC).
-
-   Compound-Frames was suggested by Keith Sklower (Berkeley).
-
-   Special thanks to Morning Star Technologies for providing computing
-   resources and network access support for writing this specification.
-
-
-Chair's Address
-
-   The working group can be contacted via the current chair:
-
-      Fred Baker
-      Advanced Computer Communications
-      315 Bollay Drive
-      Santa Barbara, California  93117
-
-      EMail: fbaker@acc.com
-
-
-Editor's Address
-
-   Questions about this memo can also be directed to:
-
-      William Allen Simpson
-      Daydreamer
-      Computer Systems Consulting Services
-      1384 Fontaine
-      Madison Heights, Michigan  48071
-
-      EMail: Bill.Simpson@um.cc.umich.edu
-             bsimpson@MorningStar.com
-
-
-
-
-
-
-
-Simpson                                                        [Page 18]
-
-