GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1570

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1570.txt · Last modified: 1994/01/10 21:15 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki