Network Working Group W. Simpson, Editor
`Request for Comments: 1661 Daydreamer
`STD: 51 July 1994
`Obsoletes: 1548
`Category: Standards Track
`
` The Point-to-Point Protocol (PPP)
`
`Status of this Memo
` This document specifies an Internet standards track protocol for the
` Internet community, and requests discussion and suggestions for
` improvements. Please refer to the current edition of the "Internet
` Official Protocol Standards" (STD 1) for the standardization state
` and status of this protocol. Distribution of this memo is unlimited.
`
`Abstract
` The Point-to-Point Protocol (PPP) provides a standard method for
` transporting multi-protocol datagrams over point-to-point links. PPP
` is comprised of three main components:
` 1. A method for encapsulating multi-protocol datagrams.
` 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 organization and methodology, and the
` PPP encapsulation, together with an extensible option negotiation
` mechanism which is able to negotiate a rich assortment of
` configuration parameters and provides additional management
` functions. The PPP Link Control Protocol (LCP) is described in terms
` of this mechanism.
`
`Table of Contents
`
` 1. Introduction .......................................... 1
` 1.1 Specification of Requirements ................... 2
` 1.2 Terminology ..................................... 3
` 2. PPP Encapsulation ..................................... 4
`
`Simpson [Page i]
`RFC 1661 Point-to-Point Protocol July 1994
`
` 3. PPP Link Operation .................................... 6
` 3.1 Overview ........................................ 6
` 3.2 Phase Diagram ................................... 6
` 3.3 Link Dead (physical-layer not ready) ............ 7
` 3.4 Link Establishment Phase ........................ 7
` 3.5 Authentication Phase ............................ 8
` 3.6 Network-Layer Protocol Phase .................... 8
` 3.7 Link Termination Phase .......................... 9
` 4. The Option Negotiation Automaton ...................... 11
` 4.1 State Transition Table .......................... 12
` 4.2 States .......................................... 14
` 4.3 Events .......................................... 16
` 4.4 Actions ......................................... 21
` 4.5 Loop Avoidance .................................. 23
` 4.6 Counters and Timers ............................. 24
` 5. LCP Packet Formats .................................... 26
` 5.1 Configure-Request ............................... 28
` 5.2 Configure-Ack ................................... 29
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 1
`
`

`

` 5.3 Configure-Nak ................................... 30
` 5.4 Configure-Reject ................................ 31
` 5.5 Terminate-Request and Terminate-Ack ............. 33
` 5.6 Code-Reject ..................................... 34
` 5.7 Protocol-Reject ................................. 35
` 5.8 Echo-Request and Echo-Reply ..................... 36
` 5.9 Discard-Request ................................. 37
` 6. LCP Configuration Options ............................. 39
` 6.1 Maximum-Receive-Unit (MRU) ...................... 41
` 6.2 Authentication-Protocol ......................... 42
` 6.3 Quality-Protocol ................................ 43
` 6.4 Magic-Number .................................... 45
` 6.5 Protocol-Field-Compression (PFC) ................ 48
` 6.6 Address-and-Control-Field-Compression (ACFC)
` SECURITY CONSIDERATIONS ...................................... 51
` REFERENCES ................................................... 51
` ACKNOWLEDGEMENTS ............................................. 51
` CHAIR'S ADDRESS .............................................. 52
` EDITOR'S ADDRESS ............................................. 52
`
`Simpson [Page ii]
`RFC 1661 Point-to-Point Protocol July 1994
`
`1. Introduction
` The Point-to-Point Protocol is designed for simple links which
` transport packets between two peers. These links provide full-duplex
` simultaneous bi-directional operation, and are assumed to deliver
` packets in order. It is intended that PPP provide a common solution
` for easy connection of a wide variety of hosts, bridges and routers
` [1].
` Encapsulation
` The PPP encapsulation provides for multiplexing of different
` network-layer protocols simultaneously over the same link. The
` PPP encapsulation has been carefully designed to retain
` compatibility with most commonly used supporting hardware.
` Only 8 additional octets are necessary to form the encapsulation
` when used within the default HDLC-like framing. In environments
` where bandwidth is at a premium, the encapsulation and framing may
` be shortened to 2 or 4 octets.
` To support high speed implementations, the default encapsulation
` uses only simple fields, only one of which needs to be examined
` for demultiplexing. The default header and information fields
` fall on 32-bit boundaries, and the trailer may be padded to an
` arbitrary boundary.
` Link Control Protocol
` 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, detect a looped-back link and other common
` misconfiguration errors, and terminate the link. Other optional
` facilities provided are authentication of the identity of its peer
` on the link, and determination when a link is functioning properly
` and when it is failing.
` 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
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 2
`
`

`

` problems are handled by a family of Network Control Protocols
` (NCPs), which each manage the specific needs required by their
`
`Simpson [Page 1]
`RFC 1661 Point-to-Point Protocol July 1994
`
` respective network-layer protocols. These NCPs are defined in
` companion documents.
` Configuration
` It is intended that PPP links be easy to configure. By design,
` the standard defaults handle all common configurations. The
` implementor can 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
` document is specified in terms of the Link Control Protocol (LCP),
` the same facilities are designed to be used by other control
` protocols, especially 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 must 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.
`
`Simpson [Page 2]
`RFC 1661 Point-to-Point Protocol July 1994
`
`1.2. Terminology
` This document frequently uses the following terms:
` datagram The unit of transmission in the network layer (such as IP).
` A datagram may be encapsulated in one or more packets
` passed to the data link layer.
` frame The unit of transmission at the data link layer. A frame
` may include a header and/or a trailer, along with some
` number of units of data.
` packet The basic unit of encapsulation, which is passed across the
` interface between the network layer and the data link
` layer. A packet is usually mapped to a frame; the
` exceptions are when data link layer fragmentation is being
` performed, or when multiple packets are incorporated into a
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 3
`
`

`

` single frame.
` peer The other end of the point-to-point link.
` silently discard
` 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.
`
`Simpson [Page 3]
`RFC 1661 Point-to-Point Protocol July 1994
`
`2. PPP Encapsulation
` The PPP encapsulation is used to disambiguate multiprotocol
` datagrams. This encapsulation requires framing to indicate the
` beginning and end of the encapsulation. Methods of providing framing
` are specified in companion documents.
` A summary of the PPP encapsulation is shown below. The fields are
` transmitted from left to right.
` +----------+-------------+---------+
` | Protocol | Information | Padding |
` | 8/16 bits| * | * |
` +----------+-------------+---------+
`
` Protocol Field
` The Protocol field is one or two octets, and its value identifies
` the datagram encapsulated in the Information field of the packet.
` The field is transmitted and received most significant octet
` first.
` The structure of this 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
` treated as having an unrecognized Protocol.
` Protocol field values in the "0***" to "3***" range identify the
` network-layer protocol of specific packets, and values in the
` "8***" to "b***" range identify packets 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
` packets as link-layer Control Protocols (such as LCP).
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 4
`
`

`

`Simpson [Page 4]
`RFC 1661 Point-to-Point Protocol July 1994
`
` Up-to-date values of the Protocol field are specified in the most
` recent "Assigned Numbers" RFC [2]. This specification reserves
` the following values:
` Value (in hex) Protocol Name
` 0001 Padding Protocol
` 0003 to 001f reserved (transparency inefficient)
` 007d reserved (Control Escape)
` 00cf reserved (PPP NLPID)
` 00ff reserved (compression inefficient)
` 8001 to 801f unused
` 807d unused
` 80cf unused
` 80ff unused
` 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.
`
` 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 maximum length for the Information field, including Padding,
` but not including the Protocol field, is termed the Maximum
` Receive Unit (MRU), which defaults to 1500 octets. By
` negotiation, consenting PPP implementations may use other values
` for the MRU.
`
` Padding
` On transmission, the Information field MAY be padded with an
` arbitrary number of octets up to the MRU. It is the
` responsibility of each protocol to distinguish padding octets from
` real information.
`
`Simpson [Page 5]
`RFC 1661 Point-to-Point Protocol July 1994
`
`3. PPP Link Operation
`3.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.
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 5
`
`

`

` 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).
`
`3.2. Phase Diagram
` In the process of configuring, maintaining and terminating the
` point-to-point link, the PPP link goes through several distinct
` phases which are specified in the following simplified state diagram:
` +------+ +-----------+ +--------------+
` | | UP | | OPENED | | SUCCESS/NONE
` | Dead |------->| Establish |---------->| Authenticate |--+
` | | | | | | |
` +------+ +-----------+ +--------------+ |
` ^ | | |
` | FAIL | FAIL | |
` +<--------------+ +----------+ |
` | | |
` | +-----------+ | +---------+ |
` | DOWN | | | CLOSING | | |
` +------------| Terminate |<---+<----------| Network |<-+
` | | | |
` +-----------+ +---------+
` Not all transitions are specified in this diagram. The following
` semantics MUST be followed.
`
`Simpson [Page 6]
`RFC 1661 Point-to-Point Protocol July 1994
`
`3.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 later) will be in the
` Initial or Starting states. The transition to the Link Establishment
` phase will signal an Up event to the LCP automaton.
` Implementation Note:
` Typically, a link will return to this phase automatically after
` the disconnection of a modem. In the case of a hard-wired link,
` this phase may be extremely short -- merely long enough to detect
` the presence of the device.
`
`3.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 later) has been both sent and received.
` All Configuration Options are assumed to be at default values unless
` altered by the configuration exchange. See the chapter 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.
` Any non-LCP packets received during this phase MUST be silently
` discarded.
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 6
`
`

`

` The receipt of the LCP Configure-Request causes a return to the Link
` Establishment phase from the Network-Layer Protocol phase or
` Authentication phase.
`
`Simpson [Page 7]
`RFC 1661 Point-to-Point Protocol July 1994
`
`3.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 mandatory. If an implementation
` desires that the peer authenticate with some specific authentication
` protocol, then it MUST request 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 authentication has completed. If
` authentication fails, the authenticator SHOULD proceed instead to the
` Link Termination phase.
` Only Link Control Protocol, authentication protocol, and link quality
` monitoring packets are allowed during this phase. All other packets
` received during this phase MUST be silently discarded.
` Implementation Notes:
` An implementation SHOULD NOT fail authentication simply due to
` timeout or lack of response. The authentication SHOULD allow some
` method of retransmission, and proceed to the Link Termination
` phase only after a number of authentication attempts has been
` exceeded.
` The implementation responsible for commencing Link Termination
` phase is the implementation which has refused authentication to
` its peer.
`
`3.6. Network-Layer Protocol Phase
` Once PPP has finished the previous phases, each network-layer
` protocol (such as IP, IPX, or AppleTalk) MUST be separately
` configured by the appropriate Network Control Protocol (NCP).
` Each NCP MAY be Opened and Closed at any time.
`
`Simpson [Page 8]
`RFC 1661 Point-to-Point Protocol July 1994
`
` 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 supported
` network-layer protocol packets received when the corresponding NCP is
` not in the Opened state MUST be silently discarded.
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 7
`
`

`

` Implementation Note:
` While LCP is in the Opened state, any protocol packet which is
` unsupported by the implementation MUST be returned in a Protocol-
` Reject (described later). Only protocols which are supported are
` silently discarded.
` During this phase, link traffic consists of any possible combination
` of LCP, NCP, and network-layer protocol packets.
`
`3.7. Link Termination Phase
` PPP can terminate the link at any time. This might happen because of
` the loss of carrier, authentication failure, link quality failure,
` the expiration of an idle-period timer, or the administrative closing
` of the link.
` 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
` 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.
` Any non-LCP packets received during this phase MUST be silently
` discarded.
`
`Simpson [Page 9]
`RFC 1661 Point-to-Point Protocol July 1994
`
` 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 one NCP has Closed is not sufficient reason to cause
` the termination of the PPP link, even if that NCP was the only NCP
` currently in the Opened state.
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 8
`
`

`

`Simpson [Page 10]
`RFC 1661 Point-to-Point Protocol July 1994
`
`4. 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-Started
` Close= administrative Close tlf = This-Layer-Finished
` TO+ = Timeout with counter > 0 irc = Initialize-Restart-Count
` TO- = Timeout with counter expired zrc = Zero-Restart-Count
` 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
`
`Simpson [Page 11]
`RFC 1661 Point-to-Point Protocol July 1994
`
`4.1. 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; multiple actions may be implemented in any
` convenient order. The state may be followed by a letter, which
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 9
`
`

`

` indicates an explanatory footnote. The dash ('-') indicates an
` illegal transition.
` | 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 tlf/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
`
`Simpson [Page 12]
`RFC 1661 Point-to-Point Protocol July 1994
`
` | 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 scj/9
` 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-Count actions start or re-start
` the Restart timer. The Restart timer is stopped when transitioning
` from any state where the timer is running to a state where the timer
` is not running.
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 10
`
`

`

` The events and actions are defined according to a message passing
` architecture, rather than a signalling architecture. If an action is
` desired to control specific signals (such as DTR), additional actions
` are likely to be required.
` [p] Passive option; see Stopped state discussion.
` [r] Restart option; see Open event discussion.
` [x] Crossed connection; see RCA event discussion.
`
`Simpson [Page 13]
`RFC 1661 Point-to-Point Protocol July 1994
`
`4.2. 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
`
`Simpson [Page 14]
`RFC 1661 Point-to-Point Protocol July 1994
`
` 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.
`
`http://www.ietf.org/rfc/rfc1661[7/8/2011 8:25:47 PM]
`
`Petitioner RPX Corporation - Ex. 1033, p. 11
`
`

`

` 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