home *** CD-ROM | disk | FTP | other *** search
/ The World of Computer Software / World_Of_Computer_Software-02-387-Vol-3of3.iso / r / rfc1331.zip / RFC1331.TXT < prev   
Text File  |  1992-12-02  |  134KB  |  3,862 lines
  1. Network Working Group                                         W. Simpson
  2. Request for Comments: 1331                                    Daydreamer
  3. Obsoletes: RFCs 1171, 1172                                      May 1992
  4.  
  5.  
  6.  
  7.                    The Point-to-Point Protocol (PPP)
  8.                                 for the
  9.                 Transmission of Multi-protocol Datagrams
  10.                        over Point-to-Point Links
  11.  
  12.  
  13. Status of this Memo
  14.  
  15.    This RFC specifies an IAB standards track protocol for the Internet
  16.    community, and requests discussion and suggestions for improvements.
  17.    Please refer to the current edition of the "IAB Official Protocol
  18.    Standards" for the standardization state and status of this protocol.
  19.    Distribution of this memo is unlimited.
  20.  
  21. Abstract
  22.  
  23.    The Point-to-Point Protocol (PPP) provides a method for transmitting
  24.    datagrams over serial point-to-point links.  PPP is comprised of
  25.    three main components:
  26.  
  27.       1. A method for encapsulating datagrams over serial links.
  28.  
  29.       2. A Link Control Protocol (LCP) for establishing, configuring,
  30.          and testing the data-link connection.
  31.  
  32.       3. A family of Network Control Protocols (NCPs) for establishing
  33.          and configuring different network-layer protocols.
  34.  
  35.    This document defines the PPP encapsulation scheme, together with the
  36.    PPP Link Control Protocol (LCP), an extensible option negotiation
  37.    protocol which is able to negotiate a rich assortment of
  38.    configuration parameters and provides additional management
  39.    functions.
  40.  
  41.    This RFC is a product of the Point-to-Point Protocol Working Group of
  42.    the Internet Engineering Task Force (IETF).  Comments on this memo
  43.    should be submitted to the ietf-ppp@ucdavis.edu mailing list.
  44.  
  45.  
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52. Simpson                                                         [Page i]
  53.  
  54. RFC 1331                Point-to-Point Protocol                 May 1992
  55.  
  56.  
  57. Table of Contents
  58.  
  59.  
  60.      1.     Introduction ..........................................    1
  61.         1.1       Specification of Requirements ...................    3
  62.         1.2       Terminology .....................................    3
  63.  
  64.      2.     Physical Layer Requirements ...........................    4
  65.  
  66.      3.     The Data Link Layer ...................................    5
  67.         3.1       Frame Format ....................................    6
  68.  
  69.      4.     PPP Link Operation ....................................   10
  70.         4.1       Overview ........................................   10
  71.         4.2       Phase Diagram ...................................   10
  72.         4.3       Link Dead (physical-layer not ready) ............   10
  73.         4.4       Link Establishment Phase ........................   11
  74.         4.5       Authentication Phase ............................   11
  75.         4.6       Network-Layer Protocol Phase ....................   12
  76.         4.7       Link Termination Phase ..........................   12
  77.  
  78.      5.     The Option Negotiation Automaton ......................   14
  79.         5.1       State Diagram ...................................   15
  80.         5.2       State Transition Table ..........................   16
  81.         5.3       States ..........................................   18
  82.         5.4       Events ..........................................   20
  83.         5.5       Actions .........................................   24
  84.         5.6       Loop Avoidance ..................................   26
  85.         5.7       Counters and Timers .............................   27
  86.  
  87.      6.     LCP Packet Formats ....................................   28
  88.         6.1       Configure-Request ...............................   30
  89.         6.2       Configure-Ack ...................................   31
  90.         6.3       Configure-Nak ...................................   32
  91.         6.4       Configure-Reject ................................   33
  92.         6.5       Terminate-Request and Terminate-Ack .............   35
  93.         6.6       Code-Reject .....................................   36
  94.         6.7       Protocol-Reject .................................   38
  95.         6.8       Echo-Request and Echo-Reply .....................   39
  96.         6.9       Discard-Request .................................   40
  97.  
  98.      7.     LCP Configuration Options .............................   42
  99.         7.1       Format ..........................................   43
  100.         7.2       Maximum-Receive-Unit ............................   44
  101.         7.3       Async-Control-Character-Map .....................   45
  102.         7.4       Authentication-Protocol .........................   47
  103.         7.5       Quality-Protocol ................................   49
  104.         7.6       Magic-Number ....................................   51
  105.  
  106.  
  107.  
  108. Simpson                                                        [Page ii]
  109.  
  110. RFC 1331                Point-to-Point Protocol                 May 1992
  111.  
  112.  
  113.         7.7       Protocol-Field-Compression ......................   54
  114.         7.8       Address-and-Control-Field-Compression ...........   56
  115.  
  116.      APPENDICES ...................................................   58
  117.  
  118.      A.     Asynchronous HDLC .....................................   58
  119.  
  120.      B.     Fast Frame Check Sequence (FCS) Implementation ........   61
  121.         B.1       FCS Computation Method ..........................   61
  122.         B.2       Fast FCS table generator ........................   63
  123.  
  124.      C.     LCP Recommended Options ...............................   64
  125.  
  126.      SECURITY CONSIDERATIONS ......................................   65
  127.  
  128.      REFERENCES ...................................................   65
  129.  
  130.      ACKNOWLEDGEMENTS .............................................   66
  131.  
  132.      CHAIR'S ADDRESS ..............................................   66
  133.  
  134.      AUTHOR'S ADDRESS .............................................   66
  135.  
  136.  
  137.  
  138.  
  139.  
  140.  
  141.  
  142.  
  143.  
  144.  
  145.  
  146.  
  147.  
  148.  
  149.  
  150.  
  151.  
  152.  
  153.  
  154.  
  155.  
  156.  
  157.  
  158.  
  159.  
  160.  
  161.  
  162.  
  163.  
  164. Simpson                                                       [Page iii]
  165.  
  166. RFC 1331                Point-to-Point Protocol                 May 1992
  167.  
  168.  
  169. 1.  Introduction
  170.  
  171.    Motivation
  172.  
  173.       In the last few years, the Internet has seen explosive growth in
  174.       the number of hosts supporting TCP/IP.  The vast majority of these
  175.       hosts are connected to Local Area Networks (LANs) of various
  176.       types, Ethernet being the most common.  Most of the other hosts
  177.       are connected through Wide Area Networks (WANs) such as X.25 style
  178.       Public Data Networks (PDNs).  Relatively few of these hosts are
  179.       connected with simple point-to-point (i.e., serial) links.  Yet,
  180.       point-to-point links are among the oldest methods of data
  181.       communications and almost every host supports point-to-point
  182.       connections.  For example, asynchronous RS-232-C [1] interfaces
  183.       are essentially ubiquitous.
  184.  
  185.    Encapsulation
  186.  
  187.       One reason for the small number of point-to-point IP links is the
  188.       lack of a standard encapsulation protocol.  There are plenty of
  189.       non-standard (and at least one de facto standard) encapsulation
  190.       protocols available, but there is not one which has been agreed
  191.       upon as an Internet Standard.  By contrast, standard encapsulation
  192.       schemes do exist for the transmission of datagrams over most
  193.       popular LANs.
  194.  
  195.       PPP provides an encapsulation protocol over both bit-oriented
  196.       synchronous links and asynchronous links with 8 bits of data and
  197.       no parity.  These links MUST be full-duplex, but MAY be either
  198.       dedicated or circuit-switched.  PPP uses HDLC as a basis for the
  199.       encapsulation.
  200.  
  201.       PPP has been carefully designed to retain compatibility with most
  202.       commonly used supporting hardware.  In addition, an escape
  203.       mechanism is specified to allow control data such as XON/XOFF to
  204.       be transmitted transparently over the link, and to remove spurious
  205.       control data which may be injected into the link by intervening
  206.       hardware and software.
  207.  
  208.       The PPP encapsulation also provides for multiplexing of different
  209.       network-layer protocols simultaneously over the same link.  It is
  210.       intended that PPP provide a common solution for easy connection of
  211.       a wide variety of hosts, bridges and routers.
  212.  
  213.       Some protocols expect error free transmission, and either provide
  214.       error detection only on a conditional basis, or do not provide it
  215.       at all.  PPP uses the HDLC Frame Check Sequence for error
  216.       detection.  This is commonly available in hardware
  217.  
  218.  
  219.  
  220. Simpson                                                         [Page 1]
  221.  
  222. RFC 1331                Point-to-Point Protocol                 May 1992
  223.  
  224.  
  225.       implementations, and a software implementation is provided.
  226.  
  227.       By default, only 8 additional octets are necessary to form the
  228.       encapsulation.  In environments where bandwidth is at a premium,
  229.       the encapsulation may be shortened to as few as 2 octets.  To
  230.       support high speed hardware implementations, PPP provides that the
  231.       default encapsulation header and information fields fall on 32-bit
  232.       boundaries, and allows the trailer to be padded to an arbitrary
  233.       boundary.
  234.  
  235.    Link Control Protocol
  236.  
  237.       More importantly, the Point-to-Point Protocol defines more than
  238.       just an encapsulation scheme.  In order to be sufficiently
  239.       versatile to be portable to a wide variety of environments, PPP
  240.       provides a Link Control Protocol (LCP).  The LCP is used to
  241.       automatically agree upon the encapsulation format options, handle
  242.       varying limits on sizes of packets, authenticate the identity of
  243.       its peer on the link, determine when a link is functioning
  244.       properly and when it is defunct, detect a looped-back link and
  245.       other common misconfiguration errors, and terminate the link.
  246.  
  247.    Network Control Protocols
  248.  
  249.       Point-to-Point links tend to exacerbate many problems with the
  250.       current family of network protocols.  For instance, assignment and
  251.       management of IP addresses, which is a problem even in LAN
  252.       environments, is especially difficult over circuit-switched
  253.       point-to-point links (such as dial-up modem servers).  These
  254.       problems are handled by a family of Network Control Protocols
  255.       (NCPs), which each manage the specific needs required by their
  256.       respective network-layer protocols.  These NCPs are defined in
  257.       other documents.
  258.  
  259.    Configuration
  260.  
  261.       It is intended that PPP be easy to configure.  By design, the
  262.       standard defaults should handle all common configurations.  The
  263.       implementor may specify improvements to the default configuration,
  264.       which are automatically communicated to the peer without operator
  265.       intervention.  Finally, the operator may explicitly configure
  266.       options for the link which enable the link to operate in
  267.       environments where it would otherwise be impossible.
  268.  
  269.       This self-configuration is implemented through an extensible
  270.       option negotiation mechanism, wherein each end of the link
  271.       describes to the other its capabilities and requirements.
  272.       Although the option negotiation mechanism described in this
  273.  
  274.  
  275.  
  276. Simpson                                                         [Page 2]
  277.  
  278. RFC 1331                Point-to-Point Protocol                 May 1992
  279.  
  280.  
  281.       document is specified in terms of the Link Control Protocol (LCP),
  282.       the same facilities may be used by the Internet Protocol Control
  283.       Protocol (IPCP) and others in the family of NCPs.
  284.  
  285. 1.1.  Specification of Requirements
  286.  
  287.    In this document, several words are used to signify the requirements
  288.    of the specification.  These words are often capitalized.
  289.  
  290.    MUST
  291.  
  292.       This word, or the adjective "required", means that the definition
  293.       is an absolute requirement of the specification.
  294.  
  295.    MUST NOT
  296.  
  297.       This phrase means that the definition is an absolute prohibition
  298.       of the specification.
  299.  
  300.    SHOULD
  301.  
  302.       This word, or the adjective "recommended", means that there may
  303.       exist valid reasons in particular circumstances to ignore this
  304.       item, but the full implications should be understood and carefully
  305.       weighed before choosing a different course.
  306.  
  307.    MAY
  308.  
  309.       This word, or the adjective "optional", means that this item is
  310.       one of an allowed set of alternatives.  An implementation which
  311.       does not include this option MUST be prepared to interoperate with
  312.       another implementation which does include the option.
  313.  
  314. 1.2.  Terminology
  315.  
  316.    This document frequently uses the following terms:
  317.  
  318.    peer
  319.  
  320.       The other end of the point-to-point link.
  321.  
  322.    silently discard
  323.  
  324.       This means the implementation discards the packet without further
  325.       processing.  The implementation SHOULD provide the capability of
  326.       logging the error, including the contents of the silently
  327.       discarded packet, and SHOULD record the event in a statistics
  328.       counter.
  329.  
  330.  
  331.  
  332. Simpson                                                         [Page 3]
  333.  
  334. RFC 1331                Point-to-Point Protocol                 May 1992
  335.  
  336.  
  337. 2.  Physical Layer Requirements
  338.  
  339.    The Point-to-Point Protocol is capable of operating across any
  340.    DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and
  341.    CCITT V.35).  The only absolute requirement imposed by PPP is the
  342.    provision of a full-duplex circuit, either dedicated or circuit-
  343.    switched, which can operate in either an asynchronous (start/stop) or
  344.    synchronous bit-serial mode, transparent to PPP Data Link Layer
  345.    frames.  PPP does not impose any restrictions regarding transmission
  346.    rate, other than those imposed by the particular DTE/DCE interface in
  347.    use.
  348.  
  349.    PPP does not require any particular synchronous encoding, such as FM,
  350.    NRZ, or NRZI.
  351.  
  352.    Implementation Note:
  353.  
  354.       NRZ is currently most widely available, and on that basis is
  355.       recommended as a default.  When configuration of the encoding is
  356.       allowed, NRZI is recommended as an alternative, because of its
  357.       relative immunity to signal inversion configuration errors.
  358.  
  359.    PPP does not require the use of modem control signals, such as
  360.    Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect
  361.    (DCD), and Data Terminal Ready (DTR).
  362.  
  363.    Implementation Note:
  364.  
  365.       When available, using such signals can allow greater functionality
  366.       and performance.  In particular, such signals SHOULD be used to
  367.       signal the Up and Down events in the Option Negotiation Automaton
  368.       (described below).
  369.  
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388. Simpson                                                         [Page 4]
  389.  
  390. RFC 1331                Point-to-Point Protocol                 May 1992
  391.  
  392.  
  393. 3.  The Data Link Layer
  394.  
  395.    The Point-to-Point Protocol uses the principles, terminology, and
  396.    frame structure of the International Organization For
  397.    Standardization's (ISO) High-level Data Link Control (HDLC)
  398.    procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1
  399.    "Addendum 1: Start/stop transmission" [5].  ISO 3309-1979 specifies
  400.    the HDLC frame structure for use in synchronous environments.  ISO
  401.    3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to
  402.    allow its use in asynchronous environments.
  403.  
  404.    The PPP control procedures use the definitions and Control field
  405.    encodings standardized in ISO 4335-1979 [3] and ISO 4335-
  406.    1979/Addendum 1-1979 [4].  The PPP frame structure is also consistent
  407.    with CCITT Recommendation X.25 LAPB [6], since that too is based on
  408.    HDLC.
  409.  
  410.    The purpose of this memo is not to document what is already
  411.    standardized in ISO 3309.  We assume that the reader is already
  412.    familiar with HDLC, or has access to a copy of [2] or [6].  Instead,
  413.    this paper attempts to give a concise summary and point out specific
  414.    options and features used by PPP.  Since "Addendum 1: Start/stop
  415.    transmission", is not yet standardized and widely available, it is
  416.    summarized in Appendix A.
  417.  
  418.    To remain consistent with standard Internet practice, and avoid
  419.    confusion for people used to reading RFCs, all binary numbers in the
  420.    following descriptions are in Most Significant Bit to Least
  421.    Significant Bit order, reading from left to right, unless otherwise
  422.    indicated.  Note that this is contrary to standard ISO and CCITT
  423.    practice which orders bits as transmitted (i.e., network bit order).
  424.    Keep this in mind when comparing this document with the international
  425.    standards documents.
  426.  
  427.  
  428.  
  429.  
  430.  
  431.  
  432.  
  433.  
  434.  
  435.  
  436.  
  437.  
  438.  
  439.  
  440.  
  441.  
  442.  
  443.  
  444. Simpson                                                         [Page 5]
  445.  
  446. RFC 1331                Point-to-Point Protocol                 May 1992
  447.  
  448.  
  449. 3.1.  Frame Format
  450.  
  451.    A summary of the standard PPP frame structure is shown below.  This
  452.    figure does not include start/stop bits (for asynchronous links), nor
  453.    any bits or octets inserted for transparency.  The fields are
  454.    transmitted from left to right.
  455.  
  456.            +----------+----------+----------+----------+------------
  457.            |   Flag   | Address  | Control  | Protocol | Information
  458.            | 01111110 | 11111111 | 00000011 | 16 bits  |      *
  459.            +----------+----------+----------+----------+------------
  460.                    ---+----------+----------+-----------------
  461.                       |   FCS    |   Flag   | Inter-frame Fill
  462.                       | 16 bits  | 01111110 | or next Address
  463.                    ---+----------+----------+-----------------
  464.  
  465.    Inter-frame Time Fill
  466.  
  467.    For asynchronous links, inter-frame time fill SHOULD be accomplished
  468.    in the same manner as inter-octet time fill, by transmitting
  469.    continuous "1" bits (mark-hold state).
  470.  
  471.    For synchronous links, the Flag Sequence SHOULD be transmitted during
  472.    inter-frame time fill.  There is no provision for inter-octet time
  473.    fill.
  474.  
  475.    Implementation Note:
  476.  
  477.       Mark idle (continuous ones) SHOULD NOT be used for idle
  478.       synchronous inter-frame time fill.  However, certain types of
  479.       circuit-switched links require the use of mark idle, particularly
  480.       those that calculate accounting based on bit activity.  When mark
  481.       idle is used on a synchronous link, the implementation MUST ensure
  482.       at least 15 consecutive "1" bits between Flags, and that the Flag
  483.       Sequence is generated at the beginning and end of a frame.
  484.  
  485. Flag Sequence
  486.  
  487.    The Flag Sequence is a single octet and indicates the beginning or
  488.    end of a frame.  The Flag Sequence consists of the binary sequence
  489.    01111110 (hexadecimal 0x7e).
  490.  
  491.    The Flag is a frame separator.  Only one Flag is required between two
  492.    frames.  Two consecutive Flags constitute an empty frame, which is
  493.    ignored.
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500. Simpson                                                         [Page 6]
  501.  
  502. RFC 1331                Point-to-Point Protocol                 May 1992
  503.  
  504.  
  505.    Implementation Note:
  506.  
  507.       The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
  508.       be used.  When not avoidable, such an implementation MUST ensure
  509.       that the first Flag Sequence detected (the end of the frame) is
  510.       promptly communicated to the link layer.
  511.  
  512. Address Field
  513.  
  514.    The Address field is a single octet and contains the binary sequence
  515.    11111111 (hexadecimal 0xff), the All-Stations address.  PPP does not
  516.    assign individual station addresses.  The All-Stations address MUST
  517.    always be recognized and received.  The use of other address lengths
  518.    and values may be defined at a later time, or by prior agreement.
  519.    Frames with unrecognized Addresses SHOULD be silently discarded, and
  520.    reported through the normal network management facility.
  521.  
  522. Control Field
  523.  
  524.    The Control field is a single octet and contains the binary sequence
  525.    00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command
  526.    with the P/F bit set to zero.  Frames with other Control field values
  527.    SHOULD be silently discarded.
  528.  
  529. Protocol Field
  530.  
  531.    The Protocol field is two octets and its value identifies the
  532.    protocol encapsulated in the Information field of the frame.
  533.  
  534.    This Protocol field is defined by PPP and is not a field defined by
  535.    HDLC.  However, the Protocol field is consistent with the ISO 3309
  536.    extension mechanism for Address fields.  All Protocols MUST be odd;
  537.    the least significant bit of the least significant octet MUST equal
  538.    "1".  Also, all Protocols MUST be assigned such that the least
  539.    significant bit of the most significant octet equals "0".  Frames
  540.    received which don't comply with these rules MUST be considered as
  541.    having an unrecognized Protocol, and handled as specified by the LCP.
  542.    The Protocol field is transmitted and received most significant octet
  543.    first.
  544.  
  545.    Protocol field values in the "0---" to "3---" range identify the
  546.    network-layer protocol of specific datagrams, and values in the "8--
  547.    -" to "b---" range identify datagrams belonging to the associated
  548.    Network Control Protocols (NCPs), if any.
  549.  
  550.    Protocol field values in the "4---" to "7---" range are used for
  551.    protocols with low volume traffic which have no associated NCP.
  552.    Protocol field values in the "c---" to "f---" range identify
  553.  
  554.  
  555.  
  556. Simpson                                                         [Page 7]
  557.  
  558. RFC 1331                Point-to-Point Protocol                 May 1992
  559.  
  560.  
  561.    datagrams as link-layer Control Protocols (such as LCP).
  562.  
  563.    The most up-to-date values of the Protocol field are specified in the
  564.    most recent "Assigned Numbers" RFC [11].  Current values are assigned
  565.    as follows:
  566.  
  567.       Value (in hex)  Protocol Name
  568.  
  569.       0001 to 001f    reserved (transparency inefficient)
  570.       0021            Internet Protocol
  571.       0023            OSI Network Layer
  572.       0025            Xerox NS IDP
  573.       0027            DECnet Phase IV
  574.       0029            Appletalk
  575.       002b            Novell IPX
  576.       002d            Van Jacobson Compressed TCP/IP
  577.       002f            Van Jacobson Uncompressed TCP/IP
  578.       0031            Bridging PDU
  579.       0033            Stream Protocol (ST-II)
  580.       0035            Banyan Vines
  581.       0037            reserved (until 1993)
  582.       00ff            reserved (compression inefficient)
  583.  
  584.       0201            802.1d Hello Packets
  585.       0231            Luxcom
  586.       0233            Sigma Network Systems
  587.  
  588.       8021            Internet Protocol Control Protocol
  589.       8023            OSI Network Layer Control Protocol
  590.       8025            Xerox NS IDP Control Protocol
  591.       8027            DECnet Phase IV Control Protocol
  592.       8029            Appletalk Control Protocol
  593.       802b            Novell IPX Control Protocol
  594.       802d            Reserved
  595.       802f            Reserved
  596.       8031            Bridging NCP
  597.       8033            Stream Protocol Control Protocol
  598.       8035            Banyan Vines Control Protocol
  599.  
  600.       c021            Link Control Protocol
  601.       c023            Password Authentication Protocol
  602.       c025            Link Quality Report
  603.       c223            Challenge Handshake Authentication Protocol
  604.  
  605.    Developers of new protocols MUST obtain a number from the Internet
  606.    Assigned Numbers Authority (IANA), at IANA@isi.edu.
  607.  
  608.  
  609.  
  610.  
  611.  
  612. Simpson                                                         [Page 8]
  613.  
  614. RFC 1331                Point-to-Point Protocol                 May 1992
  615.  
  616.  
  617. Information Field
  618.  
  619.    The Information field is zero or more octets.  The Information field
  620.    contains the datagram for the protocol specified in the Protocol
  621.    field.  The end of the Information field is found by locating the
  622.    closing Flag Sequence and allowing two octets for the Frame Check
  623.    Sequence field.  The default maximum length of the Information field
  624.    is 1500 octets.  By negotiation, consenting PPP implementations may
  625.    use other values for the maximum Information field length.
  626.  
  627.    On transmission, the Information field may be padded with an
  628.    arbitrary number of octets up to the maximum length.  It is the
  629.    responsibility of each protocol to disambiguate padding octets from
  630.    real information.
  631.  
  632. Frame Check Sequence (FCS) Field
  633.  
  634.    The Frame Check Sequence field is normally 16 bits (two octets).  The
  635.    use of other FCS lengths may be defined at a later time, or by prior
  636.    agreement.
  637.  
  638.    The FCS field is calculated over all bits of the Address, Control,
  639.    Protocol and Information fields not including any start and stop bits
  640.    (asynchronous) and any bits (synchronous) or octets (asynchronous)
  641.    inserted for transparency.  This does not include the Flag Sequences
  642.    or the FCS field itself.  The FCS is transmitted with the coefficient
  643.    of the highest term first.
  644.  
  645.       Note: When octets are received which are flagged in the Async-
  646.       Control-Character-Map, they are discarded before calculating the
  647.       FCS.  See the description in Appendix A.
  648.  
  649.    For more information on the specification of the FCS, see ISO 3309
  650.    [2] or CCITT X.25 [6].
  651.  
  652.       Note: A fast, table-driven implementation of the 16-bit FCS
  653.       algorithm is shown in Appendix B.  This implementation is based on
  654.       [7], [8], and [9].
  655.  
  656. Modifications to the Basic Frame Format
  657.  
  658.    The Link Control Protocol can negotiate modifications to the standard
  659.    PPP frame structure.  However, modified frames will always be clearly
  660.    distinguishable from standard frames.
  661.  
  662.  
  663.  
  664.  
  665.  
  666.  
  667.  
  668. Simpson                                                         [Page 9]
  669.  
  670. RFC 1331                Point-to-Point Protocol                 May 1992
  671.  
  672.  
  673. 4.  PPP Link Operation
  674.  
  675. 4.1.  Overview
  676.  
  677.    In order to establish communications over a point-to-point link, each
  678.    end of the PPP link must first send LCP packets to configure and test
  679.    the data link.  After the link has been established, the peer may be
  680.    authenticated.  Then, PPP must send NCP packets to choose and
  681.    configure one or more network-layer protocols.  Once each of the
  682.    chosen network-layer protocols has been configured, datagrams from
  683.    each network-layer protocol can be sent over the link.
  684.  
  685.    The link will remain configured for communications until explicit LCP
  686.    or NCP packets close the link down, or until some external event
  687.    occurs (an inactivity timer expires or network administrator
  688.    intervention).
  689.  
  690. 4.2.  Phase Diagram
  691.  
  692.    In the process of configuring, maintaining and terminating the
  693.    point-to-point link, the PPP link goes through several distinct
  694.    phases:
  695.  
  696.    +------+        +-----------+           +--------------+
  697.    |      | UP     |           | OPENED    |              | SUCCESS/NONE
  698.    | Dead |------->| Establish |---------->| Authenticate |--+
  699.    |      |        |           |           |              |  |
  700.    +------+        +-----------+           +--------------+  |
  701.       ^          FAIL |                   FAIL |             |
  702.       +<--------------+             +----------+             |
  703.       |                             |                        |
  704.       |            +-----------+    |           +---------+  |
  705.       |       DOWN |           |    |   CLOSING |         |  |
  706.       +------------| Terminate |<---+<----------| Network |<-+
  707.                    |           |                |         |
  708.                    +-----------+                +---------+
  709.  
  710. 4.3.  Link Dead (physical-layer not ready)
  711.  
  712.    The link necessarily begins and ends with this phase.  When an
  713.    external event (such as carrier detection or network administrator
  714.    configuration) indicates that the physical-layer is ready to be used,
  715.    PPP will proceed to the Link Establishment phase.
  716.  
  717.    During this phase, the LCP automaton (described below) will be in the
  718.    Initial or Starting states.  The transition to the Link Establishment
  719.    phase will signal an Up event to the automaton.
  720.  
  721.  
  722.  
  723.  
  724. Simpson                                                        [Page 10]
  725.  
  726. RFC 1331                Point-to-Point Protocol                 May 1992
  727.  
  728.  
  729.    Implementation Note:
  730.  
  731.       Typically, a link will return to this phase automatically after
  732.       the disconnection of a modem.  In the case of a hard-wired line,
  733.       this phase may be extremely short -- merely long enough to detect
  734.       the presence of the device.
  735.  
  736. 4.4.  Link Establishment Phase
  737.  
  738.    The Link Control Protocol (LCP) is used to establish the connection
  739.    through an exchange of Configure packets.  This exchange is complete,
  740.    and the LCP Opened state entered, once a Configure-Ack packet
  741.    (described below) has been both sent and received.  Any non-LCP
  742.    packets received during this phase MUST be silently discarded.
  743.  
  744.    All Configuration Options are assumed to be at default values unless
  745.    altered by the configuration exchange.  See the section on LCP
  746.    Configuration Options for further discussion.
  747.  
  748.    It is important to note that only Configuration Options which are
  749.    independent of particular network-layer protocols are configured by
  750.    LCP.  Configuration of individual network-layer protocols is handled
  751.    by separate Network Control Protocols (NCPs) during the Network-Layer
  752.    Protocol phase.
  753.  
  754. 4.5.  Authentication Phase
  755.  
  756.    On some links it may be desirable to require a peer to authenticate
  757.    itself before allowing network-layer protocol packets to be
  758.    exchanged.
  759.  
  760.    By default, authentication is not necessary.  If an implementation
  761.    requires that the peer authenticate with some specific authentication
  762.    protocol, then it MUST negotiate the use of that authentication
  763.    protocol during Link Establishment phase.
  764.  
  765.    Authentication SHOULD take place as soon as possible after link
  766.    establishment.  However, link quality determination MAY occur
  767.    concurrently.  An implementation MUST NOT allow the exchange of link
  768.    quality determination packets to delay authentication indefinitely.
  769.  
  770.    Advancement from the Authentication phase to the Network-Layer
  771.    Protocol phase MUST NOT occur until the peer is successfully
  772.    authenticated using the negotiated authentication protocol.  In the
  773.    event of failure to authenticate, PPP SHOULD proceed instead to the
  774.    Link Termination phase.
  775.  
  776.  
  777.  
  778.  
  779.  
  780. Simpson                                                        [Page 11]
  781.  
  782. RFC 1331                Point-to-Point Protocol                 May 1992
  783.  
  784.  
  785. 4.6.  Network-Layer Protocol Phase
  786.  
  787.    Once PPP has finished the previous phases, each network-layer
  788.    protocol (such as IP) MUST be separately configured by the
  789.    appropriate Network Control Protocol (NCP).
  790.  
  791.    Each NCP may be Opened and Closed at any time.
  792.  
  793.    Implementation Note:
  794.  
  795.       Because an implementation may initially use a significant amount
  796.       of time for link quality determination, implementations SHOULD
  797.       avoid fixed timeouts when waiting for their peers to configure a
  798.       NCP.
  799.  
  800.    After a NCP has reached the Opened state, PPP will carry the
  801.    corresponding network-layer protocol packets.  Any network-layer
  802.    protocol packets received when the corresponding NCP is not in the
  803.    Opened state SHOULD be silently discarded.
  804.  
  805.    During this phase, link traffic consists of any possible combinations
  806.    of LCP, NCP, and network-layer protocol packets.  Any NCP or
  807.    network-layer protocol packets received during any other phase SHOULD
  808.    be silently discarded.
  809.  
  810.    Implementation Note:
  811.  
  812.       There is an exception to the preceding paragraphs, due to the
  813.       availability of the LCP Protocol-Reject (described below).  While
  814.       LCP is in the Opened state, any protocol packet which is
  815.       unsupported by the implementation MUST be returned in a Protocol-
  816.       Reject.  Only supported protocols are silently discarded.
  817.  
  818. 4.7.  Link Termination Phase
  819.  
  820.    PPP may terminate the link at any time.  This will usually be done at
  821.    the request of a human user, but might happen because of a physical
  822.    event such as the loss of carrier, authentication failure, link
  823.    quality failure, or the expiration of an idle-period timer.
  824.  
  825.    LCP is used to close the link through an exchange of Terminate
  826.    packets.  When the link is closing, PPP informs the network-layer
  827.    protocols so that they may take appropriate action.
  828.  
  829.    After the exchange of Terminate packets, the implementation SHOULD
  830.    signal the physical-layer to disconnect in order to enforce the
  831.    termination of the link, particularly in the case of an
  832.    authentication failure.  The sender of the Terminate-Request SHOULD
  833.  
  834.  
  835.  
  836. Simpson                                                        [Page 12]
  837.  
  838. RFC 1331                Point-to-Point Protocol                 May 1992
  839.  
  840.  
  841.    disconnect after receiving a Terminate-Ack, or after the Restart
  842.    counter expires.  The receiver of a Terminate-Request SHOULD wait for
  843.    the peer to disconnect, and MUST NOT disconnect until at least one
  844.    Restart time has passed after sending a Terminate-Ack.  PPP SHOULD
  845.    proceed to the Link Dead phase.
  846.  
  847.    Implementation Note:
  848.  
  849.       The closing of the link by LCP is sufficient.  There is no need
  850.       for each NCP to send a flurry of Terminate packets.  Conversely,
  851.       the fact that a NCP has Closed is not sufficient reason to cause
  852.       the termination of the PPP link, even if that NCP was the only
  853.       currently NCP in the Opened state.
  854.  
  855.  
  856.  
  857.  
  858.  
  859.  
  860.  
  861.  
  862.  
  863.  
  864.  
  865.  
  866.  
  867.  
  868.  
  869.  
  870.  
  871.  
  872.  
  873.  
  874.  
  875.  
  876.  
  877.  
  878.  
  879.  
  880.  
  881.  
  882.  
  883.  
  884.  
  885.  
  886.  
  887.  
  888.  
  889.  
  890.  
  891.  
  892. Simpson                                                        [Page 13]
  893.  
  894. RFC 1331                Point-to-Point Protocol                 May 1992
  895.  
  896.  
  897. 5.  The Option Negotiation Automaton
  898.  
  899.    The finite-state automaton is defined by events, actions and state
  900.    transitions.  Events include reception of external commands such as
  901.    Open and Close, expiration of the Restart timer, and reception of
  902.    packets from a peer.  Actions include the starting of the Restart
  903.    timer and transmission of packets to the peer.
  904.  
  905.    Some types of packets -- Configure-Naks and Configure-Rejects, or
  906.    Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
  907.    Discard-Requests -- are not differentiated in the automaton
  908.    descriptions.  As will be described later, these packets do indeed
  909.    serve different functions.  However, they always cause the same
  910.    transitions.
  911.  
  912.    Events                                   Actions
  913.  
  914.    Up   = lower layer is Up                 tlu = This-Layer-Up
  915.    Down = lower layer is Down               tld = This-Layer-Down
  916.    Open = administrative Open               tls = This-Layer-Start
  917.    Close= administrative Close              tlf = This-Layer-Finished
  918.  
  919.    TO+  = Timeout with counter > 0          irc = initialize restart
  920.                                                   counter
  921.    TO-  = Timeout with counter expired      zrc = zero restart counter
  922.  
  923.    RCR+ = Receive-Configure-Request (Good)  scr = Send-Configure-Request
  924.    RCR- = Receive-Configure-Request (Bad)
  925.    RCA  = Receive-Configure-Ack             sca = Send-Configure-Ack
  926.    RCN  = Receive-Configure-Nak/Rej         scn = Send-Configure-Nak/Rej
  927.  
  928.    RTR  = Receive-Terminate-Request         str = Send-Terminate-Request
  929.    RTA  = Receive-Terminate-Ack             sta = Send-Terminate-Ack
  930.  
  931.    RUC  = Receive-Unknown-Code              scj = Send-Code-Reject
  932.    RXJ+ = Receive-Code-Reject (permitted)
  933.        or Receive-Protocol-Reject
  934.    RXJ- = Receive-Code-Reject (catastrophic)
  935.        or Receive-Protocol-Reject
  936.    RXR  = Receive-Echo-Request              ser = Send-Echo-Reply
  937.        or Receive-Echo-Reply
  938.        or Receive-Discard-Request
  939.                                              -  = illegal action
  940.  
  941.  
  942.  
  943.  
  944.  
  945.  
  946.  
  947.  
  948. Simpson                                                        [Page 14]
  949.  
  950. RFC 1331                Point-to-Point Protocol                 May 1992
  951.  
  952.  
  953. 5.1.  State Diagram
  954.  
  955.    The simplified state diagram which follows describes the sequence of
  956.    events for reaching agreement on Configuration Options (opening the
  957.    PPP link) and for later termination of the link.
  958.  
  959.       This diagram is not a complete representation of the automaton.
  960.       Implementation MUST be done by consulting the actual state
  961.       transition table.
  962.  
  963.    Events are in upper case.  Actions are in lower case.  For these
  964.    purposes, the state machine is initially in the Closed state.  Once
  965.    the Opened state has been reached, both ends of the link have met the
  966.    requirement of having both sent and received a Configure-Ack packet.
  967.  
  968.                   RCR                    TO+
  969.                 +--sta-->+             +------->+
  970.                 |        |             |        |
  971.           +-------+      |   RTA +-------+      | Close +-------+
  972.           |       |<-----+<------|       |<-str-+<------|       |
  973.           |Closed |              |Closing|              |Opened |
  974.           |       | Open         |       |              |       |
  975.           |       |------+       |       |              |       |
  976.           +-------+      |       +-------+              +-------+
  977.                          |                                ^
  978.                          |                                |
  979.                          |         +-sca----------------->+
  980.                          |         |                      ^
  981.                  RCN,TO+ V    RCR+ |     RCR-         RCA |    RCN,TO+
  982.                 +------->+         |   +------->+         |   +--scr-->+
  983.                 |        |         |   |        |         |   |        |
  984.           +-------+      |   TO+ +-------+      |       +-------+      |
  985.           |       |<-scr-+<------|       |<-scn-+       |       |<-----+
  986.           | Req-  |              | Ack-  |              | Ack-  |
  987.           | Sent  | RCA          | Rcvd  |              | Sent  |
  988.    +-scn->|       |------------->|       |       +-sca->|       |
  989.    |      +-------+              +-------+       |      +-------+
  990.    |   RCR- |   | RCR+                           |   RCR+ |   | RCR-
  991.    |        |   +------------------------------->+<-------+   |
  992.    |        |                                                 |
  993.    +<-------+<------------------------------------------------+
  994.  
  995.  
  996.  
  997.  
  998.  
  999.  
  1000.  
  1001.  
  1002.  
  1003.  
  1004. Simpson                                                        [Page 15]
  1005.  
  1006. RFC 1331                Point-to-Point Protocol                 May 1992
  1007.  
  1008.  
  1009. 5.2.  State Transition Table
  1010.  
  1011.    The complete state transition table follows.  States are indicated
  1012.    horizontally, and events are read vertically.  State transitions and
  1013.    actions are represented in the form action/new-state.  Multiple
  1014.    actions are separated by commas, and may continue on succeeding lines
  1015.    as space requires.  The state may be followed by a letter, which
  1016.    indicates an explanatory footnote.
  1017.  
  1018.    Rationale:
  1019.  
  1020.       In previous versions of this table, a simplified non-deterministic
  1021.       finite-state automaton was used, with considerable detailed
  1022.       information specified in the semantics.  This lead to
  1023.       interoperability problems from differing interpretations.
  1024.  
  1025.       This table functions similarly to the previous versions, with the
  1026.       up/down flags expanded to explicit states, and the active/passive
  1027.       paradigm eliminated.  It is believed that this table interoperates
  1028.       with previous versions better than those versions themselves.
  1029.  
  1030.       | State
  1031.       |    0         1         2         3         4         5
  1032. Events| Initial   Starting  Closed    Stopped   Closing   Stopping
  1033. ------+-----------------------------------------------------------
  1034.  Up   |    2     irc,scr/6     -         -         -         -
  1035.  Down |    -         -         0       tls/1       0         1
  1036.  Open |  tls/1       1     irc,scr/6     3r        5r        5r
  1037.  Close|    0         0         2         2         4         4
  1038.       |
  1039.   TO+ |    -         -         -         -       str/4     str/5
  1040.   TO- |    -         -         -         -       tlf/2     tlf/3
  1041.       |
  1042.  RCR+ |    -         -       sta/2 irc,scr,sca/8   4         5
  1043.  RCR- |    -         -       sta/2 irc,scr,scn/6   4         5
  1044.  RCA  |    -         -       sta/2     sta/3       4         5
  1045.  RCN  |    -         -       sta/2     sta/3       4         5
  1046.       |
  1047.  RTR  |    -         -       sta/2     sta/3     sta/4     sta/5
  1048.  RTA  |    -         -         2         3       tlf/2     tlf/3
  1049.       |
  1050.  RUC  |    -         -       scj/2     scj/3     scj/4     scj/5
  1051.  RXJ+ |    -         -         2         3         4         5
  1052.  RXJ- |    -         -       tlf/2     tlf/3     tlf/2     tlf/3
  1053.       |
  1054.  RXR  |    -         -         2         3         4         5
  1055.  
  1056.  
  1057.  
  1058.  
  1059.  
  1060. Simpson                                                        [Page 16]
  1061.  
  1062. RFC 1331                Point-to-Point Protocol                 May 1992
  1063.  
  1064.  
  1065.       | State
  1066.       |    6         7         8           9
  1067. Events| Req-Sent  Ack-Rcvd  Ack-Sent    Opened
  1068. ------+-----------------------------------------
  1069.  Up   |    -         -         -           -
  1070.  Down |    1         1         1         tld/1
  1071.  Open |    6         7         8           9r
  1072.  Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
  1073.       |
  1074.   TO+ |  scr/6     scr/6     scr/8         -
  1075.   TO- |  tlf/3p    tlf/3p    tlf/3p        -
  1076.       |
  1077.  RCR+ |  sca/8   sca,tlu/9   sca/8   tld,scr,sca/8
  1078.  RCR- |  scn/6     scn/7     scn/6   tld,scr,scn/6
  1079.  RCA  |  irc/7     scr/6x  irc,tlu/9   tld,scr/6x
  1080.  RCN  |irc,scr/6   scr/6x  irc,scr/8   tld,scr/6x
  1081.       |
  1082.  RTR  |  sta/6     sta/6     sta/6   tld,zrc,sta/5
  1083.  RTA  |    6         6         8       tld,scr/6
  1084.       |
  1085.  RUC  |  scj/6     scj/7     scj/8   tld,scj,scr/6
  1086.  RXJ+ |    6         6         8           9
  1087.  RXJ- |  tlf/3     tlf/3     tlf/3   tld,irc,str/5
  1088.       |
  1089.  RXR  |    6         7         8         ser/9
  1090.  
  1091.    The states in which the Restart timer is running are identifiable by
  1092.    the presence of TO events.  Only the Send-Configure-Request, Send-
  1093.    Terminate-Request and Zero-Restart-Counter actions start or re-start
  1094.    the Restart timer.  The Restart timer SHOULD be stopped when
  1095.    transitioning from any state where the timer is running to a state
  1096.    where the timer is not running.
  1097.  
  1098.  
  1099.    [p]   Passive option; see Stopped state discussion.
  1100.  
  1101.    [r]   Restart option; see Open event discussion.
  1102.  
  1103.    [x]   Crossed connection; see RCA event discussion.
  1104.  
  1105.  
  1106.  
  1107.  
  1108.  
  1109.  
  1110.  
  1111.  
  1112.  
  1113.  
  1114.  
  1115.  
  1116. Simpson                                                        [Page 17]
  1117.  
  1118. RFC 1331                Point-to-Point Protocol                 May 1992
  1119.  
  1120.  
  1121. 5.3.  States
  1122.  
  1123.    Following is a more detailed description of each automaton state.
  1124.  
  1125.    Initial
  1126.  
  1127.       In the Initial state, the lower layer is unavailable (Down), and
  1128.       no Open has occurred.  The Restart timer is not running in the
  1129.       Initial state.
  1130.  
  1131.    Starting
  1132.  
  1133.       The Starting state is the Open counterpart to the Initial state.
  1134.       An administrative Open has been initiated, but the lower layer is
  1135.       still unavailable (Down).  The Restart timer is not running in the
  1136.       Starting state.
  1137.  
  1138.       When the lower layer becomes available (Up), a Configure-Request
  1139.       is sent.
  1140.  
  1141.    Closed
  1142.  
  1143.       In the Closed state, the link is available (Up), but no Open has
  1144.       occurred.  The Restart timer is not running in the Closed state.
  1145.  
  1146.       Upon reception of Configure-Request packets, a Terminate-Ack is
  1147.       sent.  Terminate-Acks are silently discarded to avoid creating a
  1148.       loop.
  1149.  
  1150.    Stopped
  1151.  
  1152.       The Stopped state is the Open counterpart to the Closed state.  It
  1153.       is entered when the automaton is waiting for a Down event after
  1154.       the This-Layer-Finished action, or after sending a Terminate-Ack.
  1155.       The Restart timer is not running in the Stopped state.
  1156.  
  1157.       Upon reception of Configure-Request packets, an appropriate
  1158.       response is sent.  Upon reception of other packets, a Terminate-
  1159.       Ack is sent.  Terminate-Acks are silently discarded to avoid
  1160.       creating a loop.
  1161.  
  1162.       Rationale:
  1163.  
  1164.          The Stopped state is a junction state for link termination,
  1165.          link configuration failure, and other automaton failure modes.
  1166.          These potentially separate states have been combined.
  1167.  
  1168.          There is a race condition between the Down event response (from
  1169.  
  1170.  
  1171.  
  1172. Simpson                                                        [Page 18]
  1173.  
  1174. RFC 1331                Point-to-Point Protocol                 May 1992
  1175.  
  1176.  
  1177.          the This-Layer-Finished action) and the Receive-Configure-
  1178.          Request event.  When a Configure-Request arrives before the
  1179.          Down event, the Down event will supercede by returning the
  1180.          automaton to the Starting state.  This prevents attack by
  1181.          repetition.
  1182.  
  1183.       Implementation Option:
  1184.  
  1185.          After the peer fails to respond to Configure-Requests, an
  1186.          implementation MAY wait passively for the peer to send
  1187.          Configure-Requests.  In this case, the This-Layer-Finished
  1188.          action is not used for the TO- event in states Req-Sent, Ack-
  1189.          Rcvd and Ack-Sent.
  1190.  
  1191.          This option is useful for dedicated circuits, or circuits which
  1192.          have no status signals available, but SHOULD NOT be used for
  1193.          switched circuits.
  1194.  
  1195.    Closing
  1196.  
  1197.       In the Closing state, an attempt is made to terminate the
  1198.       connection.  A Terminate-Request has been sent and the Restart
  1199.       timer is running, but a Terminate-Ack has not yet been received.
  1200.  
  1201.       Upon reception of a Terminate-Ack, the Closed state is entered.
  1202.       Upon the expiration of the Restart timer, a new Terminate-Request
  1203.       is transmitted and the Restart timer is restarted.  After the
  1204.       Restart timer has expired Max-Terminate times, this action may be
  1205.       skipped, and the Closed state may be entered.
  1206.  
  1207.    Stopping
  1208.  
  1209.       The Stopping state is the Open counterpart to the Closing state.
  1210.       A Terminate-Request has been sent and the Restart timer is
  1211.       running, but a Terminate-Ack has not yet been received.
  1212.  
  1213.       Rationale:
  1214.  
  1215.          The Stopping state provides a well defined opportunity to
  1216.          terminate a link before allowing new traffic.  After the link
  1217.          has terminated, a new configuration may occur via the Stopped
  1218.          or Starting states.
  1219.  
  1220.    Request-Sent
  1221.  
  1222.       In the Request-Sent state an attempt is made to configure the
  1223.       connection.  A Configure-Request has been sent and the Restart
  1224.       timer is running, but a Configure-Ack has not yet been received
  1225.  
  1226.  
  1227.  
  1228. Simpson                                                        [Page 19]
  1229.  
  1230. RFC 1331                Point-to-Point Protocol                 May 1992
  1231.  
  1232.  
  1233.       nor has one been sent.
  1234.  
  1235.    Ack-Received
  1236.  
  1237.       In the Ack-Received state, a Configure-Request has been sent and a
  1238.       Configure-Ack has been received.  The Restart timer is still
  1239.       running since a Configure-Ack has not yet been sent.
  1240.  
  1241.    Ack-Sent
  1242.  
  1243.       In the Ack-Sent state, a Configure-Request and a Configure-Ack
  1244.       have both been sent but a Configure-Ack has not yet been received.
  1245.       The Restart timer is always running in the Ack-Sent state.
  1246.  
  1247.    Opened
  1248.  
  1249.       In the Opened state, a Configure-Ack has been both sent and
  1250.       received.  The Restart timer is not running in the Opened state.
  1251.  
  1252.       When entering the Opened state, the implementation SHOULD signal
  1253.       the upper layers that it is now Up.  Conversely, when leaving the
  1254.       Opened state, the implementation SHOULD signal the upper layers
  1255.       that it is now Down.
  1256.  
  1257. 5.4.  Events
  1258.  
  1259.    Transitions and actions in the automaton are caused by events.
  1260.  
  1261.    Up
  1262.  
  1263.       The Up event occurs when a lower layer indicates that it is ready
  1264.       to carry packets.  Typically, this event is used to signal LCP
  1265.       that the link is entering Link Establishment phase, or used to
  1266.       signal a NCP that the link is entering Network-Layer Protocol
  1267.       phase.
  1268.  
  1269.    Down
  1270.  
  1271.       The Down event occurs when a lower layer indicates that it is no
  1272.       longer ready to carry packets.  Typically, this event is used to
  1273.       signal LCP that the link is entering Link Dead phase, or used to
  1274.       signal a NCP that the link is leaving Network-Layer Protocol
  1275.       phase.
  1276.  
  1277.    Open
  1278.  
  1279.       The Open event indicates that the link is administratively
  1280.       available for traffic; that is, the network administrator (human
  1281.  
  1282.  
  1283.  
  1284. Simpson                                                        [Page 20]
  1285.  
  1286. RFC 1331                Point-to-Point Protocol                 May 1992
  1287.  
  1288.  
  1289.       or program) has indicated that the link is allowed to be Opened.
  1290.       When this event occurs, and the link is not in the Opened state,
  1291.       the automaton attempts to send configuration packets to the peer.
  1292.  
  1293.       If the automaton is not able to begin configuration (the lower
  1294.       layer is Down, or a previous Close event has not completed), the
  1295.       establishment of the link is automatically delayed.
  1296.  
  1297.       When a Terminate-Request is received, or other events occur which
  1298.       cause the link to become unavailable, the automaton will progress
  1299.       to a state where the link is ready to re-open.  No additional
  1300.       administrative intervention should be necessary.
  1301.  
  1302.       Implementation Note:
  1303.  
  1304.          Experience has shown that users will execute an additional Open
  1305.          command when they want to renegotiate the link.  Since this is
  1306.          not the meaning of the Open event, it is suggested that when an
  1307.          Open user command is executed in the Opened, Closing, Stopping,
  1308.          or Stopped states, the implementation issue a Down event,
  1309.          immediately followed by an Up event.  This will cause the
  1310.          renegotiation of the link, without any harmful side effects.
  1311.  
  1312.    Close
  1313.  
  1314.       The Close event indicates that the link is not available for
  1315.       traffic; that is, the network administrator (human or program) has
  1316.       indicated that the link is not allowed to be Opened.  When this
  1317.       event occurs, and the link is not in the Closed state, the
  1318.       automaton attempts to terminate the connection.  Futher attempts
  1319.       to re-configure the link are denied until a new Open event occurs.
  1320.  
  1321.    Timeout (TO+,TO-)
  1322.  
  1323.       This event indicates the expiration of the Restart timer.  The
  1324.       Restart timer is used to time responses to Configure-Request and
  1325.       Terminate-Request packets.
  1326.  
  1327.       The TO+ event indicates that the Restart counter continues to be
  1328.       greater than zero, which triggers the corresponding Configure-
  1329.       Request or Terminate-Request packet to be retransmitted.
  1330.  
  1331.       The TO- event indicates that the Restart counter is not greater
  1332.       than zero, and no more packets need to be retransmitted.
  1333.  
  1334.    Receive-Configure-Request (RCR+,RCR-)
  1335.  
  1336.       This event occurs when a Configure-Request packet is received from
  1337.  
  1338.  
  1339.  
  1340. Simpson                                                        [Page 21]
  1341.  
  1342. RFC 1331                Point-to-Point Protocol                 May 1992
  1343.  
  1344.  
  1345.       the peer.  The Configure-Request packet indicates the desire to
  1346.       open a connection and may specify Configuration Options.  The
  1347.       Configure-Request packet is more fully described in a later
  1348.       section.
  1349.  
  1350.       The RCR+ event indicates that the Configure-Request was
  1351.       acceptable, and triggers the transmission of a corresponding
  1352.       Configure-Ack.
  1353.  
  1354.       The RCR- event indicates that the Configure-Request was
  1355.       unacceptable, and triggers the transmission of a corresponding
  1356.       Configure-Nak or Configure-Reject.
  1357.  
  1358.       Implementation Note:
  1359.  
  1360.          These events may occur on a connection which is already in the
  1361.          Opened state.  The implementation MUST be prepared to
  1362.          immediately renegotiate the Configuration Options.
  1363.  
  1364.    Receive-Configure-Ack (RCA)
  1365.  
  1366.       The Receive-Configure-Ack event occurs when a valid Configure-Ack
  1367.       packet is received from the peer.  The Configure-Ack packet is a
  1368.       positive response to a Configure-Request packet.  An out of
  1369.       sequence or otherwise invalid packet is silently discarded.
  1370.  
  1371.       Implementation Note:
  1372.  
  1373.          Since the correct packet has already been received before
  1374.          reaching the Ack-Rcvd or Opened states, it is extremely
  1375.          unlikely that another such packet will arrive.  As specified,
  1376.          all invalid Ack/Nak/Rej packets are silently discarded, and do
  1377.          not affect the transitions of the automaton.
  1378.  
  1379.          However, it is not impossible that a correctly formed packet
  1380.          will arrive through a coincidentally-timed cross-connection.
  1381.          It is more likely to be the result of an implementation error.
  1382.          At the very least, this occurance should be logged.
  1383.  
  1384.    Receive-Configure-Nak/Rej (RCN)
  1385.  
  1386.       This event occurs when a valid Configure-Nak or Configure-Reject
  1387.       packet is received from the peer.  The Configure-Nak and
  1388.       Configure-Reject packets are negative responses to a Configure-
  1389.       Request packet.  An out of sequence or otherwise invalid packet is
  1390.       silently discarded.
  1391.  
  1392.  
  1393.  
  1394.  
  1395.  
  1396. Simpson                                                        [Page 22]
  1397.  
  1398. RFC 1331                Point-to-Point Protocol                 May 1992
  1399.  
  1400.  
  1401.       Implementation Note:
  1402.  
  1403.          Although the Configure-Nak and Configure-Reject cause the same
  1404.          state transition in the automaton, these packets have
  1405.          significantly different effects on the Configuration Options
  1406.          sent in the resulting Configure-Request packet.
  1407.  
  1408.    Receive-Terminate-Request (RTR)
  1409.  
  1410.       The Receive-Terminate-Request event occurs when a Terminate-
  1411.       Request packet is received.  The Terminate-Request packet
  1412.       indicates the desire of the peer to close the connection.
  1413.  
  1414.       Implementation Note:
  1415.  
  1416.          This event is not identical to the Close event (see above), and
  1417.          does not override the Open commands of the local network
  1418.          administrator.  The implementation MUST be prepared to receive
  1419.          a new Configure-Request without network administrator
  1420.          intervention.
  1421.  
  1422.    Receive-Terminate-Ack (RTA)
  1423.  
  1424.       The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
  1425.       is received from the peer.  The Terminate-Ack packet is usually a
  1426.       response to a Terminate-Request packet.  The Terminate-Ack packet
  1427.       may also indicate that the peer is in Closed or Stopped states,
  1428.       and serves to re-synchronize the link configuration.
  1429.  
  1430.    Receive-Unknown-Code (RUC)
  1431.  
  1432.       The Receive-Unknown-Code event occurs when an un-interpretable
  1433.       packet is received from the peer.  A Code-Reject packet is sent in
  1434.       response.
  1435.  
  1436.    Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)
  1437.  
  1438.       This event occurs when a Code-Reject or a Protocol-Reject packet
  1439.       is received from the peer.
  1440.  
  1441.       The RXJ+ event arises when the rejected value is acceptable, such
  1442.       as a Code-Reject of an extended code, or a Protocol-Reject of a
  1443.       NCP.  These are within the scope of normal operation.  The
  1444.       implementation MUST stop sending the offending packet type.
  1445.  
  1446.       The RXJ- event arises when the rejected value is catastrophic,
  1447.       such as a Code-Reject of Configure-Request, or a Protocol-Reject
  1448.       of LCP!  This event communicates an unrecoverable error that
  1449.  
  1450.  
  1451.  
  1452. Simpson                                                        [Page 23]
  1453.  
  1454. RFC 1331                Point-to-Point Protocol                 May 1992
  1455.  
  1456.  
  1457.       terminates the connection.
  1458.  
  1459.    Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request
  1460.    (RXR)
  1461.  
  1462.       This event occurs when an Echo-Request, Echo-Reply or Discard-
  1463.       Request packet is received from the peer.  The Echo-Reply packet
  1464.       is a response to a Echo-Request packet.  There is no reply to an
  1465.       Echo-Reply or Discard-Request packet.
  1466.  
  1467. 5.5.  Actions
  1468.  
  1469.    Actions in the automaton are caused by events and typically indicate
  1470.    the transmission of packets and/or the starting or stopping of the
  1471.    Restart timer.
  1472.  
  1473.    Illegal-Event (-)
  1474.  
  1475.       This indicates an event that SHOULD NOT occur.  The implementation
  1476.       probably has an internal error.
  1477.  
  1478.    This-Layer-Up (tlu)
  1479.  
  1480.       This action indicates to the upper layers that the automaton is
  1481.       entering the Opened state.
  1482.  
  1483.       Typically, this action MAY be used by the LCP to signal the Up
  1484.       event to a NCP, Authentication Protocol, or Link Quality Protocol,
  1485.       or MAY be used by a NCP to indicate that the link is available for
  1486.       its traffic.
  1487.  
  1488.    This-Layer-Down (tld)
  1489.  
  1490.       This action indicates to the upper layers that the automaton is
  1491.       leaving the Opened state.
  1492.  
  1493.       Typically, this action MAY be used by the LCP to signal the Down
  1494.       event to a NCP, Authentication Protocol, or Link Quality Protocol,
  1495.       or MAY be used by a NCP to indicate that the link is no longer
  1496.       available for its traffic.
  1497.  
  1498.    This-Layer-Start (tls)
  1499.  
  1500.       This action indicates to the lower layers that the automaton is
  1501.       entering the Starting state, and the lower layer is needed for the
  1502.       link.  The lower layer SHOULD respond with an Up event when the
  1503.       lower layer is available.
  1504.  
  1505.  
  1506.  
  1507.  
  1508. Simpson                                                        [Page 24]
  1509.  
  1510. RFC 1331                Point-to-Point Protocol                 May 1992
  1511.  
  1512.  
  1513.       This action is highly implementation dependent.
  1514.  
  1515.    This-Layer-Finished (tlf)
  1516.  
  1517.       This action indicates to the lower layers that the automaton is
  1518.       entering the Stopped or Closed states, and the lower layer is no
  1519.       longer needed for the link.  The lower layer SHOULD respond with a
  1520.       Down event when the lower layer has terminated.
  1521.  
  1522.       Typically, this action MAY be used by the LCP to advance to the
  1523.       Link Dead phase, or MAY be used by a NCP to indicate to the LCP
  1524.       that the link may terminate when there are no other NCPs open.
  1525.  
  1526.       This action is highly implementation dependent.
  1527.  
  1528.    Initialize-Restart-Counter (irc)
  1529.  
  1530.       This action sets the Restart counter to the appropriate value
  1531.       (Max-Terminate or Max-Configure).  The counter is decremented for
  1532.       each transmission, including the first.
  1533.  
  1534.    Zero-Restart-Counter (zrc)
  1535.  
  1536.       This action sets the Restart counter to zero.
  1537.  
  1538.       Implementation Note:
  1539.  
  1540.          This action enables the FSA to pause before proceeding to the
  1541.          desired final state.  In addition to zeroing the Restart
  1542.          counter, the implementation MUST set the timeout period to an
  1543.          appropriate value.
  1544.  
  1545.    Send-Configure-Request (scr)
  1546.  
  1547.       The Send-Configure-Request action transmits a Configure-Request
  1548.       packet.  This indicates the desire to open a connection with a
  1549.       specified set of Configuration Options.  The Restart timer is
  1550.       started when the Configure-Request packet is transmitted, to guard
  1551.       against packet loss.  The Restart counter is decremented each time
  1552.       a Configure-Request is sent.
  1553.  
  1554.    Send-Configure-Ack (sca)
  1555.  
  1556.       The Send-Configure-Ack action transmits a Configure-Ack packet.
  1557.       This acknowledges the reception of a Configure-Request packet with
  1558.       an acceptable set of Configuration Options.
  1559.  
  1560.  
  1561.  
  1562.  
  1563.  
  1564. Simpson                                                        [Page 25]
  1565.  
  1566. RFC 1331                Point-to-Point Protocol                 May 1992
  1567.  
  1568.  
  1569.    Send-Configure-Nak (scn)
  1570.  
  1571.       The Send-Configure-Nak action transmits a Configure-Nak or
  1572.       Configure-Reject packet, as appropriate.  This negative response
  1573.       reports the reception of a Configure-Request packet with an
  1574.       unacceptable set of Configuration Options.  Configure-Nak packets
  1575.       are used to refuse a Configuration Option value, and to suggest a
  1576.       new, acceptable value.  Configure-Reject packets are used to
  1577.       refuse all negotiation about a Configuration Option, typically
  1578.       because it is not recognized or implemented.  The use of
  1579.       Configure-Nak versus Configure-Reject is more fully described in
  1580.       the section on LCP Packet Formats.
  1581.  
  1582.    Send-Terminate-Request (str)
  1583.  
  1584.       The Send-Terminate-Request action transmits a Terminate-Request
  1585.       packet.  This indicates the desire to close a connection.  The
  1586.       Restart timer is started when the Terminate-Request packet is
  1587.       transmitted, to guard against packet loss.  The Restart counter is
  1588.       decremented each time a Terminate-Request is sent.
  1589.  
  1590.    Send-Terminate-Ack (sta)
  1591.  
  1592.       The Send-Terminate-Ack action transmits a Terminate-Ack packet.
  1593.       This acknowledges the reception of a Terminate-Request packet or
  1594.       otherwise serves to synchronize the state machines.
  1595.  
  1596.    Send-Code-Reject (scj)
  1597.  
  1598.       The Send-Code-Reject action transmits a Code-Reject packet.  This
  1599.       indicates the reception of an unknown type of packet.
  1600.  
  1601.    Send-Echo-Reply (ser)
  1602.  
  1603.       The Send-Echo-Reply action transmits an Echo-Reply packet.  This
  1604.       acknowledges the reception of an Echo-Request packet.
  1605.  
  1606. 5.6.  Loop Avoidance
  1607.  
  1608.    The protocol makes a reasonable attempt at avoiding Configuration
  1609.    Option negotiation loops.  However, the protocol does NOT guarantee
  1610.    that loops will not happen.  As with any negotiation, it is possible
  1611.    to configure two PPP implementations with conflicting policies that
  1612.    will never converge.  It is also possible to configure policies which
  1613.    do converge, but which take significant time to do so.  Implementors
  1614.    should keep this in mind and should implement loop detection
  1615.    mechanisms or higher level timeouts.
  1616.  
  1617.  
  1618.  
  1619.  
  1620. Simpson                                                        [Page 26]
  1621.  
  1622. RFC 1331                Point-to-Point Protocol                 May 1992
  1623.  
  1624.  
  1625. 5.7.  Counters and Timers
  1626.  
  1627. Restart Timer
  1628.  
  1629.    There is one special timer used by the automaton.  The Restart timer
  1630.    is used to time transmissions of Configure-Request and Terminate-
  1631.    Request packets.  Expiration of the Restart timer causes a Timeout
  1632.    event, and retransmission of the corresponding Configure-Request or
  1633.    Terminate-Request packet.  The Restart timer MUST be configurable,
  1634.    but MAY default to three (3) seconds.
  1635.  
  1636.    Implementation Note:
  1637.  
  1638.       The Restart timer SHOULD be based on the speed of the link.  The
  1639.       default value is designed for low speed (19,200 bps or less), high
  1640.       switching latency links (typical telephone lines).  Higher speed
  1641.       links, or links with low switching latency, SHOULD have
  1642.       correspondingly faster retransmission times.
  1643.  
  1644. Max-Terminate
  1645.  
  1646.    There is one required restart counter for Terminate-Requests.  Max-
  1647.    Terminate indicates the number of Terminate-Request packets sent
  1648.    without receiving a Terminate-Ack before assuming that the peer is
  1649.    unable to respond.  Max-Terminate MUST be configurable, but should
  1650.    default to two (2) transmissions.
  1651.  
  1652. Max-Configure
  1653.  
  1654.    A similar counter is recommended for Configure-Requests.  Max-
  1655.    Configure indicates the number of Configure-Request packets sent
  1656.    without receiving a valid Configure-Ack, Configure-Nak or Configure-
  1657.    Reject before assuming that the peer is unable to respond.  Max-
  1658.    Configure MUST be configurable, but should default to ten (10)
  1659.    transmissions.
  1660.  
  1661. Max-Failure
  1662.  
  1663.    A related counter is recommended for Configure-Nak.  Max-Failure
  1664.    indicates the number of Configure-Nak packets sent without sending a
  1665.    Configure-Ack before assuming that configuration is not converging.
  1666.    Any further Configure-Nak packets are converted to Configure-Reject
  1667.    packets.  Max-Failure MUST be configurable, but should default to ten
  1668.    (10) transmissions.
  1669.  
  1670.  
  1671.  
  1672.  
  1673.  
  1674.  
  1675.  
  1676. Simpson                                                        [Page 27]
  1677.  
  1678. RFC 1331                Point-to-Point Protocol                 May 1992
  1679.  
  1680.  
  1681. 6.  LCP Packet Formats
  1682.  
  1683.    There are three classes of LCP packets:
  1684.  
  1685.       1. Link Configuration packets used to establish and configure a
  1686.          link (Configure-Request, Configure-Ack, Configure-Nak and
  1687.          Configure-Reject).
  1688.  
  1689.       2. Link Termination packets used to terminate a link (Terminate-
  1690.          Request and Terminate-Ack).
  1691.  
  1692.       3. Link Maintenance packets used to manage and debug a link
  1693.          (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and
  1694.          Discard-Request).
  1695.  
  1696.    This document describes Version 1 of the Link Control Protocol.  In
  1697.    the interest of simplicity, there is no version field in the LCP
  1698.    packet.  If a new version of LCP is necessary in the future, the
  1699.    intention is that a new Data Link Layer Protocol field value will be
  1700.    used to differentiate Version 1 LCP from all other versions.  A
  1701.    correctly functioning Version 1 LCP implementation will always
  1702.    respond to unknown Protocols (including other versions) with an
  1703.    easily recognizable Version 1 packet, thus providing a deterministic
  1704.    fallback mechanism for implementations of other versions.
  1705.  
  1706.    Regardless of which Configuration Options are enabled, all LCP Link
  1707.    Configuration, Link Termination, and Code-Reject packets (codes 1
  1708.    through 7) are always sent in the full, standard form, as if no
  1709.    Configuration Options were enabled.  This ensures that LCP
  1710.    Configure-Request packets are always recognizable even when one end
  1711.    of the link mistakenly believes the link to be open.
  1712.  
  1713.    Exactly one Link Control Protocol packet is encapsulated in the
  1714.    Information field of PPP Data Link Layer frames where the Protocol
  1715.    field indicates type hex c021 (Link Control Protocol).
  1716.  
  1717.    A summary of the Link Control Protocol packet format is shown below.
  1718.    The fields are transmitted from left to right.
  1719.  
  1720.     0                   1                   2                   3
  1721.     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
  1722.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1723.    |     Code      |  Identifier   |            Length             |
  1724.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1725.    |    Data ...
  1726.    +-+-+-+-+
  1727.  
  1728.  
  1729.  
  1730.  
  1731.  
  1732. Simpson                                                        [Page 28]
  1733.  
  1734. RFC 1331                Point-to-Point Protocol                 May 1992
  1735.  
  1736.  
  1737.    Code
  1738.  
  1739.       The Code field is one octet and identifies the kind of LCP packet.
  1740.       When a packet is received with an invalid Code field, a Code-
  1741.       Reject packet is transmitted.
  1742.  
  1743.       The most up-to-date values of the LCP Code field are specified in
  1744.       the most recent "Assigned Numbers" RFC [11].  Current values are
  1745.       assigned as follows:
  1746.  
  1747.          1       Configure-Request
  1748.          2       Configure-Ack
  1749.          3       Configure-Nak
  1750.          4       Configure-Reject
  1751.          5       Terminate-Request
  1752.          6       Terminate-Ack
  1753.          7       Code-Reject
  1754.          8       Protocol-Reject
  1755.          9       Echo-Request
  1756.          10      Echo-Reply
  1757.          11      Discard-Request
  1758.          12      RESERVED
  1759.  
  1760.    Identifier
  1761.  
  1762.       The Identifier field is one octet and aids in matching requests
  1763.       and replies.  When a packet is received with an invalid Identifier
  1764.       field, the packet is silently discarded.
  1765.  
  1766.    Length
  1767.  
  1768.       The Length field is two octets and indicates the length of the LCP
  1769.       packet including the Code, Identifier, Length and Data fields.
  1770.       Octets outside the range of the Length field should be treated as
  1771.       Data Link Layer padding and should be ignored on reception.  When
  1772.       a packet is received with an invalid Length field, the packet is
  1773.       silently discarded.
  1774.  
  1775.    Data
  1776.  
  1777.       The Data field is zero or more octets as indicated by the Length
  1778.       field.  The format of the Data field is determined by the Code
  1779.       field.
  1780.  
  1781.  
  1782.  
  1783.  
  1784.  
  1785.  
  1786.  
  1787.  
  1788. Simpson                                                        [Page 29]
  1789.  
  1790. RFC 1331                Point-to-Point Protocol                 May 1992
  1791.  
  1792.  
  1793. 6.1.  Configure-Request
  1794.  
  1795.    Description
  1796.  
  1797.       A LCP implementation wishing to open a connection MUST transmit a
  1798.       LCP packet with the Code field set to 1 (Configure-Request) and
  1799.       the Options field filled with any desired changes to the default
  1800.       link Configuration Options.
  1801.  
  1802.       Upon reception of a Configure-Request, an appropriate reply MUST
  1803.       be transmitted.
  1804.  
  1805.    A summary of the Configure-Request packet format is shown below.  The
  1806.    fields are transmitted from left to right.
  1807.  
  1808.     0                   1                   2                   3
  1809.     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
  1810.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1811.    |     Code      |  Identifier   |            Length             |
  1812.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1813.    | Options ...
  1814.    +-+-+-+-+
  1815.  
  1816.    Code
  1817.  
  1818.       1 for Configure-Request.
  1819.  
  1820.    Identifier
  1821.  
  1822.       The Identifier field SHOULD be changed on each transmission.  On
  1823.       reception, the Identifier field should be copied into the
  1824.       Identifier field of the appropriate reply packet.
  1825.  
  1826.    Options
  1827.  
  1828.       The options field is variable in length and contains the list of
  1829.       zero or more Configuration Options that the sender desires to
  1830.       negotiate.  All Configuration Options are always negotiated
  1831.       simultaneously.  The format of Configuration Options is further
  1832.       described in a later section.
  1833.  
  1834.  
  1835.  
  1836.  
  1837.  
  1838.  
  1839.  
  1840.  
  1841.  
  1842.  
  1843.  
  1844. Simpson                                                        [Page 30]
  1845.  
  1846. RFC 1331                Point-to-Point Protocol                 May 1992
  1847.  
  1848.  
  1849. 6.2.  Configure-Ack
  1850.  
  1851.    Description
  1852.  
  1853.       If every Configuration Option received in a Configure-Request is
  1854.       both recognizable and acceptable, then a LCP implementation should
  1855.       transmit a LCP packet with the Code field set to 2 (Configure-
  1856.       Ack), the Identifier field copied from the received Configure-
  1857.       Request, and the Options field copied from the received
  1858.       Configure-Request.  The acknowledged Configuration Options MUST
  1859.       NOT be reordered or modified in any way.
  1860.  
  1861.       On reception of a Configure-Ack, the Identifier field must match
  1862.       that of the last transmitted Configure-Request.  Additionally, the
  1863.       Configuration Options in a Configure-Ack must exactly match those
  1864.       of the last transmitted Configure-Request.  Invalid packets are
  1865.       silently discarded.
  1866.  
  1867.    A summary of the Configure-Ack packet format is shown below.  The
  1868.    fields are transmitted from left to right.
  1869.  
  1870.     0                   1                   2                   3
  1871.     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
  1872.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1873.    |     Code      |  Identifier   |            Length             |
  1874.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1875.    | Options ...
  1876.    +-+-+-+-+
  1877.  
  1878.    Code
  1879.  
  1880.       2 for Configure-Ack.
  1881.  
  1882.    Identifier
  1883.  
  1884.       The Identifier field is a copy of the Identifier field of the
  1885.       Configure-Request which caused this Configure-Ack.
  1886.  
  1887.    Options
  1888.  
  1889.       The Options field is variable in length and contains the list of
  1890.       zero or more Configuration Options that the sender is
  1891.       acknowledging.  All Configuration Options are always acknowledged
  1892.       simultaneously.
  1893.  
  1894.  
  1895.  
  1896.  
  1897.  
  1898.  
  1899.  
  1900. Simpson                                                        [Page 31]
  1901.  
  1902. RFC 1331                Point-to-Point Protocol                 May 1992
  1903.  
  1904.  
  1905. 6.3.  Configure-Nak
  1906.  
  1907.    Description
  1908.  
  1909.       If every element of the received Configuration Options is
  1910.       recognizable but some are not acceptable, then a LCP
  1911.       implementation should transmit a LCP packet with the Code field
  1912.       set to 3 (Configure-Nak), the Identifier field copied from the
  1913.       received Configure-Request, and the Options field filled with only
  1914.       the unacceptable Configuration Options from the Configure-Request.
  1915.       All acceptable Configuration Options are filtered out of the
  1916.       Configure-Nak, but otherwise the Configuration Options from the
  1917.       Configure-Request MUST NOT be reordered.
  1918.  
  1919.       Each of the Nak'd Configuration Options MUST be modified to a
  1920.       value acceptable to the Configure-Nak sender.  Options which have
  1921.       no value fields (boolean options) use the Configure-Reject reply
  1922.       instead.
  1923.  
  1924.       Finally, an implementation may be configured to request the
  1925.       negotiation of a specific option.  If that option is not listed,
  1926.       then that option may be appended to the list of Nak'd
  1927.       Configuration Options in order to request the peer to list that
  1928.       option in its next Configure-Request packet.  Any value fields for
  1929.       the option MUST indicate values acceptable to the Configure-Nak
  1930.       sender.
  1931.  
  1932.       On reception of a Configure-Nak, the Identifier field must match
  1933.       that of the last transmitted Configure-Request.  Invalid packets
  1934.       are silently discarded.
  1935.  
  1936.       Reception of a valid Configure-Nak indicates that a new
  1937.       Configure-Request MAY be sent with the Configuration Options
  1938.       modified as specified in the Configure-Nak.
  1939.  
  1940.       Some Configuration Options have a variable length.  Since the
  1941.       Nak'd Option has been modified by the peer, the implementation
  1942.       MUST be able to handle an Option length which is different from
  1943.       the original Configure-Request.
  1944.  
  1945.  
  1946.  
  1947.  
  1948.  
  1949.  
  1950.  
  1951.  
  1952.  
  1953.  
  1954.  
  1955.  
  1956. Simpson                                                        [Page 32]
  1957.  
  1958. RFC 1331                Point-to-Point Protocol                 May 1992
  1959.  
  1960.  
  1961.    A summary of the Configure-Nak packet format is shown below.  The
  1962.    fields are transmitted from left to right.
  1963.  
  1964.     0                   1                   2                   3
  1965.     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
  1966.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1967.    |     Code      |  Identifier   |            Length             |
  1968.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  1969.    | Options ...
  1970.    +-+-+-+-+
  1971.  
  1972.    Code
  1973.  
  1974.       3 for Configure-Nak.
  1975.  
  1976.    Identifier
  1977.  
  1978.       The Identifier field is a copy of the Identifier field of the
  1979.       Configure-Request which caused this Configure-Nak.
  1980.  
  1981.    Options
  1982.  
  1983.       The Options field is variable in length and contains the list of
  1984.       zero or more Configuration Options that the sender is Nak'ing.
  1985.       All Configuration Options are always Nak'd simultaneously.
  1986.  
  1987.  
  1988. 6.4.  Configure-Reject
  1989.  
  1990.    Description
  1991.  
  1992.       If some Configuration Options received in a Configure-Request are
  1993.       not recognizable or are not acceptable for negotiation (as
  1994.       configured by a network administrator), then a LCP implementation
  1995.       should transmit a LCP packet with the Code field set to 4
  1996.       (Configure-Reject), the Identifier field copied from the received
  1997.       Configure-Request, and the Options field filled with only the
  1998.       unacceptable Configuration Options from the Configure-Request.
  1999.       All recognizable and negotiable Configuration Options are filtered
  2000.       out of the Configure-Reject, but otherwise the Configuration
  2001.       Options MUST NOT be reordered or modified in any way.
  2002.  
  2003.       On reception of a Configure-Reject, the Identifier field must
  2004.       match that of the last transmitted Configure-Request.
  2005.       Additionally, the Configuration Options in a Configure-Reject must
  2006.       be a proper subset of those in the last transmitted Configure-
  2007.       Request.  Invalid packets are silently discarded.
  2008.  
  2009.  
  2010.  
  2011.  
  2012. Simpson                                                        [Page 33]
  2013.  
  2014. RFC 1331                Point-to-Point Protocol                 May 1992
  2015.  
  2016.  
  2017.       Reception of a valid Configure-Reject indicates that a new
  2018.       Configure-Request SHOULD be sent which does not include any of the
  2019.       Configuration Options listed in the Configure-Reject.
  2020.  
  2021.    A summary of the Configure-Reject packet format is shown below.  The
  2022.    fields are transmitted from left to right.
  2023.  
  2024.     0                   1                   2                   3
  2025.     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
  2026.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2027.    |     Code      |  Identifier   |            Length             |
  2028.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2029.    | Options ...
  2030.    +-+-+-+-+
  2031.  
  2032.    Code
  2033.  
  2034.       4 for Configure-Reject.
  2035.  
  2036.    Identifier
  2037.  
  2038.       The Identifier field is a copy of the Identifier field of the
  2039.       Configure-Request which caused this Configure-Reject.
  2040.  
  2041.    Options
  2042.  
  2043.       The Options field is variable in length and contains the list of
  2044.       zero or more Configuration Options that the sender is rejecting.
  2045.       All Configuration Options are always rejected simultaneously.
  2046.  
  2047.  
  2048.  
  2049.  
  2050.  
  2051.  
  2052.  
  2053.  
  2054.  
  2055.  
  2056.  
  2057.  
  2058.  
  2059.  
  2060.  
  2061.  
  2062.  
  2063.  
  2064.  
  2065.  
  2066.  
  2067.  
  2068. Simpson                                                        [Page 34]
  2069.  
  2070. RFC 1331                Point-to-Point Protocol                 May 1992
  2071.  
  2072.  
  2073. 6.5.  Terminate-Request and Terminate-Ack
  2074.  
  2075.    Description
  2076.  
  2077.       LCP includes Terminate-Request and Terminate-Ack Codes in order to
  2078.       provide a mechanism for closing a connection.
  2079.  
  2080.       A LCP implementation wishing to close a connection should transmit
  2081.       a LCP packet with the Code field set to 5 (Terminate-Request) and
  2082.       the Data field filled with any desired data.  Terminate-Request
  2083.       packets should continue to be sent until Terminate-Ack is
  2084.       received, the lower layer indicates that it has gone down, or a
  2085.       sufficiently large number have been transmitted such that the peer
  2086.       is down with reasonable certainty.
  2087.  
  2088.       Upon reception of a Terminate-Request, a LCP packet MUST be
  2089.       transmitted with the Code field set to 6 (Terminate-Ack), the
  2090.       Identifier field copied from the Terminate-Request packet, and the
  2091.       Data field filled with any desired data.
  2092.  
  2093.       Reception of an unelicited Terminate-Ack indicates that the peer
  2094.       is in the Closed or Stopped states, or is otherwise in need of
  2095.       re-negotiation.
  2096.  
  2097.    A summary of the Terminate-Request and Terminate-Ack packet formats
  2098.    is shown below.  The fields are transmitted from left to right.
  2099.  
  2100.     0                   1                   2                   3
  2101.     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
  2102.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2103.    |     Code      |  Identifier   |            Length             |
  2104.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2105.    |    Data ...
  2106.    +-+-+-+-+
  2107.  
  2108.    Code
  2109.  
  2110.       5 for Terminate-Request;
  2111.  
  2112.       6 for Terminate-Ack.
  2113.  
  2114.    Identifier
  2115.  
  2116.       The Identifier field is one octet and aids in matching requests
  2117.       and replies.
  2118.  
  2119.  
  2120.  
  2121.  
  2122.  
  2123.  
  2124. Simpson                                                        [Page 35]
  2125.  
  2126. RFC 1331                Point-to-Point Protocol                 May 1992
  2127.  
  2128.  
  2129.    Data
  2130.  
  2131.       The Data field is zero or more octets and contains uninterpreted
  2132.       data for use by the sender.  The data may consist of any binary
  2133.       value and may be of any length from zero to the peer's established
  2134.       maximum Information field length minus four.
  2135.  
  2136.  
  2137. 6.6.  Code-Reject
  2138.  
  2139.    Description
  2140.  
  2141.       Reception of a LCP packet with an unknown Code indicates that one
  2142.       of the communicating LCP implementations is faulty or incomplete.
  2143.       This error MUST be reported back to the sender of the unknown Code
  2144.       by transmitting a LCP packet with the Code field set to 7 (Code-
  2145.       Reject), and the inducing packet copied to the Rejected-
  2146.       Information field.
  2147.  
  2148.       Upon reception of a Code-Reject, the implementation SHOULD report
  2149.       the error, since it is unlikely that the situation can be
  2150.       rectified automatically.
  2151.  
  2152.    A summary of the Code-Reject packet format is shown below.  The
  2153.    fields are transmitted from left to right.
  2154.  
  2155.     0                   1                   2                   3
  2156.     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
  2157.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2158.    |     Code      |  Identifier   |            Length             |
  2159.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2160.    | Rejected-Packet ...
  2161.    +-+-+-+-+-+-+-+-+
  2162.  
  2163.    Code
  2164.  
  2165.       7 for Code-Reject.
  2166.  
  2167.    Identifier
  2168.  
  2169.       The Identifier field is one octet and is for use by the
  2170.       transmitter.
  2171.  
  2172.    Rejected-Information
  2173.  
  2174.       The Rejected-Information field contains a copy of the LCP packet
  2175.       which is being rejected.  It begins with the Information field,
  2176.       and does not include any PPP Data Link Layer headers nor the FCS.
  2177.  
  2178.  
  2179.  
  2180. Simpson                                                        [Page 36]
  2181.  
  2182. RFC 1331                Point-to-Point Protocol                 May 1992
  2183.  
  2184.  
  2185.       The Rejected-Information MUST be truncated to comply with the
  2186.       peer's established maximum Information field length.
  2187.  
  2188.  
  2189.  
  2190.  
  2191.  
  2192.  
  2193.  
  2194.  
  2195.  
  2196.  
  2197.  
  2198.  
  2199.  
  2200.  
  2201.  
  2202.  
  2203.  
  2204.  
  2205.  
  2206.  
  2207.  
  2208.  
  2209.  
  2210.  
  2211.  
  2212.  
  2213.  
  2214.  
  2215.  
  2216.  
  2217.  
  2218.  
  2219.  
  2220.  
  2221.  
  2222.  
  2223.  
  2224.  
  2225.  
  2226.  
  2227.  
  2228.  
  2229.  
  2230.  
  2231.  
  2232.  
  2233.  
  2234.  
  2235.  
  2236. Simpson                                                        [Page 37]
  2237.  
  2238. RFC 1331                Point-to-Point Protocol                 May 1992
  2239.  
  2240.  
  2241. 6.7.  Protocol-Reject
  2242.  
  2243.    Description
  2244.  
  2245.       Reception of a PPP frame with an unknown Data Link Layer Protocol
  2246.       indicates that the peer is attempting to use a protocol which is
  2247.       unsupported.  This usually occurs when the peer attempts to
  2248.       configure a new protocol.  If the LCP state machine is in the
  2249.       Opened state, then this error MUST be reported back to the peer by
  2250.       transmitting a LCP packet with the Code field set to 8 (Protocol-
  2251.       Reject), the Rejected-Protocol field set to the received Protocol,
  2252.       and the inducing packet copied to the Rejected-Information field.
  2253.  
  2254.       Upon reception of a Protocol-Reject, a LCP implementation SHOULD
  2255.       stop transmitting frames of the indicated protocol.
  2256.  
  2257.       Protocol-Reject packets may only be sent in the LCP Opened state.
  2258.       Protocol-Reject packets received in any state other than the LCP
  2259.       Opened state SHOULD be silently discarded.
  2260.  
  2261.    A summary of the Protocol-Reject packet format is shown below.  The
  2262.    fields are transmitted from left to right.
  2263.  
  2264.     0                   1                   2                   3
  2265.     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
  2266.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2267.    |     Code      |  Identifier   |            Length             |
  2268.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2269.    |       Rejected-Protocol       |      Rejected-Information ...
  2270.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2271.  
  2272.    Code
  2273.  
  2274.       8 for Protocol-Reject.
  2275.  
  2276.    Identifier
  2277.  
  2278.       The Identifier field is one octet and is for use by the
  2279.       transmitter.
  2280.  
  2281.    Rejected-Protocol
  2282.  
  2283.       The Rejected-Protocol field is two octets and contains the
  2284.       Protocol of the Data Link Layer frame which is being rejected.
  2285.  
  2286.    Rejected-Information
  2287.  
  2288.       The Rejected-Information field contains a copy from the frame
  2289.  
  2290.  
  2291.  
  2292. Simpson                                                        [Page 38]
  2293.  
  2294. RFC 1331                Point-to-Point Protocol                 May 1992
  2295.  
  2296.  
  2297.       which is being rejected.  It begins with the Information field,
  2298.       and does not include any PPP Data Link Layer headers nor the FCS.
  2299.       The Rejected-Information MUST be truncated to comply with the
  2300.       peer's established maximum Information field length.
  2301.  
  2302.  
  2303. 6.8.  Echo-Request and Echo-Reply
  2304.  
  2305.    Description
  2306.  
  2307.       LCP includes Echo-Request and Echo-Reply Codes in order to provide
  2308.       a Data Link Layer loopback mechanism for use in exercising both
  2309.       directions of the link.  This is useful as an aid in debugging,
  2310.       link quality determination, performance testing, and for numerous
  2311.       other functions.
  2312.  
  2313.       An Echo-Request sender transmits a LCP packet with the Code field
  2314.       set to 9 (Echo-Request), the Identifier field set, the local
  2315.       Magic-Number inserted, and the Data field filled with any desired
  2316.       data, up to but not exceeding the peer's established maximum
  2317.       Information field length minus eight.
  2318.  
  2319.       Upon reception of an Echo-Request, a LCP packet MUST be
  2320.       transmitted with the Code field set to 10 (Echo-Reply), the
  2321.       Identifier field copied from the received Echo-Request, the local
  2322.       Magic-Number inserted, and the Data field copied from the Echo-
  2323.       Request, truncating as necessary to avoid exceeding the peer's
  2324.       established maximum Information field length.
  2325.  
  2326.       Echo-Request and Echo-Reply packets may only be sent in the LCP
  2327.       Opened state.  Echo-Request and Echo-Reply packets received in any
  2328.       state other than the LCP Opened state SHOULD be silently
  2329.       discarded.
  2330.  
  2331.    A summary of the Echo-Request and Echo-Reply packet formats is shown
  2332.    below.  The fields are transmitted from left to right.
  2333.  
  2334.     0                   1                   2                   3
  2335.     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
  2336.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2337.    |     Code      |  Identifier   |            Length             |
  2338.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2339.    |                         Magic-Number                          |
  2340.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2341.    |    Data ...
  2342.    +-+-+-+-+
  2343.  
  2344.  
  2345.  
  2346.  
  2347.  
  2348. Simpson                                                        [Page 39]
  2349.  
  2350. RFC 1331                Point-to-Point Protocol                 May 1992
  2351.  
  2352.  
  2353.    Code
  2354.  
  2355.       9 for Echo-Request;
  2356.  
  2357.       10 for Echo-Reply.
  2358.  
  2359.    Identifier
  2360.  
  2361.       The Identifier field is one octet and aids in matching Echo-
  2362.       Requests and Echo-Replies.
  2363.  
  2364.    Magic-Number
  2365.  
  2366.       The Magic-Number field is four octets and aids in detecting links
  2367.       which are in the looped-back condition.  Unless modified by a
  2368.       Configuration Option, the Magic-Number MUST be transmitted as zero
  2369.       and MUST be ignored on reception.  See the Magic-Number
  2370.       Configuration Option for further explanation.
  2371.  
  2372.    Data
  2373.  
  2374.       The Data field is zero or more octets and contains uninterpreted
  2375.       data for use by the sender.  The data may consist of any binary
  2376.       value and may be of any length from zero to the peer's established
  2377.       maximum Information field length minus eight.
  2378.  
  2379.  
  2380. 6.9.  Discard-Request
  2381.  
  2382.    Description
  2383.  
  2384.       LCP includes a Discard-Request Code in order to provide a Data
  2385.       Link Layer data sink mechanism for use in exercising the local to
  2386.       remote direction of the link.  This is useful as an aid in
  2387.       debugging, performance testing, and for numerous other functions.
  2388.  
  2389.       A discard sender transmits a LCP packet with the Code field set to
  2390.       11 (Discard-Request) the Identifier field set, the local Magic-
  2391.       Number inserted, and the Data field filled with any desired data,
  2392.       up to but not exceeding the peer's established maximum Information
  2393.       field length minus eight.
  2394.  
  2395.       A discard receiver MUST simply throw away an Discard-Request that
  2396.       it receives.
  2397.  
  2398.       Discard-Request packets may only be sent in the LCP Opened state.
  2399.  
  2400.  
  2401.  
  2402.  
  2403.  
  2404. Simpson                                                        [Page 40]
  2405.  
  2406. RFC 1331                Point-to-Point Protocol                 May 1992
  2407.  
  2408.  
  2409.    A summary of the Discard-Request packet formats is shown below.  The
  2410.    fields are transmitted from left to right.
  2411.  
  2412.     0                   1                   2                   3
  2413.     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
  2414.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2415.    |     Code      |  Identifier   |            Length             |
  2416.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2417.    |                         Magic-Number                          |
  2418.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2419.    |    Data ...
  2420.    +-+-+-+-+
  2421.  
  2422.    Code
  2423.  
  2424.       11 for Discard-Request.
  2425.  
  2426.    Identifier
  2427.  
  2428.       The Identifier field is one octet and is for use by the Discard-
  2429.       Request transmitter.
  2430.  
  2431.    Magic-Number
  2432.  
  2433.       The Magic-Number field is four octets and aids in detecting links
  2434.       which are in the looped-back condition.  Unless modified by a
  2435.       configuration option, the Magic-Number MUST be transmitted as zero
  2436.       and MUST be ignored on reception.  See the Magic-Number
  2437.       Configuration Option for further explanation.
  2438.  
  2439.    Data
  2440.  
  2441.       The Data field is zero or more octets and contains uninterpreted
  2442.       data for use by the sender.  The data may consist of any binary
  2443.       value and may be of any length from zero to the peer's established
  2444.       maximum Information field length minus four.
  2445.  
  2446.  
  2447.  
  2448.  
  2449.  
  2450.  
  2451.  
  2452.  
  2453.  
  2454.  
  2455.  
  2456.  
  2457.  
  2458.  
  2459.  
  2460. Simpson                                                        [Page 41]
  2461.  
  2462. RFC 1331                Point-to-Point Protocol                 May 1992
  2463.  
  2464.  
  2465. 7.  LCP Configuration Options
  2466.  
  2467.    LCP Configuration Options allow modifications to the standard
  2468.    characteristics of a point-to-point link to be negotiated.
  2469.    Negotiable modifications include such things as the maximum receive
  2470.    unit, async control character mapping, the link authentication
  2471.    method, etc.  If a Configuration Option is not included in a
  2472.    Configure-Request packet, the default value for that Configuration
  2473.    Option is assumed.
  2474.  
  2475.    The end of the list of Configuration Options is indicated by the
  2476.    length of the LCP packet.
  2477.  
  2478.    Unless otherwise specified, each Configuration Option is not listed
  2479.    more than once in a Configuration Options list.  Some Configuration
  2480.    Options MAY be listed more than once.  The effect of this is
  2481.    Configuration Option specific and is specified by each such
  2482.    Configuration Option.
  2483.  
  2484.    Also unless otherwise specified, all Configuration Options apply in a
  2485.    half-duplex fashion.  When negotiated, they apply to only one
  2486.    direction of the link, typically in the receive direction when
  2487.    interpreted from the point of view of the Configure-Request sender.
  2488.  
  2489.  
  2490.  
  2491.  
  2492.  
  2493.  
  2494.  
  2495.  
  2496.  
  2497.  
  2498.  
  2499.  
  2500.  
  2501.  
  2502.  
  2503.  
  2504.  
  2505.  
  2506.  
  2507.  
  2508.  
  2509.  
  2510.  
  2511.  
  2512.  
  2513.  
  2514.  
  2515.  
  2516. Simpson                                                        [Page 42]
  2517.  
  2518. RFC 1331                Point-to-Point Protocol                 May 1992
  2519.  
  2520.  
  2521. 7.1.  Format
  2522.  
  2523.    A summary of the Configuration Option format is shown below.  The
  2524.    fields are transmitted from left to right.
  2525.  
  2526.     0                   1
  2527.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9
  2528.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2529.    |     Type      |    Length     |    Data ...
  2530.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2531.  
  2532.    Type
  2533.  
  2534.       The Type field is one octet and indicates the type of
  2535.       Configuration Option.  The most up-to-date values of the LCP
  2536.       Option Type field are specified in the most recent "Assigned
  2537.       Numbers" RFC [11].  Current values are assigned as follows:
  2538.  
  2539.          1       Maximum-Receive-Unit
  2540.          2       Async-Control-Character-Map
  2541.          3       Authentication-Protocol
  2542.          4       Quality-Protocol
  2543.          5       Magic-Number
  2544.          6       RESERVED
  2545.          7       Protocol-Field-Compression
  2546.          8       Address-and-Control-Field-Compression
  2547.  
  2548.    Length
  2549.  
  2550.       The Length field is one octet and indicates the length of this
  2551.       Configuration Option including the Type, Length and Data fields.
  2552.       If a negotiable Configuration Option is received in a Configure-
  2553.       Request but with an invalid Length, a Configure-Nak SHOULD be
  2554.       transmitted which includes the desired Configuration Option with
  2555.       an appropriate Length and Data.
  2556.  
  2557.    Data
  2558.  
  2559.       The Data field is zero or more octets and indicates the value or
  2560.       other information for this Configuration Option.  The format and
  2561.       length of the Data field is determined by the Type and Length
  2562.       fields.
  2563.  
  2564.  
  2565.  
  2566.  
  2567.  
  2568.  
  2569.  
  2570.  
  2571.  
  2572. Simpson                                                        [Page 43]
  2573.  
  2574. RFC 1331                Point-to-Point Protocol                 May 1992
  2575.  
  2576.  
  2577. 7.2.  Maximum-Receive-Unit
  2578.  
  2579.    Description
  2580.  
  2581.       This Configuration Option may be sent to inform the peer that the
  2582.       implementation can receive larger frames, or to request that the
  2583.       peer send smaller frames.  If smaller frames are requested, an
  2584.       implementation MUST still be able to receive 1500 octet frames in
  2585.       case link synchronization is lost.
  2586.  
  2587.    A summary of the Maximum-Receive-Unit Configuration Option format is
  2588.    shown below.  The fields are transmitted from left to right.
  2589.  
  2590.     0                   1                   2                   3
  2591.     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
  2592.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2593.    |     Type      |    Length     |      Maximum-Receive-Unit     |
  2594.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2595.  
  2596.    Type
  2597.  
  2598.       1
  2599.  
  2600.    Length
  2601.  
  2602.       4
  2603.  
  2604.    Maximum-Receive-Unit
  2605.  
  2606.       The Maximum-Receive-Unit field is two octets and indicates the new
  2607.       maximum receive unit.  The Maximum-Receive-Unit covers only the
  2608.       Data Link Layer Information field.  It does not include the
  2609.       header, padding, FCS, nor any transparency bits or bytes.
  2610.  
  2611.    Default
  2612.  
  2613.       1500
  2614.  
  2615.  
  2616.  
  2617.  
  2618.  
  2619.  
  2620.  
  2621.  
  2622.  
  2623.  
  2624.  
  2625.  
  2626.  
  2627.  
  2628. Simpson                                                        [Page 44]
  2629.  
  2630. RFC 1331                Point-to-Point Protocol                 May 1992
  2631.  
  2632.  
  2633. 7.3.  Async-Control-Character-Map
  2634.  
  2635.    Description
  2636.  
  2637.       This Configuration Option provides a way to negotiate the use of
  2638.       control character mapping on asynchronous links.  By default, PPP
  2639.       maps all control characters into an appropriate two character
  2640.       sequence.  However, it is rarely necessary to map all control
  2641.       characters and often it is unnecessary to map any characters.  A
  2642.       PPP implementation may use this Configuration Option to inform the
  2643.       peer which control characters must remain mapped and which control
  2644.       characters need not remain mapped when the peer sends them.  The
  2645.       peer may still send these control characters in mapped format if
  2646.       it is necessary because of constraints at the peer.
  2647.  
  2648.       There may be some use of synchronous-to-asynchronous converters
  2649.       (some built into modems) in Point-to-Point links resulting in a
  2650.       synchronous PPP implementation on one end of a link and an
  2651.       asynchronous implementation on the other.  It is the
  2652.       responsibility of the converter to do all mapping conversions
  2653.       during operation.  To enable this functionality, synchronous PPP
  2654.       implementations MUST always accept a Async-Control-Character-Map
  2655.       Configuration Option (it MUST always respond to an LCP Configure-
  2656.       Request specifying this Configuration Option with an LCP
  2657.       Configure-Ack).  However, acceptance of this Configuration Option
  2658.       does not imply that the synchronous implementation will do any
  2659.       character mapping, since synchronous PPP uses bit-stuffing rather
  2660.       than character-stuffing.  Instead, all such character mapping will
  2661.       be performed by the asynchronous-to-synchronous converter.
  2662.  
  2663.    A summary of the Async-Control-Character-Map Configuration Option
  2664.    format is shown below.  The fields are transmitted from left to
  2665.    right.
  2666.  
  2667.     0                   1                   2                   3
  2668.     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
  2669.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2670.    |     Type      |    Length     |  Async-Control-Character-Map
  2671.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2672.              ACCM (cont)           |
  2673.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2674.  
  2675.    Type
  2676.  
  2677.       2
  2678.  
  2679.  
  2680.  
  2681.  
  2682.  
  2683.  
  2684. Simpson                                                        [Page 45]
  2685.  
  2686. RFC 1331                Point-to-Point Protocol                 May 1992
  2687.  
  2688.  
  2689.    Length
  2690.  
  2691.       6
  2692.  
  2693.    Async-Control-Character-Map
  2694.  
  2695.       The Async-Control-Character-Map field is four octets and indicates
  2696.       the new async control character map.  The map is encoded in big-
  2697.       endian fashion where each numbered bit corresponds to the ASCII
  2698.       control character of the same value.  If the bit is cleared to
  2699.       zero, then that ASCII control character need not be mapped.  If
  2700.       the bit is set to one, then that ASCII control character must
  2701.       remain mapped.  E.g., if bit 19 is set to zero, then the ASCII
  2702.       control character 19 (DC3, Control-S) may be sent in the clear.
  2703.  
  2704.          Note: The bit ordering of the map is as described in section
  2705.          3.1, Most Significant Bit to Least Significant Bit.  The least
  2706.          significant bit of the least significant octet (the final octet
  2707.          transmitted) is numbered bit 0, and would map to the ASCII
  2708.          control character NUL.
  2709.  
  2710.    Default
  2711.  
  2712.       All ones (0xffffffff).
  2713.  
  2714.  
  2715.  
  2716.  
  2717.  
  2718.  
  2719.  
  2720.  
  2721.  
  2722.  
  2723.  
  2724.  
  2725.  
  2726.  
  2727.  
  2728.  
  2729.  
  2730.  
  2731.  
  2732.  
  2733.  
  2734.  
  2735.  
  2736.  
  2737.  
  2738.  
  2739.  
  2740. Simpson                                                        [Page 46]
  2741.  
  2742. RFC 1331                Point-to-Point Protocol                 May 1992
  2743.  
  2744.  
  2745. 7.4.  Authentication-Protocol
  2746.  
  2747.    Description
  2748.  
  2749.       On some links it may be desirable to require a peer to
  2750.       authenticate itself before allowing network-layer protocol packets
  2751.       to be exchanged.  This Configuration Option provides a way to
  2752.       negotiate the use of a specific authentication protocol.  By
  2753.       default, authentication is not necessary.
  2754.  
  2755.       An implementation SHOULD NOT include multiple Authentication-
  2756.       Protocol Configuration Options in its Configure-Request packets.
  2757.       Instead, it SHOULD attempt to configure the most desirable
  2758.       protocol first.  If that protocol is Rejected, then the
  2759.       implementation could attempt the next most desirable protocol in
  2760.       the next Configure-Request.
  2761.  
  2762.       An implementation receiving a Configure-Request specifying
  2763.       Authentication-Protocols MAY choose at most one of the negotiable
  2764.       authentication protocols and MUST send a Configure-Reject
  2765.       including the other specified authentication protocols.  The
  2766.       implementation MAY reject all of the proposed authentication
  2767.       protocols.
  2768.  
  2769.       If an implementation sends a Configure-Ack with this Configuration
  2770.       Option, then it is agreeing to authenticate with the specified
  2771.       protocol.  An implementation receiving a Configure-Ack with this
  2772.       Configuration Option SHOULD expect the peer to authenticate with
  2773.       the acknowledged protocol.
  2774.  
  2775.       There is no requirement that authentication be full duplex or that
  2776.       the same protocol be used in both directions.  It is perfectly
  2777.       acceptable for different protocols to be used in each direction.
  2778.       This will, of course, depend on the specific protocols negotiated.
  2779.  
  2780.    A summary of the Authentication-Protocol Configuration Option format
  2781.    is shown below.  The fields are transmitted from left to right.
  2782.  
  2783.     0                   1                   2                   3
  2784.     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
  2785.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2786.    |     Type      |    Length     |     Authentication-Protocol   |
  2787.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2788.    |    Data ...
  2789.    +-+-+-+-+
  2790.  
  2791.  
  2792.  
  2793.  
  2794.  
  2795.  
  2796. Simpson                                                        [Page 47]
  2797.  
  2798. RFC 1331                Point-to-Point Protocol                 May 1992
  2799.  
  2800.  
  2801.    Type
  2802.  
  2803.       3
  2804.  
  2805.    Length
  2806.  
  2807.       >= 4
  2808.  
  2809.    Authentication-Protocol
  2810.  
  2811.       The Authentication-Protocol field is two octets and indicates the
  2812.       authentication protocol desired.  Values for this field are always
  2813.       the same as the PPP Data Link Layer Protocol field values for that
  2814.       same authentication protocol.
  2815.  
  2816.       The most up-to-date values of the Authentication-Protocol field
  2817.       are specified in the most recent "Assigned Numbers" RFC [11].
  2818.       Current values are assigned as follows:
  2819.  
  2820.          Value (in hex)          Protocol
  2821.  
  2822.          c023                    Password Authentication Protocol
  2823.          c223                    Challenge Handshake Authentication
  2824.                                  Protocol
  2825.  
  2826.    Data
  2827.  
  2828.       The Data field is zero or more octets and contains additional data
  2829.       as determined by the particular protocol.
  2830.  
  2831. Default
  2832.  
  2833.    No authentication protocol necessary.
  2834.  
  2835.  
  2836.  
  2837.  
  2838.  
  2839.  
  2840.  
  2841.  
  2842.  
  2843.  
  2844.  
  2845.  
  2846.  
  2847.  
  2848.  
  2849.  
  2850.  
  2851.  
  2852. Simpson                                                        [Page 48]
  2853.  
  2854. RFC 1331                Point-to-Point Protocol                 May 1992
  2855.  
  2856.  
  2857. 7.5.  Quality-Protocol
  2858.  
  2859.    Description
  2860.  
  2861.       On some links it may be desirable to determine when, and how
  2862.       often, the link is dropping data.  This process is called link
  2863.       quality monitoring.
  2864.  
  2865.       This Configuration Option provides a way to negotiate the use of a
  2866.       specific protocol for link quality monitoring.  By default, link
  2867.       quality monitoring is disabled.
  2868.  
  2869.       There is no requirement that quality monitoring be full duplex or
  2870.       that the same protocol be used in both directions.  It is
  2871.       perfectly acceptable for different protocols to be used in each
  2872.       direction.  This will, of course, depend on the specific protocols
  2873.       negotiated.
  2874.  
  2875.    A summary of the Quality-Protocol Configuration Option format is
  2876.    shown below.  The fields are transmitted from left to right.
  2877.  
  2878.     0                   1                   2                   3
  2879.     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
  2880.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2881.    |     Type      |    Length     |        Quality-Protocol       |
  2882.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  2883.    |    Data ...
  2884.    +-+-+-+-+
  2885.  
  2886.    Type
  2887.  
  2888.       4
  2889.  
  2890.    Length
  2891.  
  2892.       >= 4
  2893.  
  2894.    Quality-Protocol
  2895.  
  2896.       The Quality-Protocol field is two octets and indicates the link
  2897.       quality monitoring protocol desired.  Values for this field are
  2898.       always the same as the PPP Data Link Layer Protocol field values
  2899.       for that same monitoring protocol.
  2900.  
  2901.       The most up-to-date values of the Quality-Protocol field are
  2902.       specified in the most recent "Assigned Numbers" RFC [11].  Current
  2903.       values are assigned as follows:
  2904.  
  2905.  
  2906.  
  2907.  
  2908. Simpson                                                        [Page 49]
  2909.  
  2910. RFC 1331                Point-to-Point Protocol                 May 1992
  2911.  
  2912.  
  2913.          Value (in hex)          Protocol
  2914.  
  2915.          c025                    Link Quality Report
  2916.  
  2917.    Data
  2918.  
  2919.       The Data field is zero or more octets and contains additional data
  2920.       as determined by the particular protocol.
  2921.  
  2922.    Default
  2923.  
  2924.       None
  2925.  
  2926.  
  2927.  
  2928.  
  2929.  
  2930.  
  2931.  
  2932.  
  2933.  
  2934.  
  2935.  
  2936.  
  2937.  
  2938.  
  2939.  
  2940.  
  2941.  
  2942.  
  2943.  
  2944.  
  2945.  
  2946.  
  2947.  
  2948.  
  2949.  
  2950.  
  2951.  
  2952.  
  2953.  
  2954.  
  2955.  
  2956.  
  2957.  
  2958.  
  2959.  
  2960.  
  2961.  
  2962.  
  2963.  
  2964. Simpson                                                        [Page 50]
  2965.  
  2966. RFC 1331                Point-to-Point Protocol                 May 1992
  2967.  
  2968.  
  2969. 7.6.  Magic-Number
  2970.  
  2971.    Description
  2972.  
  2973.       This Configuration Option provides a way to detect looped-back
  2974.       links and other Data Link Layer anomalies.  This Configuration
  2975.       Option MAY be required by some other Configuration Options such as
  2976.       the Monitoring-Protocol Configuration Option.
  2977.  
  2978.       Before this Configuration Option is requested, an implementation
  2979.       must choose its Magic-Number.  It is recommended that the Magic-
  2980.       Number be chosen in the most random manner possible in order to
  2981.       guarantee with very high probability that an implementation will
  2982.       arrive at a unique number.  A good way to choose a unique random
  2983.       number is to start with an unique seed.  Suggested sources of
  2984.       uniqueness include machine serial numbers, other network hardware
  2985.       addresses, time-of-day clocks, etc.  Particularly good random
  2986.       number seeds are precise measurements of the inter-arrival time of
  2987.       physical events such as packet reception on other connected
  2988.       networks, server response time, or the typing rate of a human
  2989.       user.  It is also suggested that as many sources as possible be
  2990.       used simultaneously.
  2991.  
  2992.       When a Configure-Request is received with a Magic-Number
  2993.       Configuration Option, the received Magic-Number is compared with
  2994.       the Magic-Number of the last Configure-Request sent to the peer.
  2995.       If the two Magic-Numbers are different, then the link is not
  2996.       looped-back, and the Magic-Number should be acknowledged.  If the
  2997.       two Magic-Numbers are equal, then it is possible, but not certain,
  2998.       that the link is looped-back and that this Configure-Request is
  2999.       actually the one last sent.  To determine this, a Configure-Nak
  3000.       should be sent specifying a different Magic-Number value.  A new
  3001.       Configure-Request should not be sent to the peer until normal
  3002.       processing would cause it to be sent (i.e., until a Configure-Nak
  3003.       is received or the Restart timer runs out).
  3004.  
  3005.       Reception of a Configure-Nak with a Magic-Number different from
  3006.       that of the last Configure-Nak sent to the peer proves that a link
  3007.       is not looped-back, and indicates a unique Magic-Number.  If the
  3008.       Magic-Number is equal to the one sent in the last Configure-Nak,
  3009.       the possibility of a looped-back link is increased, and a new
  3010.       Magic-Number should be chosen.  In either case, a new Configure-
  3011.       Request should be sent with the new Magic-Number.
  3012.  
  3013.       If the link is indeed looped-back, this sequence (transmit
  3014.       Configure-Request, receive Configure-Request, transmit Configure-
  3015.       Nak, receive Configure-Nak) will repeat over and over again.  If
  3016.       the link is not looped-back, this sequence might occur a few
  3017.  
  3018.  
  3019.  
  3020. Simpson                                                        [Page 51]
  3021.  
  3022. RFC 1331                Point-to-Point Protocol                 May 1992
  3023.  
  3024.  
  3025.       times, but it is extremely unlikely to occur repeatedly.  More
  3026.       likely, the Magic-Numbers chosen at either end will quickly
  3027.       diverge, terminating the sequence.  The following table shows the
  3028.       probability of collisions assuming that both ends of the link
  3029.       select Magic-Numbers with a perfectly uniform distribution:
  3030.  
  3031.          Number of Collisions        Probability
  3032.          --------------------   ---------------------
  3033.                  1              1/2**32    = 2.3 E-10
  3034.                  2              1/2**32**2 = 5.4 E-20
  3035.                  3              1/2**32**3 = 1.3 E-29
  3036.  
  3037.       Good sources of uniqueness or randomness are required for this
  3038.       divergence to occur.  If a good source of uniqueness cannot be
  3039.       found, it is recommended that this Configuration Option not be
  3040.       enabled; Configure-Requests with the option SHOULD NOT be
  3041.       transmitted and any Magic-Number Configuration Options which the
  3042.       peer sends SHOULD be either acknowledged or rejected.  In this
  3043.       case, loop-backs cannot be reliably detected by the
  3044.       implementation, although they may still be detectable by the peer.
  3045.  
  3046.       If an implementation does transmit a Configure-Request with a
  3047.       Magic-Number Configuration Option, then it MUST NOT respond with a
  3048.       Configure-Reject if its peer also transmits a Configure-Request
  3049.       with a Magic-Number Configuration Option.  That is, if an
  3050.       implementation desires to use Magic Numbers, then it MUST also
  3051.       allow its peer to do so.  If an implementation does receive a
  3052.       Configure-Reject in response to a Configure-Request, it can only
  3053.       mean that the link is not looped-back, and that its peer will not
  3054.       be using Magic-Numbers.  In this case, an implementation should
  3055.       act as if the negotiation had been successful (as if it had
  3056.       instead received a Configure-Ack).
  3057.  
  3058.       The Magic-Number also may be used to detect looped-back links
  3059.       during normal operation as well as during Configuration Option
  3060.       negotiation.  All LCP Echo-Request, Echo-Reply, and Discard-
  3061.       Request packets have a Magic-Number field which MUST normally be
  3062.       zero, and MUST normally be ignored on reception.  If Magic-Number
  3063.       has been successfully negotiated, an implementation MUST transmit
  3064.       these packets with the Magic-Number field set to its negotiated
  3065.       Magic-Number.
  3066.  
  3067.       The Magic-Number field of these packets SHOULD be inspected on
  3068.       reception.  All received Magic-Number fields MUST be equal to
  3069.       either zero or the peer's unique Magic-Number, depending on
  3070.       whether or not the peer negotiated one.
  3071.  
  3072.       Reception of a Magic-Number field equal to the negotiated local
  3073.  
  3074.  
  3075.  
  3076. Simpson                                                        [Page 52]
  3077.  
  3078. RFC 1331                Point-to-Point Protocol                 May 1992
  3079.  
  3080.  
  3081.       Magic-Number indicates a looped-back link.  Reception of a Magic-
  3082.       Number other than the negotiated local Magic-Number or the peer's
  3083.       negotiated Magic-Number, or zero if the peer didn't negotiate one,
  3084.       indicates a link which has been (mis)configured for communications
  3085.       with a different peer.
  3086.  
  3087.       Procedures for recovery from either case are unspecified and may
  3088.       vary from implementation to implementation.  A somewhat
  3089.       pessimistic procedure is to assume a LCP Down event.  A further
  3090.       Open event will begin the process of re-establishing the link,
  3091.       which can't complete until the loop-back condition is terminated
  3092.       and Magic-Numbers are successfully negotiated.  A more optimistic
  3093.       procedure (in the case of a loop-back) is to begin transmitting
  3094.       LCP Echo-Request packets until an appropriate Echo-Reply is
  3095.       received, indicating a termination of the loop-back condition.
  3096.  
  3097.    A summary of the Magic-Number Configuration Option format is shown
  3098.    below.  The fields are transmitted from left to right.
  3099.  
  3100.     0                   1                   2                   3
  3101.     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
  3102.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3103.    |     Type      |    Length     |          Magic-Number
  3104.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3105.          Magic-Number (cont)       |
  3106.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3107.  
  3108.    Type
  3109.  
  3110.       5
  3111.  
  3112.    Length
  3113.  
  3114.       6
  3115.  
  3116.    Magic-Number
  3117.  
  3118.       The Magic-Number field is four octets and indicates a number which
  3119.       is very likely to be unique to one end of the link.  A Magic-
  3120.       Number of zero is illegal and MUST always be Nak'd, if it is not
  3121.       Rejected outright.
  3122.  
  3123.    Default
  3124.  
  3125.       None.
  3126.  
  3127.  
  3128.  
  3129.  
  3130.  
  3131.  
  3132. Simpson                                                        [Page 53]
  3133.  
  3134. RFC 1331                Point-to-Point Protocol                 May 1992
  3135.  
  3136.  
  3137. 7.7.  Protocol-Field-Compression
  3138.  
  3139.    Description
  3140.  
  3141.       This Configuration Option provides a way to negotiate the
  3142.       compression of the Data Link Layer Protocol field.  By default,
  3143.       all implementations MUST transmit standard PPP frames with two
  3144.       octet Protocol fields.  However, PPP Protocol field numbers are
  3145.       chosen such that some values may be compressed into a single octet
  3146.       form which is clearly distinguishable from the two octet form.
  3147.       This Configuration Option is sent to inform the peer that the
  3148.       implementation can receive such single octet Protocol fields.
  3149.       Compressed Protocol fields MUST NOT be transmitted unless this
  3150.       Configuration Option has been negotiated.
  3151.  
  3152.       As previously mentioned, the Protocol field uses an extension
  3153.       mechanism consistent with the ISO 3309 extension mechanism for the
  3154.       Address field; the Least Significant Bit (LSB) of each octet is
  3155.       used to indicate extension of the Protocol field.  A binary "0" as
  3156.       the LSB indicates that the Protocol field continues with the
  3157.       following octet.  The presence of a binary "1" as the LSB marks
  3158.       the last octet of the Protocol field.  Notice that any number of
  3159.       "0" octets may be prepended to the field, and will still indicate
  3160.       the same value (consider the two representations for 3, 00000011
  3161.       and 00000000 00000011).
  3162.  
  3163.       In the interest of simplicity, the standard PPP frame uses this
  3164.       fact and always sends Protocol fields with a two octet
  3165.       representation.  Protocol field values less than 256 (decimal) are
  3166.       prepended with a single zero octet even though transmission of
  3167.       this, the zero and most significant octet, is unnecessary.
  3168.  
  3169.       However, when using low speed links, it is desirable to conserve
  3170.       bandwidth by sending as little redundant data as possible.  The
  3171.       Protocol Compression Configuration Option allows a trade-off
  3172.       between implementation simplicity and bandwidth efficiency.  If
  3173.       successfully negotiated, the ISO 3309 extension mechanism may be
  3174.       used to compress the Protocol field to one octet instead of two.
  3175.       The large majority of frames are compressible since data protocols
  3176.       are typically assigned with Protocol field values less than 256.
  3177.  
  3178.       In addition, PPP implementations must continue to be robust and
  3179.       MUST accept PPP frames with either double-octet or single-octet
  3180.       Protocol fields, and MUST NOT distinguish between them.
  3181.  
  3182.       The Protocol field is never compressed when sending any LCP
  3183.       packet.  This rule guarantees unambiguous recognition of LCP
  3184.       packets.
  3185.  
  3186.  
  3187.  
  3188. Simpson                                                        [Page 54]
  3189.  
  3190. RFC 1331                Point-to-Point Protocol                 May 1992
  3191.  
  3192.  
  3193.       When a Protocol field is compressed, the Data Link Layer FCS field
  3194.       is calculated on the compressed frame, not the original
  3195.       uncompressed frame.
  3196.  
  3197.    A summary of the Protocol-Field-Compression Configuration Option
  3198.    format is shown below.  The fields are transmitted from left to
  3199.    right.
  3200.  
  3201.     0                   1
  3202.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  3203.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3204.    |     Type      |    Length     |
  3205.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3206.  
  3207.    Type
  3208.  
  3209.       7
  3210.  
  3211.    Length
  3212.  
  3213.       2
  3214.  
  3215.    Default
  3216.  
  3217.       Disabled.
  3218.  
  3219.  
  3220.  
  3221.  
  3222.  
  3223.  
  3224.  
  3225.  
  3226.  
  3227.  
  3228.  
  3229.  
  3230.  
  3231.  
  3232.  
  3233.  
  3234.  
  3235.  
  3236.  
  3237.  
  3238.  
  3239.  
  3240.  
  3241.  
  3242.  
  3243.  
  3244. Simpson                                                        [Page 55]
  3245.  
  3246. RFC 1331                Point-to-Point Protocol                 May 1992
  3247.  
  3248.  
  3249. 7.8.  Address-and-Control-Field-Compression
  3250.  
  3251.    Description
  3252.  
  3253.       This Configuration Option provides a way to negotiate the
  3254.       compression of the Data Link Layer Address and Control fields.  By
  3255.       default, all implementations MUST transmit frames with Address and
  3256.       Control fields and MUST use the hexadecimal values 0xff and 0x03
  3257.       respectively.  Since these fields have constant values, they are
  3258.       easily compressed.  This Configuration Option is sent to inform
  3259.       the peer that the implementation can receive compressed Address
  3260.       and Control fields.
  3261.  
  3262.       Compressed Address and Control fields are formed by simply
  3263.       omitting them.  By definition the first octet of a two octet
  3264.       Protocol field will never be 0xff, and the Protocol field value
  3265.       0x00ff is not allowed (reserved) to avoid ambiguity.
  3266.  
  3267.       On reception, the Address and Control fields are decompressed by
  3268.       examining the first two octets.  If they contain the values 0xff
  3269.       and 0x03, they are assumed to be the Address and Control fields.
  3270.       If not, it is assumed that the fields were compressed and were not
  3271.       transmitted.
  3272.  
  3273.       If a compressed frame is received when Address-and-Control-Field-
  3274.       Compression has not been negotiated, the implementation MAY
  3275.       silently discard the frame.
  3276.  
  3277.       The Address and Control fields MUST NOT be compressed when sending
  3278.       any LCP packet.  This rule guarantees unambiguous recognition of
  3279.       LCP packets.
  3280.  
  3281.       When the Address and Control fields are compressed, the Data Link
  3282.       Layer FCS field is calculated on the compressed frame, not the
  3283.       original uncompressed frame.
  3284.  
  3285.    A summary of the Address-and-Control-Field-Compression configuration
  3286.    option format is shown below.  The fields are transmitted from left
  3287.    to right.
  3288.  
  3289.     0                   1
  3290.     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
  3291.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3292.    |     Type      |    Length     |
  3293.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  3294.  
  3295.  
  3296.  
  3297.  
  3298.  
  3299.  
  3300. Simpson                                                        [Page 56]
  3301.  
  3302. RFC 1331                Point-to-Point Protocol                 May 1992
  3303.  
  3304.  
  3305.    Type
  3306.  
  3307.       8
  3308.  
  3309.    Length
  3310.  
  3311.       2
  3312.  
  3313.    Default
  3314.  
  3315.       Not compressed.
  3316.  
  3317.  
  3318.  
  3319.  
  3320.  
  3321.  
  3322.  
  3323.  
  3324.  
  3325.  
  3326.  
  3327.  
  3328.  
  3329.  
  3330.  
  3331.  
  3332.  
  3333.  
  3334.  
  3335.  
  3336.  
  3337.  
  3338.  
  3339.  
  3340.  
  3341.  
  3342.  
  3343.  
  3344.  
  3345.  
  3346.  
  3347.  
  3348.  
  3349.  
  3350.  
  3351.  
  3352.  
  3353.  
  3354.  
  3355.  
  3356. Simpson                                                        [Page 57]
  3357.  
  3358. RFC 1331                Point-to-Point Protocol                 May 1992
  3359.  
  3360.  
  3361. A.  Asynchronous HDLC
  3362.  
  3363.    This appendix summarizes the modifications to ISO 3309-1979 proposed
  3364.    in ISO 3309:1984/PDAD1, as applied in the Point-to-Point Protocol.
  3365.    These modifications allow HDLC to be used with 8-bit asynchronous
  3366.    links.
  3367.  
  3368.    Transmission Considerations
  3369.  
  3370.       All octets are transmitted with one start bit, eight bits of data,
  3371.       and one stop bit.  There is no provision in either PPP or ISO
  3372.       3309:1984/PDAD1 for seven bit asynchronous links.
  3373.  
  3374.    Flag Sequence
  3375.  
  3376.       The Flag Sequence is a single octet and indicates the beginning or
  3377.       end of a frame.  The Flag Sequence consists of the binary sequence
  3378.       01111110 (hexadecimal 0x7e).
  3379.  
  3380.    Transparency
  3381.  
  3382.       On asynchronous links, a character stuffing procedure is used.
  3383.       The Control Escape octet is defined as binary 01111101
  3384.       (hexadecimal 0x7d) where the bit positions are numbered 87654321
  3385.       (not 76543210, BEWARE).
  3386.  
  3387.       After FCS computation, the transmitter examines the entire frame
  3388.       between the two Flag Sequences.  Each Flag Sequence, Control
  3389.       Escape octet and octet with value less than hexadecimal 0x20 which
  3390.       is flagged in the Remote Async-Control-Character-Map is replaced
  3391.       by a two octet sequence consisting of the Control Escape octet and
  3392.       the original octet with bit 6 complemented (i.e., exclusive-or'd
  3393.       with hexadecimal 0x20).
  3394.  
  3395.       Prior to FCS computation, the receiver examines the entire frame
  3396.       between the two Flag Sequences.  Each octet with value less than
  3397.       hexadecimal 0x20 is checked.  If it is flagged in the Local
  3398.       Async-Control-Character-Map, it is simply removed (it may have
  3399.       been inserted by intervening data communications equipment).  For
  3400.       each Control Escape octet, that octet is also removed, but bit 6
  3401.       of the following octet is complemented.  A Control Escape octet
  3402.       immediately preceding the closing Flag Sequence indicates an
  3403.       invalid frame.
  3404.  
  3405.          Note: The inclusion of all octets less than hexadecimal 0x20
  3406.          allows all ASCII control characters [10] excluding DEL (Delete)
  3407.          to be transparently communicated through almost all known data
  3408.          communications equipment.
  3409.  
  3410.  
  3411.  
  3412. Simpson                                                        [Page 58]
  3413.  
  3414. RFC 1331                Point-to-Point Protocol                 May 1992
  3415.  
  3416.  
  3417.       The transmitter may also send octets with value in the range 0x40
  3418.       through 0xff (except 0x5e) in Control Escape format.  Since these
  3419.       octet values are not negotiable, this does not solve the problem
  3420.       of receivers which cannot handle all non-control characters.
  3421.       Also, since the technique does not affect the 8th bit, this does
  3422.       not solve problems for communications links that can send only 7-
  3423.       bit characters.
  3424.  
  3425.       A few examples may make this more clear.  Packet data is
  3426.       transmitted on the link as follows:
  3427.  
  3428.          0x7e is encoded as 0x7d, 0x5e.
  3429.          0x7d is encoded as 0x7d, 0x5d.
  3430.          0x01 is encoded as 0x7d, 0x21.
  3431.  
  3432.       Some modems with software flow control may intercept outgoing DC1
  3433.       and DC3 ignoring the 8th (parity) bit.  This data would be
  3434.       transmitted on the link as follows:
  3435.  
  3436.          0x11 is encoded as 0x7d, 0x31.
  3437.          0x13 is encoded as 0x7d, 0x33.
  3438.          0x91 is encoded as 0x7d, 0xb1.
  3439.          0x93 is encoded as 0x7d, 0xb3.
  3440.  
  3441.    Aborting a Transmission
  3442.  
  3443.       On asynchronous links, frames may be aborted by transmitting a "0"
  3444.       stop bit where a "1" bit is expected (framing error) or by
  3445.       transmitting a Control Escape octet followed immediately by a
  3446.       closing Flag Sequence.
  3447.  
  3448.    Time Fill
  3449.  
  3450.       On asynchronous links, inter-octet and inter-frame time fill MUST
  3451.       be accomplished by transmitting continuous "1" bits (mark-hold
  3452.       state).
  3453.  
  3454.          Note: On asynchronous links, inter-frame time fill can be
  3455.          viewed as extended inter-octet time fill.  Doing so can save
  3456.          one octet for every frame, decreasing delay and increasing
  3457.          bandwidth.  This is possible since a Flag Sequence may serve as
  3458.          both a frame close and a frame begin.  After having received
  3459.          any frame, an idle receiver will always be in a frame begin
  3460.          state.
  3461.  
  3462.          Robust transmitters should avoid using this trick over-
  3463.          zealously since the price for decreased delay is decreased
  3464.          reliability.  Noisy links may cause the receiver to receive
  3465.  
  3466.  
  3467.  
  3468. Simpson                                                        [Page 59]
  3469.  
  3470. RFC 1331                Point-to-Point Protocol                 May 1992
  3471.  
  3472.  
  3473.          garbage characters and interpret them as part of an incoming
  3474.          frame.  If the transmitter does not transmit a new opening Flag
  3475.          Sequence before sending the next frame, then that frame will be
  3476.          appended to the noise characters causing an invalid frame (with
  3477.          high reliability).  Transmitters should avoid this by
  3478.          transmitting an open Flag Sequence whenever "appreciable time"
  3479.          has elapsed since the prior closing Flag Sequence.  It is
  3480.          suggested that implementations will achieve the best results by
  3481.          always sending an opening Flag Sequence if the new frame is not
  3482.          back-to-back with the last.  The maximum value for "appreciable
  3483.          time" is likely to be no greater than the typing rate of a slow
  3484.          to average typist, say 1 second.
  3485.  
  3486.  
  3487.  
  3488.  
  3489.  
  3490.  
  3491.  
  3492.  
  3493.  
  3494.  
  3495.  
  3496.  
  3497.  
  3498.  
  3499.  
  3500.  
  3501.  
  3502.  
  3503.  
  3504.  
  3505.  
  3506.  
  3507.  
  3508.  
  3509.  
  3510.  
  3511.  
  3512.  
  3513.  
  3514.  
  3515.  
  3516.  
  3517.  
  3518.  
  3519.  
  3520.  
  3521.  
  3522.  
  3523.  
  3524. Simpson                                                        [Page 60]
  3525.  
  3526. RFC 1331                Point-to-Point Protocol                 May 1992
  3527.  
  3528.  
  3529. B.  Fast Frame Check Sequence (FCS) Implementation
  3530.  
  3531. B.1.  FCS Computation Method
  3532.  
  3533.    The following code provides a table lookup computation for
  3534.    calculating the Frame Check Sequence as data arrives at the
  3535.    interface.  This implementation is based on [7], [8], and [9].  The
  3536.    table is created by the code in section B.2.
  3537.  
  3538.    /*
  3539.     * u16 represents an unsigned 16-bit number.  Adjust the typedef for
  3540.     * your hardware.
  3541.     */
  3542.    typedef unsigned short u16;
  3543.  
  3544.  
  3545.    /*
  3546.     * FCS lookup table as calculated by the table generator in section
  3547.     * B.2.
  3548.     */
  3549.    static u16 fcstab[256] = {
  3550.       0x0000, 0x1189, 0x2312, 0x329b, 0x4624, 0x57ad, 0x6536, 0x74bf,
  3551.       0x8c48, 0x9dc1, 0xaf5a, 0xbed3, 0xca6c, 0xdbe5, 0xe97e, 0xf8f7,
  3552.       0x1081, 0x0108, 0x3393, 0x221a, 0x56a5, 0x472c, 0x75b7, 0x643e,
  3553.       0x9cc9, 0x8d40, 0xbfdb, 0xae52, 0xdaed, 0xcb64, 0xf9ff, 0xe876,
  3554.       0x2102, 0x308b, 0x0210, 0x1399, 0x6726, 0x76af, 0x4434, 0x55bd,
  3555.       0xad4a, 0xbcc3, 0x8e58, 0x9fd1, 0xeb6e, 0xfae7, 0xc87c, 0xd9f5,
  3556.       0x3183, 0x200a, 0x1291, 0x0318, 0x77a7, 0x662e, 0x54b5, 0x453c,
  3557.       0xbdcb, 0xac42, 0x9ed9, 0x8f50, 0xfbef, 0xea66, 0xd8fd, 0xc974,
  3558.       0x4204, 0x538d, 0x6116, 0x709f, 0x0420, 0x15a9, 0x2732, 0x36bb,
  3559.       0xce4c, 0xdfc5, 0xed5e, 0xfcd7, 0x8868, 0x99e1, 0xab7a, 0xbaf3,
  3560.       0x5285, 0x430c, 0x7197, 0x601e, 0x14a1, 0x0528, 0x37b3, 0x263a,
  3561.       0xdecd, 0xcf44, 0xfddf, 0xec56, 0x98e9, 0x8960, 0xbbfb, 0xaa72,
  3562.       0x6306, 0x728f, 0x4014, 0x519d, 0x2522, 0x34ab, 0x0630, 0x17b9,
  3563.       0xef4e, 0xfec7, 0xcc5c, 0xddd5, 0xa96a, 0xb8e3, 0x8a78, 0x9bf1,
  3564.       0x7387, 0x620e, 0x5095, 0x411c, 0x35a3, 0x242a, 0x16b1, 0x0738,
  3565.       0xffcf, 0xee46, 0xdcdd, 0xcd54, 0xb9eb, 0xa862, 0x9af9, 0x8b70,
  3566.       0x8408, 0x9581, 0xa71a, 0xb693, 0xc22c, 0xd3a5, 0xe13e, 0xf0b7,
  3567.       0x0840, 0x19c9, 0x2b52, 0x3adb, 0x4e64, 0x5fed, 0x6d76, 0x7cff,
  3568.       0x9489, 0x8500, 0xb79b, 0xa612, 0xd2ad, 0xc324, 0xf1bf, 0xe036,
  3569.       0x18c1, 0x0948, 0x3bd3, 0x2a5a, 0x5ee5, 0x4f6c, 0x7df7, 0x6c7e,
  3570.       0xa50a, 0xb483, 0x8618, 0x9791, 0xe32e, 0xf2a7, 0xc03c, 0xd1b5,
  3571.       0x2942, 0x38cb, 0x0a50, 0x1bd9, 0x6f66, 0x7eef, 0x4c74, 0x5dfd,
  3572.       0xb58b, 0xa402, 0x9699, 0x8710, 0xf3af, 0xe226, 0xd0bd, 0xc134,
  3573.       0x39c3, 0x284a, 0x1ad1, 0x0b58, 0x7fe7, 0x6e6e, 0x5cf5, 0x4d7c,
  3574.       0xc60c, 0xd785, 0xe51e, 0xf497, 0x8028, 0x91a1, 0xa33a, 0xb2b3,
  3575.       0x4a44, 0x5bcd, 0x6956, 0x78df, 0x0c60, 0x1de9, 0x2f72, 0x3efb,
  3576.       0xd68d, 0xc704, 0xf59f, 0xe416, 0x90a9, 0x8120, 0xb3bb, 0xa232,
  3577.  
  3578.  
  3579.  
  3580. Simpson                                                        [Page 61]
  3581.  
  3582. RFC 1331                Point-to-Point Protocol                 May 1992
  3583.  
  3584.  
  3585.       0x5ac5, 0x4b4c, 0x79d7, 0x685e, 0x1ce1, 0x0d68, 0x3ff3, 0x2e7a,
  3586.       0xe70e, 0xf687, 0xc41c, 0xd595, 0xa12a, 0xb0a3, 0x8238, 0x93b1,
  3587.       0x6b46, 0x7acf, 0x4854, 0x59dd, 0x2d62, 0x3ceb, 0x0e70, 0x1ff9,
  3588.       0xf78f, 0xe606, 0xd49d, 0xc514, 0xb1ab, 0xa022, 0x92b9, 0x8330,
  3589.       0x7bc7, 0x6a4e, 0x58d5, 0x495c, 0x3de3, 0x2c6a, 0x1ef1, 0x0f78
  3590.    };
  3591.  
  3592.    #define PPPINITFCS      0xffff  /* Initial FCS value */
  3593.    #define PPPGOODFCS      0xf0b8  /* Good final FCS value */
  3594.  
  3595.    /*
  3596.     * Calculate a new fcs given the current fcs and the new data.
  3597.     */
  3598.    u16 pppfcs(fcs, cp, len)
  3599.        register u16 fcs;
  3600.        register unsigned char *cp;
  3601.        register int len;
  3602.    {
  3603.        ASSERT(sizeof (u16) == 2);
  3604.        ASSERT(((u16) -1) > 0);
  3605.        while (len--)
  3606.            fcs = (fcs >> 8) ^ fcstab[(fcs ^ *cp++) & 0xff];
  3607.  
  3608.        return (fcs);
  3609.    }
  3610.  
  3611.  
  3612.  
  3613.  
  3614.  
  3615.  
  3616.  
  3617.  
  3618.  
  3619.  
  3620.  
  3621.  
  3622.  
  3623.  
  3624.  
  3625.  
  3626.  
  3627.  
  3628.  
  3629.  
  3630.  
  3631.  
  3632.  
  3633.  
  3634.  
  3635.  
  3636. Simpson                                                        [Page 62]
  3637.  
  3638. RFC 1331                Point-to-Point Protocol                 May 1992
  3639.  
  3640.  
  3641. B.2.  Fast FCS table generator
  3642.  
  3643.    The following code creates the lookup table used to calculate the
  3644.    FCS.
  3645.  
  3646.    /*
  3647.     * Generate a FCS table for the HDLC FCS.
  3648.     *
  3649.     * Drew D. Perkins at Carnegie Mellon University.
  3650.     *
  3651.     * Code liberally borrowed from Mohsen Banan and D. Hugh Redelmeier.
  3652.     */
  3653.  
  3654.    /*
  3655.     * The HDLC polynomial: x**0 + x**5 + x**12 + x**16 (0x8408).
  3656.     */
  3657.    #define P       0x8408
  3658.  
  3659.  
  3660.    main()
  3661.    {
  3662.        register unsigned int b, v;
  3663.        register int i;
  3664.  
  3665.        printf("typedef unsigned short u16;\n");
  3666.        printf("static u16 fcstab[256] = {");
  3667.        for (b = 0; ; ) {
  3668.            if (b % 8 == 0)
  3669.                printf("\n");
  3670.  
  3671.            v = b;
  3672.            for (i = 8; i--; )
  3673.                v = v & 1 ? (v >> 1) ^ P : v >> 1;
  3674.  
  3675.            printf("0x%04x", v & 0xFFFF);
  3676.            if (++b == 256)
  3677.                break;
  3678.            printf(",");
  3679.        }
  3680.        printf("\n};\n");
  3681.    }
  3682.  
  3683.  
  3684.  
  3685.  
  3686.  
  3687.  
  3688.  
  3689.  
  3690.  
  3691.  
  3692. Simpson                                                        [Page 63]
  3693.  
  3694. RFC 1331                Point-to-Point Protocol                 May 1992
  3695.  
  3696.  
  3697. C.  LCP Recommended Options
  3698.  
  3699.    The following Configurations Options are recommended:
  3700.  
  3701.       SYNC LINES
  3702.  
  3703.       Magic Number
  3704.       Link Quality Monitoring
  3705.       No Address and Control Field Compression
  3706.       No Protocol Field Compression
  3707.  
  3708.  
  3709.       ASYNC LINES
  3710.  
  3711.       Async Control Character Map
  3712.       Magic Number
  3713.       Address and Control Field Compression
  3714.       Protocol Field Compression
  3715.  
  3716.  
  3717.  
  3718.  
  3719.  
  3720.  
  3721.  
  3722.  
  3723.  
  3724.  
  3725.  
  3726.  
  3727.  
  3728.  
  3729.  
  3730.  
  3731.  
  3732.  
  3733.  
  3734.  
  3735.  
  3736.  
  3737.  
  3738.  
  3739.  
  3740.  
  3741.  
  3742.  
  3743.  
  3744.  
  3745.  
  3746.  
  3747.  
  3748. Simpson                                                        [Page 64]
  3749.  
  3750. RFC 1331                Point-to-Point Protocol                 May 1992
  3751.  
  3752.  
  3753. Security Considerations
  3754.  
  3755.    Security issues are briefly discussed in sections concerning the
  3756.    Authentication Phase, and the Authentication-Protocol Configuration
  3757.    Option.  Further discussion is planned in a separate document
  3758.    entitled PPP Authentication Protocols.
  3759.  
  3760. References
  3761.  
  3762.    [1]   Electronic Industries Association, EIA Standard RS-232-C,
  3763.          "Interface Between Data Terminal Equipment and Data
  3764.          Communications Equipment Employing Serial Binary Data
  3765.          Interchange", August 1969.
  3766.  
  3767.    [2]   International Organization For Standardization, ISO Standard
  3768.          3309-1979, "Data communication - High-level data link control
  3769.          procedures - Frame structure", 1979.
  3770.  
  3771.    [3]   International Organization For Standardization, ISO Standard
  3772.          4335-1979, "Data communication - High-level data link control
  3773.          procedures - Elements of procedures", 1979.
  3774.  
  3775.    [4]   International Organization For Standardization, ISO Standard
  3776.          4335-1979/Addendum 1, "Data communication - High-level data
  3777.          link control procedures - Elements of procedures - Addendum 1",
  3778.          1979.
  3779.  
  3780.    [5]   International Organization For Standardization, Proposed Draft
  3781.          International Standard ISO 3309:1983/PDAD1, "Information
  3782.          processing systems - Data communication - High-level data link
  3783.          control procedures - Frame structure - Addendum 1: Start/stop
  3784.          transmission", 1984.
  3785.  
  3786.    [6]   International Telecommunication Union, CCITT Recommendation
  3787.          X.25, "Interface Between Data Terminal Equipment (DTE) and Data
  3788.          Circuit Terminating Equipment (DCE) for Terminals Operating in
  3789.          the Packet Mode on Public Data Networks", CCITT Red Book,
  3790.          Volume VIII, Fascicle VIII.3, Rec. X.25., October 1984.
  3791.  
  3792.    [7]   Perez, "Byte-wise CRC Calculations", IEEE Micro, June, 1983.
  3793.  
  3794.    [8]   Morse, G., "Calculating CRC's by Bits and Bytes", Byte,
  3795.          September 1986.
  3796.  
  3797.    [9]   LeVan, J., "A Fast CRC", Byte, November 1987.
  3798.  
  3799.    [10]  American National Standards Institute, ANSI X3.4-1977,
  3800.          "American National Standard Code for Information Interchange",
  3801.  
  3802.  
  3803.  
  3804. Simpson                                                        [Page 65]
  3805.  
  3806. RFC 1331                Point-to-Point Protocol                 May 1992
  3807.  
  3808.  
  3809.          1977.
  3810.  
  3811.    [11]  Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
  3812.          USC/Information Sciences Institute, March 1990.
  3813.  
  3814. Acknowledgments
  3815.  
  3816.    Much of the text in this document is taken from the WG Requirements
  3817.    (unpublished), and RFCs 1171 & 1172, by Drew Perkins of Carnegie
  3818.    Mellon University, and by Russ Hobby of the University of California
  3819.    at Davis.
  3820.  
  3821.    Many people spent significant time helping to develop the Point-to-
  3822.    Point Protocol.  The complete list of people is too numerous to list,
  3823.    but the following people deserve special thanks: Rick Adams (UUNET),
  3824.    Ken Adelman (TGV), Fred Baker (ACC), Mike Ballard (Telebit), Craig
  3825.    Fox (NSC), Karl Fox (Morning Star Technologies), Phill Gross (NRI),
  3826.    former WG chair Russ Hobby (UC Davis), David Kaufman (Proteon),
  3827.    former WG chair Steve Knowles (FTP Software), John LoVerso
  3828.    (Xylogics), Bill Melohn (Sun Microsystems), Mike Patton (MIT), former
  3829.    WG chair Drew Perkins (CMU), Greg Satz (cisco systems) and Asher
  3830.    Waldfogel (Wellfleet).
  3831.  
  3832. Chair's Address
  3833.  
  3834.    The working group can be contacted via the current chair:
  3835.  
  3836.       Brian Lloyd
  3837.       Lloyd & Associates
  3838.       3420 Sudbury Road
  3839.       Cameron Park, California 95682
  3840.  
  3841.       Phone: (916) 676-1147
  3842.  
  3843.       EMail: brian@ray.lloyd.com
  3844.  
  3845.  
  3846. Author's Address
  3847.  
  3848.    Questions about this memo can also be directed to:
  3849.  
  3850.       William Allen Simpson
  3851.       Daydreamer
  3852.       Computer Systems Consulting Services
  3853.       P O Box 6205
  3854.       East Lansing, MI  48826-6025
  3855.  
  3856.       EMail: bsimpson@ray.lloyd.com
  3857.  
  3858.  
  3859.  
  3860. Simpson                                                        [Page 66]
  3861.  
  3862.