Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 1331

The Point-to-Point Protocol (PPP) for the Transmission of Multi-protocol Datagrams over Point-to-Point Links

Pages: 69
Obsoletes:  11711172
Obsoleted by:  1548
Part 1 of 2 – Pages 1 to 30
None   None   Next

ToP   noToC   RFC1331 - Page 1
Network Working Group                                         W. Simpson
Request for Comments: 1331                                    Daydreamer
Obsoletes: RFCs 1171, 1172                                      May 1992



                   The Point-to-Point Protocol (PPP)
                                for the
                Transmission of Multi-protocol Datagrams
                       over Point-to-Point Links


Status of this Memo

   This RFC specifies an IAB standards track protocol for the Internet
   community, and requests discussion and suggestions for improvements.
   Please refer to the current edition of the "IAB Official Protocol
   Standards" for the standardization state and status of this protocol.
   Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) provides a method for transmitting
   datagrams over serial point-to-point links.  PPP is comprised of
   three main components:

      1. A method for encapsulating datagrams over serial links.

      2. A Link Control Protocol (LCP) for establishing, configuring,
         and testing the data-link connection.

      3. A family of Network Control Protocols (NCPs) for establishing
         and configuring different network-layer protocols.

   This document defines the PPP encapsulation scheme, together with the
   PPP Link Control Protocol (LCP), an extensible option negotiation
   protocol which is able to negotiate a rich assortment of
   configuration parameters and provides additional management
   functions.

   This RFC is a product of the Point-to-Point Protocol Working Group of
   the Internet Engineering Task Force (IETF).  Comments on this memo
   should be submitted to the ietf-ppp@ucdavis.edu mailing list.
ToP   noToC   RFC1331 - Page 2
Table of Contents


     1.     Introduction ..........................................    1
        1.1       Specification of Requirements ...................    3
        1.2       Terminology .....................................    3

     2.     Physical Layer Requirements ...........................    4

     3.     The Data Link Layer ...................................    5
        3.1       Frame Format ....................................    6

     4.     PPP Link Operation ....................................   10
        4.1       Overview ........................................   10
        4.2       Phase Diagram ...................................   10
        4.3       Link Dead (physical-layer not ready) ............   10
        4.4       Link Establishment Phase ........................   11
        4.5       Authentication Phase ............................   11
        4.6       Network-Layer Protocol Phase ....................   12
        4.7       Link Termination Phase ..........................   12

     5.     The Option Negotiation Automaton ......................   14
        5.1       State Diagram ...................................   15
        5.2       State Transition Table ..........................   16
        5.3       States ..........................................   18
        5.4       Events ..........................................   20
        5.5       Actions .........................................   24
        5.6       Loop Avoidance ..................................   26
        5.7       Counters and Timers .............................   27

     6.     LCP Packet Formats ....................................   28
        6.1       Configure-Request ...............................   30
        6.2       Configure-Ack ...................................   31
        6.3       Configure-Nak ...................................   32
        6.4       Configure-Reject ................................   33
        6.5       Terminate-Request and Terminate-Ack .............   35
        6.6       Code-Reject .....................................   36
        6.7       Protocol-Reject .................................   38
        6.8       Echo-Request and Echo-Reply .....................   39
        6.9       Discard-Request .................................   40

     7.     LCP Configuration Options .............................   42
        7.1       Format ..........................................   43
        7.2       Maximum-Receive-Unit ............................   44
        7.3       Async-Control-Character-Map .....................   45
        7.4       Authentication-Protocol .........................   47
        7.5       Quality-Protocol ................................   49
        7.6       Magic-Number ....................................   51
ToP   noToC   RFC1331 - Page 3
        7.7       Protocol-Field-Compression ......................   54
        7.8       Address-and-Control-Field-Compression ...........   56

     APPENDICES ...................................................   58

     A.     Asynchronous HDLC .....................................   58

     B.     Fast Frame Check Sequence (FCS) Implementation ........   61
        B.1       FCS Computation Method ..........................   61
        B.2       Fast FCS table generator ........................   63

     C.     LCP Recommended Options ...............................   64

     SECURITY CONSIDERATIONS ......................................   65

     REFERENCES ...................................................   65

     ACKNOWLEDGEMENTS .............................................   66

     CHAIR'S ADDRESS ..............................................   66

     AUTHOR'S ADDRESS .............................................   66
ToP   noToC   RFC1331 - Page 4
1.  Introduction

   Motivation

      In the last few years, the Internet has seen explosive growth in
      the number of hosts supporting TCP/IP.  The vast majority of these
      hosts are connected to Local Area Networks (LANs) of various
      types, Ethernet being the most common.  Most of the other hosts
      are connected through Wide Area Networks (WANs) such as X.25 style
      Public Data Networks (PDNs).  Relatively few of these hosts are
      connected with simple point-to-point (i.e., serial) links.  Yet,
      point-to-point links are among the oldest methods of data
      communications and almost every host supports point-to-point
      connections.  For example, asynchronous RS-232-C [1] interfaces
      are essentially ubiquitous.

   Encapsulation

      One reason for the small number of point-to-point IP links is the
      lack of a standard encapsulation protocol.  There are plenty of
      non-standard (and at least one de facto standard) encapsulation
      protocols available, but there is not one which has been agreed
      upon as an Internet Standard.  By contrast, standard encapsulation
      schemes do exist for the transmission of datagrams over most
      popular LANs.

      PPP provides an encapsulation protocol over both bit-oriented
      synchronous links and asynchronous links with 8 bits of data and
      no parity.  These links MUST be full-duplex, but MAY be either
      dedicated or circuit-switched.  PPP uses HDLC as a basis for the
      encapsulation.

      PPP has been carefully designed to retain compatibility with most
      commonly used supporting hardware.  In addition, an escape
      mechanism is specified to allow control data such as XON/XOFF to
      be transmitted transparently over the link, and to remove spurious
      control data which may be injected into the link by intervening
      hardware and software.

      The PPP encapsulation also provides for multiplexing of different
      network-layer protocols simultaneously over the same link.  It is
      intended that PPP provide a common solution for easy connection of
      a wide variety of hosts, bridges and routers.

      Some protocols expect error free transmission, and either provide
      error detection only on a conditional basis, or do not provide it
      at all.  PPP uses the HDLC Frame Check Sequence for error
      detection.  This is commonly available in hardware
ToP   noToC   RFC1331 - Page 5
      implementations, and a software implementation is provided.

      By default, only 8 additional octets are necessary to form the
      encapsulation.  In environments where bandwidth is at a premium,
      the encapsulation may be shortened to as few as 2 octets.  To
      support high speed hardware implementations, PPP provides that the
      default encapsulation header and information fields fall on 32-bit
      boundaries, and allows the trailer to be padded to an arbitrary
      boundary.

   Link Control Protocol

      More importantly, the Point-to-Point Protocol defines more than
      just an encapsulation scheme.  In order to be sufficiently
      versatile to be portable to a wide variety of environments, PPP
      provides a Link Control Protocol (LCP).  The LCP is used to
      automatically agree upon the encapsulation format options, handle
      varying limits on sizes of packets, authenticate the identity of
      its peer on the link, determine when a link is functioning
      properly and when it is defunct, detect a looped-back link and
      other common misconfiguration errors, and terminate the link.

   Network Control Protocols

      Point-to-Point links tend to exacerbate many problems with the
      current family of network protocols.  For instance, assignment and
      management of IP addresses, which is a problem even in LAN
      environments, is especially difficult over circuit-switched
      point-to-point links (such as dial-up modem servers).  These
      problems are handled by a family of Network Control Protocols
      (NCPs), which each manage the specific needs required by their
      respective network-layer protocols.  These NCPs are defined in
      other documents.

   Configuration

      It is intended that PPP be easy to configure.  By design, the
      standard defaults should handle all common configurations.  The
      implementor may specify improvements to the default configuration,
      which are automatically communicated to the peer without operator
      intervention.  Finally, the operator may explicitly configure
      options for the link which enable the link to operate in
      environments where it would otherwise be impossible.

      This self-configuration is implemented through an extensible
      option negotiation mechanism, wherein each end of the link
      describes to the other its capabilities and requirements.
      Although the option negotiation mechanism described in this
ToP   noToC   RFC1331 - Page 6
      document is specified in terms of the Link Control Protocol (LCP),
      the same facilities may be used by the Internet Protocol Control
      Protocol (IPCP) and others in the family of NCPs.

1.1.  Specification of Requirements

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

   MUST

      This word, or the adjective "required", means that the definition
      is an absolute requirement of the specification.

   MUST NOT

      This phrase means that the definition is an absolute prohibition
      of the specification.

   SHOULD

      This word, or the adjective "recommended", means that there may
      exist valid reasons in particular circumstances to ignore this
      item, but the full implications should be understood and carefully
      weighed before choosing a different course.

   MAY

      This word, or the adjective "optional", means that this item is
      one of an allowed set of alternatives.  An implementation which
      does not include this option MUST be prepared to interoperate with
      another implementation which does include the option.

1.2.  Terminology

   This document frequently uses the following terms:

   peer

      The other end of the point-to-point link.

   silently discard

      This means the implementation discards the packet without further
      processing.  The implementation SHOULD provide the capability of
      logging the error, including the contents of the silently
      discarded packet, and SHOULD record the event in a statistics
      counter.
ToP   noToC   RFC1331 - Page 7
2.  Physical Layer Requirements

   The Point-to-Point Protocol is capable of operating across any
   DTE/DCE interface (e.g., EIA RS-232-C, EIA RS-422, EIA RS-423 and
   CCITT V.35).  The only absolute requirement imposed by PPP is the
   provision of a full-duplex circuit, either dedicated or circuit-
   switched, which can operate in either an asynchronous (start/stop) or
   synchronous bit-serial mode, transparent to PPP Data Link Layer
   frames.  PPP does not impose any restrictions regarding transmission
   rate, other than those imposed by the particular DTE/DCE interface in
   use.

   PPP does not require any particular synchronous encoding, such as FM,
   NRZ, or NRZI.

   Implementation Note:

      NRZ is currently most widely available, and on that basis is
      recommended as a default.  When configuration of the encoding is
      allowed, NRZI is recommended as an alternative, because of its
      relative immunity to signal inversion configuration errors.

   PPP does not require the use of modem control signals, such as
   Request To Send (RTS), Clear To Send (CTS), Data Carrier Detect
   (DCD), and Data Terminal Ready (DTR).

   Implementation Note:

      When available, using such signals can allow greater functionality
      and performance.  In particular, such signals SHOULD be used to
      signal the Up and Down events in the Option Negotiation Automaton
      (described below).
ToP   noToC   RFC1331 - Page 8
3.  The Data Link Layer

   The Point-to-Point Protocol uses the principles, terminology, and
   frame structure of the International Organization For
   Standardization's (ISO) High-level Data Link Control (HDLC)
   procedures (ISO 3309-1979 [2]), as modified by ISO 3309:1984/PDAD1
   "Addendum 1: Start/stop transmission" [5].  ISO 3309-1979 specifies
   the HDLC frame structure for use in synchronous environments.  ISO
   3309:1984/PDAD1 specifies proposed modifications to ISO 3309-1979 to
   allow its use in asynchronous environments.

   The PPP control procedures use the definitions and Control field
   encodings standardized in ISO 4335-1979 [3] and ISO 4335-
   1979/Addendum 1-1979 [4].  The PPP frame structure is also consistent
   with CCITT Recommendation X.25 LAPB [6], since that too is based on
   HDLC.

   The purpose of this memo is not to document what is already
   standardized in ISO 3309.  We assume that the reader is already
   familiar with HDLC, or has access to a copy of [2] or [6].  Instead,
   this paper attempts to give a concise summary and point out specific
   options and features used by PPP.  Since "Addendum 1: Start/stop
   transmission", is not yet standardized and widely available, it is
   summarized in Appendix A.

   To remain consistent with standard Internet practice, and avoid
   confusion for people used to reading RFCs, all binary numbers in the
   following descriptions are in Most Significant Bit to Least
   Significant Bit order, reading from left to right, unless otherwise
   indicated.  Note that this is contrary to standard ISO and CCITT
   practice which orders bits as transmitted (i.e., network bit order).
   Keep this in mind when comparing this document with the international
   standards documents.
ToP   noToC   RFC1331 - Page 9
3.1.  Frame Format

   A summary of the standard PPP frame structure is shown below.  This
   figure does not include start/stop bits (for asynchronous links), nor
   any bits or octets inserted for transparency.  The fields are
   transmitted from left to right.

           +----------+----------+----------+----------+------------
           |   Flag   | Address  | Control  | Protocol | Information
           | 01111110 | 11111111 | 00000011 | 16 bits  |      *
           +----------+----------+----------+----------+------------
                   ---+----------+----------+-----------------
                      |   FCS    |   Flag   | Inter-frame Fill
                      | 16 bits  | 01111110 | or next Address
                   ---+----------+----------+-----------------

   Inter-frame Time Fill

   For asynchronous links, inter-frame time fill SHOULD be accomplished
   in the same manner as inter-octet time fill, by transmitting
   continuous "1" bits (mark-hold state).

   For synchronous links, the Flag Sequence SHOULD be transmitted during
   inter-frame time fill.  There is no provision for inter-octet time
   fill.

   Implementation Note:

      Mark idle (continuous ones) SHOULD NOT be used for idle
      synchronous inter-frame time fill.  However, certain types of
      circuit-switched links require the use of mark idle, particularly
      those that calculate accounting based on bit activity.  When mark
      idle is used on a synchronous link, the implementation MUST ensure
      at least 15 consecutive "1" bits between Flags, and that the Flag
      Sequence is generated at the beginning and end of a frame.

Flag Sequence

   The Flag Sequence is a single octet and indicates the beginning or
   end of a frame.  The Flag Sequence consists of the binary sequence
   01111110 (hexadecimal 0x7e).

   The Flag is a frame separator.  Only one Flag is required between two
   frames.  Two consecutive Flags constitute an empty frame, which is
   ignored.
ToP   noToC   RFC1331 - Page 10
   Implementation Note:

      The "shared zero mode" Flag Sequence "011111101111110" SHOULD NOT
      be used.  When not avoidable, such an implementation MUST ensure
      that the first Flag Sequence detected (the end of the frame) is
      promptly communicated to the link layer.

Address Field

   The Address field is a single octet and contains the binary sequence
   11111111 (hexadecimal 0xff), the All-Stations address.  PPP does not
   assign individual station addresses.  The All-Stations address MUST
   always be recognized and received.  The use of other address lengths
   and values may be defined at a later time, or by prior agreement.
   Frames with unrecognized Addresses SHOULD be silently discarded, and
   reported through the normal network management facility.

Control Field

   The Control field is a single octet and contains the binary sequence
   00000011 (hexadecimal 0x03), the Unnumbered Information (UI) command
   with the P/F bit set to zero.  Frames with other Control field values
   SHOULD be silently discarded.

Protocol Field

   The Protocol field is two octets and its value identifies the
   protocol encapsulated in the Information field of the frame.

   This Protocol field is defined by PPP and is not a field defined by
   HDLC.  However, the Protocol field is consistent with the ISO 3309
   extension mechanism for Address fields.  All Protocols MUST be odd;
   the least significant bit of the least significant octet MUST equal
   "1".  Also, all Protocols MUST be assigned such that the least
   significant bit of the most significant octet equals "0".  Frames
   received which don't comply with these rules MUST be considered as
   having an unrecognized Protocol, and handled as specified by the LCP.
   The Protocol field is transmitted and received most significant octet
   first.

   Protocol field values in the "0---" to "3---" range identify the
   network-layer protocol of specific datagrams, and values in the "8--
   -" to "b---" range identify datagrams belonging to the associated
   Network Control Protocols (NCPs), if any.

   Protocol field values in the "4---" to "7---" range are used for
   protocols with low volume traffic which have no associated NCP.
   Protocol field values in the "c---" to "f---" range identify
ToP   noToC   RFC1331 - Page 11
   datagrams as link-layer Control Protocols (such as LCP).

   The most up-to-date values of the Protocol field are specified in the
   most recent "Assigned Numbers" RFC [11].  Current values are assigned
   as follows:

      Value (in hex)  Protocol Name

      0001 to 001f    reserved (transparency inefficient)
      0021            Internet Protocol
      0023            OSI Network Layer
      0025            Xerox NS IDP
      0027            DECnet Phase IV
      0029            Appletalk
      002b            Novell IPX
      002d            Van Jacobson Compressed TCP/IP
      002f            Van Jacobson Uncompressed TCP/IP
      0031            Bridging PDU
      0033            Stream Protocol (ST-II)
      0035            Banyan Vines
      0037            reserved (until 1993)
      00ff            reserved (compression inefficient)

      0201            802.1d Hello Packets
      0231            Luxcom
      0233            Sigma Network Systems

      8021            Internet Protocol Control Protocol
      8023            OSI Network Layer Control Protocol
      8025            Xerox NS IDP Control Protocol
      8027            DECnet Phase IV Control Protocol
      8029            Appletalk Control Protocol
      802b            Novell IPX Control Protocol
      802d            Reserved
      802f            Reserved
      8031            Bridging NCP
      8033            Stream Protocol Control Protocol
      8035            Banyan Vines Control Protocol

      c021            Link Control Protocol
      c023            Password Authentication Protocol
      c025            Link Quality Report
      c223            Challenge Handshake Authentication Protocol

   Developers of new protocols MUST obtain a number from the Internet
   Assigned Numbers Authority (IANA), at IANA@isi.edu.
ToP   noToC   RFC1331 - Page 12
Information Field

   The Information field is zero or more octets.  The Information field
   contains the datagram for the protocol specified in the Protocol
   field.  The end of the Information field is found by locating the
   closing Flag Sequence and allowing two octets for the Frame Check
   Sequence field.  The default maximum length of the Information field
   is 1500 octets.  By negotiation, consenting PPP implementations may
   use other values for the maximum Information field length.

   On transmission, the Information field may be padded with an
   arbitrary number of octets up to the maximum length.  It is the
   responsibility of each protocol to disambiguate padding octets from
   real information.

Frame Check Sequence (FCS) Field

   The Frame Check Sequence field is normally 16 bits (two octets).  The
   use of other FCS lengths may be defined at a later time, or by prior
   agreement.

   The FCS field is calculated over all bits of the Address, Control,
   Protocol and Information fields not including any start and stop bits
   (asynchronous) and any bits (synchronous) or octets (asynchronous)
   inserted for transparency.  This does not include the Flag Sequences
   or the FCS field itself.  The FCS is transmitted with the coefficient
   of the highest term first.

      Note: When octets are received which are flagged in the Async-
      Control-Character-Map, they are discarded before calculating the
      FCS.  See the description in Appendix A.

   For more information on the specification of the FCS, see ISO 3309
   [2] or CCITT X.25 [6].

      Note: A fast, table-driven implementation of the 16-bit FCS
      algorithm is shown in Appendix B.  This implementation is based on
      [7], [8], and [9].

Modifications to the Basic Frame Format

   The Link Control Protocol can negotiate modifications to the standard
   PPP frame structure.  However, modified frames will always be clearly
   distinguishable from standard frames.
ToP   noToC   RFC1331 - Page 13
4.  PPP Link Operation

4.1.  Overview

   In order to establish communications over a point-to-point link, each
   end of the PPP link must first send LCP packets to configure and test
   the data link.  After the link has been established, the peer may be
   authenticated.  Then, PPP must send NCP packets to choose and
   configure one or more network-layer protocols.  Once each of the
   chosen network-layer protocols has been configured, datagrams from
   each network-layer protocol can be sent over the link.

   The link will remain configured for communications until explicit LCP
   or NCP packets close the link down, or until some external event
   occurs (an inactivity timer expires or network administrator
   intervention).

4.2.  Phase Diagram

   In the process of configuring, maintaining and terminating the
   point-to-point link, the PPP link goes through several distinct
   phases:

   +------+        +-----------+           +--------------+
   |      | UP     |           | OPENED    |              | SUCCESS/NONE
   | Dead |------->| Establish |---------->| Authenticate |--+
   |      |        |           |           |              |  |
   +------+        +-----------+           +--------------+  |
      ^          FAIL |                   FAIL |             |
      +<--------------+             +----------+             |
      |                             |                        |
      |            +-----------+    |           +---------+  |
      |       DOWN |           |    |   CLOSING |         |  |
      +------------| Terminate |<---+<----------| Network |<-+
                   |           |                |         |
                   +-----------+                +---------+

4.3.  Link Dead (physical-layer not ready)

   The link necessarily begins and ends with this phase.  When an
   external event (such as carrier detection or network administrator
   configuration) indicates that the physical-layer is ready to be used,
   PPP will proceed to the Link Establishment phase.

   During this phase, the LCP automaton (described below) will be in the
   Initial or Starting states.  The transition to the Link Establishment
   phase will signal an Up event to the automaton.
ToP   noToC   RFC1331 - Page 14
   Implementation Note:

      Typically, a link will return to this phase automatically after
      the disconnection of a modem.  In the case of a hard-wired line,
      this phase may be extremely short -- merely long enough to detect
      the presence of the device.

4.4.  Link Establishment Phase

   The Link Control Protocol (LCP) is used to establish the connection
   through an exchange of Configure packets.  This exchange is complete,
   and the LCP Opened state entered, once a Configure-Ack packet
   (described below) has been both sent and received.  Any non-LCP
   packets received during this phase MUST be silently discarded.

   All Configuration Options are assumed to be at default values unless
   altered by the configuration exchange.  See the section on LCP
   Configuration Options for further discussion.

   It is important to note that only Configuration Options which are
   independent of particular network-layer protocols are configured by
   LCP.  Configuration of individual network-layer protocols is handled
   by separate Network Control Protocols (NCPs) during the Network-Layer
   Protocol phase.

4.5.  Authentication Phase

   On some links it may be desirable to require a peer to authenticate
   itself before allowing network-layer protocol packets to be
   exchanged.

   By default, authentication is not necessary.  If an implementation
   requires that the peer authenticate with some specific authentication
   protocol, then it MUST negotiate the use of that authentication
   protocol during Link Establishment phase.

   Authentication SHOULD take place as soon as possible after link
   establishment.  However, link quality determination MAY occur
   concurrently.  An implementation MUST NOT allow the exchange of link
   quality determination packets to delay authentication indefinitely.

   Advancement from the Authentication phase to the Network-Layer
   Protocol phase MUST NOT occur until the peer is successfully
   authenticated using the negotiated authentication protocol.  In the
   event of failure to authenticate, PPP SHOULD proceed instead to the
   Link Termination phase.
ToP   noToC   RFC1331 - Page 15
4.6.  Network-Layer Protocol Phase

   Once PPP has finished the previous phases, each network-layer
   protocol (such as IP) MUST be separately configured by the
   appropriate Network Control Protocol (NCP).

   Each NCP may be Opened and Closed at any time.

   Implementation Note:

      Because an implementation may initially use a significant amount
      of time for link quality determination, implementations SHOULD
      avoid fixed timeouts when waiting for their peers to configure a
      NCP.

   After a NCP has reached the Opened state, PPP will carry the
   corresponding network-layer protocol packets.  Any network-layer
   protocol packets received when the corresponding NCP is not in the
   Opened state SHOULD be silently discarded.

   During this phase, link traffic consists of any possible combinations
   of LCP, NCP, and network-layer protocol packets.  Any NCP or
   network-layer protocol packets received during any other phase SHOULD
   be silently discarded.

   Implementation Note:

      There is an exception to the preceding paragraphs, due to the
      availability of the LCP Protocol-Reject (described below).  While
      LCP is in the Opened state, any protocol packet which is
      unsupported by the implementation MUST be returned in a Protocol-
      Reject.  Only supported protocols are silently discarded.

4.7.  Link Termination Phase

   PPP may terminate the link at any time.  This will usually be done at
   the request of a human user, but might happen because of a physical
   event such as the loss of carrier, authentication failure, link
   quality failure, or the expiration of an idle-period timer.

   LCP is used to close the link through an exchange of Terminate
   packets.  When the link is closing, PPP informs the network-layer
   protocols so that they may take appropriate action.

   After the exchange of Terminate packets, the implementation SHOULD
   signal the physical-layer to disconnect in order to enforce the
   termination of the link, particularly in the case of an
   authentication failure.  The sender of the Terminate-Request SHOULD
ToP   noToC   RFC1331 - Page 16
   disconnect after receiving a Terminate-Ack, or after the Restart
   counter expires.  The receiver of a Terminate-Request SHOULD wait for
   the peer to disconnect, and MUST NOT disconnect until at least one
   Restart time has passed after sending a Terminate-Ack.  PPP SHOULD
   proceed to the Link Dead phase.

   Implementation Note:

      The closing of the link by LCP is sufficient.  There is no need
      for each NCP to send a flurry of Terminate packets.  Conversely,
      the fact that a NCP has Closed is not sufficient reason to cause
      the termination of the PPP link, even if that NCP was the only
      currently NCP in the Opened state.
ToP   noToC   RFC1331 - Page 17
5.  The Option Negotiation Automaton

   The finite-state automaton is defined by events, actions and state
   transitions.  Events include reception of external commands such as
   Open and Close, expiration of the Restart timer, and reception of
   packets from a peer.  Actions include the starting of the Restart
   timer and transmission of packets to the peer.

   Some types of packets -- Configure-Naks and Configure-Rejects, or
   Code-Rejects and Protocol-Rejects, or Echo-Requests, Echo-Replies and
   Discard-Requests -- are not differentiated in the automaton
   descriptions.  As will be described later, these packets do indeed
   serve different functions.  However, they always cause the same
   transitions.

   Events                                   Actions

   Up   = lower layer is Up                 tlu = This-Layer-Up
   Down = lower layer is Down               tld = This-Layer-Down
   Open = administrative Open               tls = This-Layer-Start
   Close= administrative Close              tlf = This-Layer-Finished

   TO+  = Timeout with counter > 0          irc = initialize restart
                                                  counter
   TO-  = Timeout with counter expired      zrc = zero restart counter

   RCR+ = Receive-Configure-Request (Good)  scr = Send-Configure-Request
   RCR- = Receive-Configure-Request (Bad)
   RCA  = Receive-Configure-Ack             sca = Send-Configure-Ack
   RCN  = Receive-Configure-Nak/Rej         scn = Send-Configure-Nak/Rej

   RTR  = Receive-Terminate-Request         str = Send-Terminate-Request
   RTA  = Receive-Terminate-Ack             sta = Send-Terminate-Ack

   RUC  = Receive-Unknown-Code              scj = Send-Code-Reject
   RXJ+ = Receive-Code-Reject (permitted)
       or Receive-Protocol-Reject
   RXJ- = Receive-Code-Reject (catastrophic)
       or Receive-Protocol-Reject
   RXR  = Receive-Echo-Request              ser = Send-Echo-Reply
       or Receive-Echo-Reply
       or Receive-Discard-Request
                                             -  = illegal action
ToP   noToC   RFC1331 - Page 18
5.1.  State Diagram

   The simplified state diagram which follows describes the sequence of
   events for reaching agreement on Configuration Options (opening the
   PPP link) and for later termination of the link.

      This diagram is not a complete representation of the automaton.
      Implementation MUST be done by consulting the actual state
      transition table.

   Events are in upper case.  Actions are in lower case.  For these
   purposes, the state machine is initially in the Closed state.  Once
   the Opened state has been reached, both ends of the link have met the
   requirement of having both sent and received a Configure-Ack packet.

                  RCR                    TO+
                +--sta-->+             +------->+
                |        |             |        |
          +-------+      |   RTA +-------+      | Close +-------+
          |       |<-----+<------|       |<-str-+<------|       |
          |Closed |              |Closing|              |Opened |
          |       | Open         |       |              |       |
          |       |------+       |       |              |       |
          +-------+      |       +-------+              +-------+
                         |                                ^
                         |                                |
                         |         +-sca----------------->+
                         |         |                      ^
                 RCN,TO+ V    RCR+ |     RCR-         RCA |    RCN,TO+
                +------->+         |   +------->+         |   +--scr-->+
                |        |         |   |        |         |   |        |
          +-------+      |   TO+ +-------+      |       +-------+      |
          |       |<-scr-+<------|       |<-scn-+       |       |<-----+
          | Req-  |              | Ack-  |              | Ack-  |
          | Sent  | RCA          | Rcvd  |              | Sent  |
   +-scn->|       |------------->|       |       +-sca->|       |
   |      +-------+              +-------+       |      +-------+
   |   RCR- |   | RCR+                           |   RCR+ |   | RCR-
   |        |   +------------------------------->+<-------+   |
   |        |                                                 |
   +<-------+<------------------------------------------------+
ToP   noToC   RFC1331 - Page 19
5.2.  State Transition Table

   The complete state transition table follows.  States are indicated
   horizontally, and events are read vertically.  State transitions and
   actions are represented in the form action/new-state.  Multiple
   actions are separated by commas, and may continue on succeeding lines
   as space requires.  The state may be followed by a letter, which
   indicates an explanatory footnote.

   Rationale:

      In previous versions of this table, a simplified non-deterministic
      finite-state automaton was used, with considerable detailed
      information specified in the semantics.  This lead to
      interoperability problems from differing interpretations.

      This table functions similarly to the previous versions, with the
      up/down flags expanded to explicit states, and the active/passive
      paradigm eliminated.  It is believed that this table interoperates
      with previous versions better than those versions themselves.

      | State
      |    0         1         2         3         4         5
Events| Initial   Starting  Closed    Stopped   Closing   Stopping
------+-----------------------------------------------------------
 Up   |    2     irc,scr/6     -         -         -         -
 Down |    -         -         0       tls/1       0         1
 Open |  tls/1       1     irc,scr/6     3r        5r        5r
 Close|    0         0         2         2         4         4
      |
  TO+ |    -         -         -         -       str/4     str/5
  TO- |    -         -         -         -       tlf/2     tlf/3
      |
 RCR+ |    -         -       sta/2 irc,scr,sca/8   4         5
 RCR- |    -         -       sta/2 irc,scr,scn/6   4         5
 RCA  |    -         -       sta/2     sta/3       4         5
 RCN  |    -         -       sta/2     sta/3       4         5
      |
 RTR  |    -         -       sta/2     sta/3     sta/4     sta/5
 RTA  |    -         -         2         3       tlf/2     tlf/3
      |
 RUC  |    -         -       scj/2     scj/3     scj/4     scj/5
 RXJ+ |    -         -         2         3         4         5
 RXJ- |    -         -       tlf/2     tlf/3     tlf/2     tlf/3
      |
 RXR  |    -         -         2         3         4         5
ToP   noToC   RFC1331 - Page 20
      | State
      |    6         7         8           9
Events| Req-Sent  Ack-Rcvd  Ack-Sent    Opened
------+-----------------------------------------
 Up   |    -         -         -           -
 Down |    1         1         1         tld/1
 Open |    6         7         8           9r
 Close|irc,str/4 irc,str/4 irc,str/4 tld,irc,str/4
      |
  TO+ |  scr/6     scr/6     scr/8         -
  TO- |  tlf/3p    tlf/3p    tlf/3p        -
      |
 RCR+ |  sca/8   sca,tlu/9   sca/8   tld,scr,sca/8
 RCR- |  scn/6     scn/7     scn/6   tld,scr,scn/6
 RCA  |  irc/7     scr/6x  irc,tlu/9   tld,scr/6x
 RCN  |irc,scr/6   scr/6x  irc,scr/8   tld,scr/6x
      |
 RTR  |  sta/6     sta/6     sta/6   tld,zrc,sta/5
 RTA  |    6         6         8       tld,scr/6
      |
 RUC  |  scj/6     scj/7     scj/8   tld,scj,scr/6
 RXJ+ |    6         6         8           9
 RXJ- |  tlf/3     tlf/3     tlf/3   tld,irc,str/5
      |
 RXR  |    6         7         8         ser/9

   The states in which the Restart timer is running are identifiable by
   the presence of TO events.  Only the Send-Configure-Request, Send-
   Terminate-Request and Zero-Restart-Counter actions start or re-start
   the Restart timer.  The Restart timer SHOULD be stopped when
   transitioning from any state where the timer is running to a state
   where the timer is not running.


   [p]   Passive option; see Stopped state discussion.

   [r]   Restart option; see Open event discussion.

   [x]   Crossed connection; see RCA event discussion.
ToP   noToC   RFC1331 - Page 21
5.3.  States

   Following is a more detailed description of each automaton state.

   Initial

      In the Initial state, the lower layer is unavailable (Down), and
      no Open has occurred.  The Restart timer is not running in the
      Initial state.

   Starting

      The Starting state is the Open counterpart to the Initial state.
      An administrative Open has been initiated, but the lower layer is
      still unavailable (Down).  The Restart timer is not running in the
      Starting state.

      When the lower layer becomes available (Up), a Configure-Request
      is sent.

   Closed

      In the Closed state, the link is available (Up), but no Open has
      occurred.  The Restart timer is not running in the Closed state.

      Upon reception of Configure-Request packets, a Terminate-Ack is
      sent.  Terminate-Acks are silently discarded to avoid creating a
      loop.

   Stopped

      The Stopped state is the Open counterpart to the Closed state.  It
      is entered when the automaton is waiting for a Down event after
      the This-Layer-Finished action, or after sending a Terminate-Ack.
      The Restart timer is not running in the Stopped state.

      Upon reception of Configure-Request packets, an appropriate
      response is sent.  Upon reception of other packets, a Terminate-
      Ack is sent.  Terminate-Acks are silently discarded to avoid
      creating a loop.

      Rationale:

         The Stopped state is a junction state for link termination,
         link configuration failure, and other automaton failure modes.
         These potentially separate states have been combined.

         There is a race condition between the Down event response (from
ToP   noToC   RFC1331 - Page 22
         the This-Layer-Finished action) and the Receive-Configure-
         Request event.  When a Configure-Request arrives before the
         Down event, the Down event will supercede by returning the
         automaton to the Starting state.  This prevents attack by
         repetition.

      Implementation Option:

         After the peer fails to respond to Configure-Requests, an
         implementation MAY wait passively for the peer to send
         Configure-Requests.  In this case, the This-Layer-Finished
         action is not used for the TO- event in states Req-Sent, Ack-
         Rcvd and Ack-Sent.

         This option is useful for dedicated circuits, or circuits which
         have no status signals available, but SHOULD NOT be used for
         switched circuits.

   Closing

      In the Closing state, an attempt is made to terminate the
      connection.  A Terminate-Request has been sent and the Restart
      timer is running, but a Terminate-Ack has not yet been received.

      Upon reception of a Terminate-Ack, the Closed state is entered.
      Upon the expiration of the Restart timer, a new Terminate-Request
      is transmitted and the Restart timer is restarted.  After the
      Restart timer has expired Max-Terminate times, this action may be
      skipped, and the Closed state may be entered.

   Stopping

      The Stopping state is the Open counterpart to the Closing state.
      A Terminate-Request has been sent and the Restart timer is
      running, but a Terminate-Ack has not yet been received.

      Rationale:

         The Stopping state provides a well defined opportunity to
         terminate a link before allowing new traffic.  After the link
         has terminated, a new configuration may occur via the Stopped
         or Starting states.

   Request-Sent

      In the Request-Sent state an attempt is made to configure the
      connection.  A Configure-Request has been sent and the Restart
      timer is running, but a Configure-Ack has not yet been received
ToP   noToC   RFC1331 - Page 23
      nor has one been sent.

   Ack-Received

      In the Ack-Received state, a Configure-Request has been sent and a
      Configure-Ack has been received.  The Restart timer is still
      running since a Configure-Ack has not yet been sent.

   Ack-Sent

      In the Ack-Sent state, a Configure-Request and a Configure-Ack
      have both been sent but a Configure-Ack has not yet been received.
      The Restart timer is always running in the Ack-Sent state.

   Opened

      In the Opened state, a Configure-Ack has been both sent and
      received.  The Restart timer is not running in the Opened state.

      When entering the Opened state, the implementation SHOULD signal
      the upper layers that it is now Up.  Conversely, when leaving the
      Opened state, the implementation SHOULD signal the upper layers
      that it is now Down.

5.4.  Events

   Transitions and actions in the automaton are caused by events.

   Up

      The Up event occurs when a lower layer indicates that it is ready
      to carry packets.  Typically, this event is used to signal LCP
      that the link is entering Link Establishment phase, or used to
      signal a NCP that the link is entering Network-Layer Protocol
      phase.

   Down

      The Down event occurs when a lower layer indicates that it is no
      longer ready to carry packets.  Typically, this event is used to
      signal LCP that the link is entering Link Dead phase, or used to
      signal a NCP that the link is leaving Network-Layer Protocol
      phase.

   Open

      The Open event indicates that the link is administratively
      available for traffic; that is, the network administrator (human
ToP   noToC   RFC1331 - Page 24
      or program) has indicated that the link is allowed to be Opened.
      When this event occurs, and the link is not in the Opened state,
      the automaton attempts to send configuration packets to the peer.

      If the automaton is not able to begin configuration (the lower
      layer is Down, or a previous Close event has not completed), the
      establishment of the link is automatically delayed.

      When a Terminate-Request is received, or other events occur which
      cause the link to become unavailable, the automaton will progress
      to a state where the link is ready to re-open.  No additional
      administrative intervention should be necessary.

      Implementation Note:

         Experience has shown that users will execute an additional Open
         command when they want to renegotiate the link.  Since this is
         not the meaning of the Open event, it is suggested that when an
         Open user command is executed in the Opened, Closing, Stopping,
         or Stopped states, the implementation issue a Down event,
         immediately followed by an Up event.  This will cause the
         renegotiation of the link, without any harmful side effects.

   Close

      The Close event indicates that the link is not available for
      traffic; that is, the network administrator (human or program) has
      indicated that the link is not allowed to be Opened.  When this
      event occurs, and the link is not in the Closed state, the
      automaton attempts to terminate the connection.  Futher attempts
      to re-configure the link are denied until a new Open event occurs.

   Timeout (TO+,TO-)

      This event indicates the expiration of the Restart timer.  The
      Restart timer is used to time responses to Configure-Request and
      Terminate-Request packets.

      The TO+ event indicates that the Restart counter continues to be
      greater than zero, which triggers the corresponding Configure-
      Request or Terminate-Request packet to be retransmitted.

      The TO- event indicates that the Restart counter is not greater
      than zero, and no more packets need to be retransmitted.

   Receive-Configure-Request (RCR+,RCR-)

      This event occurs when a Configure-Request packet is received from
ToP   noToC   RFC1331 - Page 25
      the peer.  The Configure-Request packet indicates the desire to
      open a connection and may specify Configuration Options.  The
      Configure-Request packet is more fully described in a later
      section.

      The RCR+ event indicates that the Configure-Request was
      acceptable, and triggers the transmission of a corresponding
      Configure-Ack.

      The RCR- event indicates that the Configure-Request was
      unacceptable, and triggers the transmission of a corresponding
      Configure-Nak or Configure-Reject.

      Implementation Note:

         These events may occur on a connection which is already in the
         Opened state.  The implementation MUST be prepared to
         immediately renegotiate the Configuration Options.

   Receive-Configure-Ack (RCA)

      The Receive-Configure-Ack event occurs when a valid Configure-Ack
      packet is received from the peer.  The Configure-Ack packet is a
      positive response to a Configure-Request packet.  An out of
      sequence or otherwise invalid packet is silently discarded.

      Implementation Note:

         Since the correct packet has already been received before
         reaching the Ack-Rcvd or Opened states, it is extremely
         unlikely that another such packet will arrive.  As specified,
         all invalid Ack/Nak/Rej packets are silently discarded, and do
         not affect the transitions of the automaton.

         However, it is not impossible that a correctly formed packet
         will arrive through a coincidentally-timed cross-connection.
         It is more likely to be the result of an implementation error.
         At the very least, this occurance should be logged.

   Receive-Configure-Nak/Rej (RCN)

      This event occurs when a valid Configure-Nak or Configure-Reject
      packet is received from the peer.  The Configure-Nak and
      Configure-Reject packets are negative responses to a Configure-
      Request packet.  An out of sequence or otherwise invalid packet is
      silently discarded.
ToP   noToC   RFC1331 - Page 26
      Implementation Note:

         Although the Configure-Nak and Configure-Reject cause the same
         state transition in the automaton, these packets have
         significantly different effects on the Configuration Options
         sent in the resulting Configure-Request packet.

   Receive-Terminate-Request (RTR)

      The Receive-Terminate-Request event occurs when a Terminate-
      Request packet is received.  The Terminate-Request packet
      indicates the desire of the peer to close the connection.

      Implementation Note:

         This event is not identical to the Close event (see above), and
         does not override the Open commands of the local network
         administrator.  The implementation MUST be prepared to receive
         a new Configure-Request without network administrator
         intervention.

   Receive-Terminate-Ack (RTA)

      The Receive-Terminate-Ack event occurs when a Terminate-Ack packet
      is received from the peer.  The Terminate-Ack packet is usually a
      response to a Terminate-Request packet.  The Terminate-Ack packet
      may also indicate that the peer is in Closed or Stopped states,
      and serves to re-synchronize the link configuration.

   Receive-Unknown-Code (RUC)

      The Receive-Unknown-Code event occurs when an un-interpretable
      packet is received from the peer.  A Code-Reject packet is sent in
      response.

   Receive-Code-Reject, Receive-Protocol-Reject (RXJ+,RXJ-)

      This event occurs when a Code-Reject or a Protocol-Reject packet
      is received from the peer.

      The RXJ+ event arises when the rejected value is acceptable, such
      as a Code-Reject of an extended code, or a Protocol-Reject of a
      NCP.  These are within the scope of normal operation.  The
      implementation MUST stop sending the offending packet type.

      The RXJ- event arises when the rejected value is catastrophic,
      such as a Code-Reject of Configure-Request, or a Protocol-Reject
      of LCP!  This event communicates an unrecoverable error that
ToP   noToC   RFC1331 - Page 27
      terminates the connection.

   Receive-Echo-Request, Receive-Echo-Reply, Receive-Discard-Request
   (RXR)

      This event occurs when an Echo-Request, Echo-Reply or Discard-
      Request packet is received from the peer.  The Echo-Reply packet
      is a response to a Echo-Request packet.  There is no reply to an
      Echo-Reply or Discard-Request packet.

5.5.  Actions

   Actions in the automaton are caused by events and typically indicate
   the transmission of packets and/or the starting or stopping of the
   Restart timer.

   Illegal-Event (-)

      This indicates an event that SHOULD NOT occur.  The implementation
      probably has an internal error.

   This-Layer-Up (tlu)

      This action indicates to the upper layers that the automaton is
      entering the Opened state.

      Typically, this action MAY be used by the LCP to signal the Up
      event to a NCP, Authentication Protocol, or Link Quality Protocol,
      or MAY be used by a NCP to indicate that the link is available for
      its traffic.

   This-Layer-Down (tld)

      This action indicates to the upper layers that the automaton is
      leaving the Opened state.

      Typically, this action MAY be used by the LCP to signal the Down
      event to a NCP, Authentication Protocol, or Link Quality Protocol,
      or MAY be used by a NCP to indicate that the link is no longer
      available for its traffic.

   This-Layer-Start (tls)

      This action indicates to the lower layers that the automaton is
      entering the Starting state, and the lower layer is needed for the
      link.  The lower layer SHOULD respond with an Up event when the
      lower layer is available.
ToP   noToC   RFC1331 - Page 28
      This action is highly implementation dependent.

   This-Layer-Finished (tlf)

      This action indicates to the lower layers that the automaton is
      entering the Stopped or Closed states, and the lower layer is no
      longer needed for the link.  The lower layer SHOULD respond with a
      Down event when the lower layer has terminated.

      Typically, this action MAY be used by the LCP to advance to the
      Link Dead phase, or MAY be used by a NCP to indicate to the LCP
      that the link may terminate when there are no other NCPs open.

      This action is highly implementation dependent.

   Initialize-Restart-Counter (irc)

      This action sets the Restart counter to the appropriate value
      (Max-Terminate or Max-Configure).  The counter is decremented for
      each transmission, including the first.

   Zero-Restart-Counter (zrc)

      This action sets the Restart counter to zero.

      Implementation Note:

         This action enables the FSA to pause before proceeding to the
         desired final state.  In addition to zeroing the Restart
         counter, the implementation MUST set the timeout period to an
         appropriate value.

   Send-Configure-Request (scr)

      The Send-Configure-Request action transmits a Configure-Request
      packet.  This indicates the desire to open a connection with a
      specified set of Configuration Options.  The Restart timer is
      started when the Configure-Request packet is transmitted, to guard
      against packet loss.  The Restart counter is decremented each time
      a Configure-Request is sent.

   Send-Configure-Ack (sca)

      The Send-Configure-Ack action transmits a Configure-Ack packet.
      This acknowledges the reception of a Configure-Request packet with
      an acceptable set of Configuration Options.
ToP   noToC   RFC1331 - Page 29
   Send-Configure-Nak (scn)

      The Send-Configure-Nak action transmits a Configure-Nak or
      Configure-Reject packet, as appropriate.  This negative response
      reports the reception of a Configure-Request packet with an
      unacceptable set of Configuration Options.  Configure-Nak packets
      are used to refuse a Configuration Option value, and to suggest a
      new, acceptable value.  Configure-Reject packets are used to
      refuse all negotiation about a Configuration Option, typically
      because it is not recognized or implemented.  The use of
      Configure-Nak versus Configure-Reject is more fully described in
      the section on LCP Packet Formats.

   Send-Terminate-Request (str)

      The Send-Terminate-Request action transmits a Terminate-Request
      packet.  This indicates the desire to close a connection.  The
      Restart timer is started when the Terminate-Request packet is
      transmitted, to guard against packet loss.  The Restart counter is
      decremented each time a Terminate-Request is sent.

   Send-Terminate-Ack (sta)

      The Send-Terminate-Ack action transmits a Terminate-Ack packet.
      This acknowledges the reception of a Terminate-Request packet or
      otherwise serves to synchronize the state machines.

   Send-Code-Reject (scj)

      The Send-Code-Reject action transmits a Code-Reject packet.  This
      indicates the reception of an unknown type of packet.

   Send-Echo-Reply (ser)

      The Send-Echo-Reply action transmits an Echo-Reply packet.  This
      acknowledges the reception of an Echo-Request packet.

5.6.  Loop Avoidance

   The protocol makes a reasonable attempt at avoiding Configuration
   Option negotiation loops.  However, the protocol does NOT guarantee
   that loops will not happen.  As with any negotiation, it is possible
   to configure two PPP implementations with conflicting policies that
   will never converge.  It is also possible to configure policies which
   do converge, but which take significant time to do so.  Implementors
   should keep this in mind and should implement loop detection
   mechanisms or higher level timeouts.
ToP   noToC   RFC1331 - Page 30
5.7.  Counters and Timers

Restart Timer

   There is one special timer used by the automaton.  The Restart timer
   is used to time transmissions of Configure-Request and Terminate-
   Request packets.  Expiration of the Restart timer causes a Timeout
   event, and retransmission of the corresponding Configure-Request or
   Terminate-Request packet.  The Restart timer MUST be configurable,
   but MAY default to three (3) seconds.

   Implementation Note:

      The Restart timer SHOULD be based on the speed of the link.  The
      default value is designed for low speed (19,200 bps or less), high
      switching latency links (typical telephone lines).  Higher speed
      links, or links with low switching latency, SHOULD have
      correspondingly faster retransmission times.

Max-Terminate

   There is one required restart counter for Terminate-Requests.  Max-
   Terminate indicates the number of Terminate-Request packets sent
   without receiving a Terminate-Ack before assuming that the peer is
   unable to respond.  Max-Terminate MUST be configurable, but should
   default to two (2) transmissions.

Max-Configure

   A similar counter is recommended for Configure-Requests.  Max-
   Configure indicates the number of Configure-Request packets sent
   without receiving a valid Configure-Ack, Configure-Nak or Configure-
   Reject before assuming that the peer is unable to respond.  Max-
   Configure MUST be configurable, but should default to ten (10)
   transmissions.

Max-Failure

   A related counter is recommended for Configure-Nak.  Max-Failure
   indicates the number of Configure-Nak packets sent without sending a
   Configure-Ack before assuming that configuration is not converging.
   Any further Configure-Nak packets are converted to Configure-Reject
   packets.  Max-Failure MUST be configurable, but should default to ten
   (10) transmissions.


(next page on part 2)

Next Section