GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc1172

Network Working Group D. Perkins Request for Comments: 1172 CMU

                                                              R. Hobby
                                                              UC Davis
                                                             July 1990
  The Point-to-Point Protocol (PPP) Initial Configuration Options

Status of this Memo

 This RFC specifies an IAB standards track protocol for the Internet
 community.
 Please refer to the current edition of the "IAB Official Protocol
 Standards" for the standardization state and status of this protocol.
 This proposal is the 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 Point-to-Point Protocol
 Working Group chair.
 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 composed of
    1) a method for encapsulating datagrams over serial links,
    2) an extensible Link Control Protocol (LCP), and
    3) a family of Network Control Protocols (NCP) for establishing
    and configuring different network-layer protocols.
 The PPP encapsulating scheme, the basic LCP, and an NCP for
 controlling and establishing the Internet Protocol (IP) (called the
 IP Control Protocol, IPCP) are defined in The Point-to-Point Protocol
 (PPP) [1].
 This document defines the intial options used by the LCP and IPCP. It
 also defines a method of Link Quality Monitoring and a simple
 authentication scheme.

Perkins & Hobby [Page i] RFC 1172 PPP Initial Options July 1990

                         Table of Contents
   1.     Introduction ..........................................    1
   2.     Link Control Protocol (LCP) Configuration Options .....    1
      2.1       Maximum-Receive-Unit ............................    2
      2.2       Async-Control-Character-Map .....................    3
      2.3       Authentication-Type .............................    5
      2.4       Magic-Number ....................................    7
      2.5       Link-Quality-Monitoring .........................   10
      2.6       Protocol-Field-Compression ......................   11
      2.7       Address-and-Control-Field-Compression ...........   13
   3.     Link Quality Monitoring ...............................   15
      3.1       Design Motivation ...............................   15
      3.2       Design Overview .................................   15
      3.3       Processes .......................................   16
      3.4       Counters ........................................   18
      3.5       Measurements, Calculations, State Variables .....   19
      3.6       Link-Quality-Report Packet Format ...............   21
      3.7       Policy Suggestions ..............................   25
      3.8       Example .........................................   25
   4.     Password Authentication Protocol ......................   27
      4.1       Packet Format ...................................   27
      4.2       Authenticate ....................................   29
      4.3       Authenticate-Ack ................................   31
      4.4       Authenticate-Nak ................................   32
   5.     IP Control Protocol (IPCP) Configuration Options ......   33
      5.1       IP-Addresses ....................................   34
      5.2       Compression-Type ................................   36
   REFERENCES ...................................................   37
   SECURITY CONSIDERATIONS ......................................   37
   AUTHOR'S ADDRESS .............................................   37

Perkins & Hobby [Page ii] RFC 1172 PPP Initial Options July 1990

1. Introduction

 The Point-to-Point Protocol (PPP) [1] proposes a standard method of
 encapsulating IP datagrams, and other Network Layer protocol
 information, over point-to-point links.  PPP also proposes an
 extensible Option Negotiation Protocol.  [1] specifies only the
 protocol itself; the initial set of Configuration Options are
 described in this document.  These Configuration Options allow MTUs
 to be changed, IP addresses to be dynamically assigned, header
 compression to be enabled, and much more.
 This memo is divided into several sections.  Section 2 describes
 Configuration Options for the Link Control Protocol. Section 3
 specifies the use of the Link Quality Monitoring option. Section 4
 defines a simple Password Authentication Protocol. Finally, Section 5
 specifies Configuration Options for the IP Control Protocol.

2. Link Control Protocol (LCP) Configuration Options

 As described in [1], LCP Configuration Options allow modifications to
 the standard characteristics of a point-to-point link to be
 negotiated.  Negotiable modifications proposed in this document
 include such things as the maximum receive unit, async control
 character mapping, the link authentication method, etc.
 The initial proposed values for the LCP Configuration Option Type
 field (see [1]) are assigned as follows:
    1       Maximum-Receive-Unit
    2       Async-Control-Character-Map
    3       Authentication-Type
    4       NOT ASSIGNED
    5       Magic-Number
    6       Link-Quality-Monitoring
    7       Protocol-Field-Compression
    8       Address-and-Control-Field-Compression

Perkins & Hobby [Page 1] RFC 1172 PPP Initial Options July 1990

2.1. Maximum-Receive-Unit

 Description
    This Configuration Option provides a way to negotiate the maximum
    packet size used across one direction of a link.  By default, all
    implementations must be able to receive frames with 1500 octets of
    Information.
    This Configuration Option may be sent to inform the remote end
    that you can receive larger frames, or to request that the remote
    end send you smaller frames.  If smaller frames are requested, an
    implementation MUST still be able to receive 1500 octet frames in
    case link synchronization is lost.
 A summary of the Maximum-Receive-Unit Configuration Option format is
 shown below.  The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |      Maximum-Receive-Unit     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    1
 Length
    4
 Maximum-Receive-Unit
    The Maximum-Receive-Unit field is two octets and indicates the new
    maximum receive unit.  The Maximum-Receive-Unit covers only the
    Data Link Layer Information field but not the header, trailer or
    any transparency bits or bytes.
 Default
    1500

Perkins & Hobby [Page 2] RFC 1172 PPP Initial Options July 1990

2.2. Async-Control-Character-Map

 Description
    This Configuration Option provides a way to negotiate the use of
    control character mapping on asynchronous links.  By default, PPP
    maps all control characters into an appropriate two character
    sequence.  However, it is rarely necessary to map all control
    characters and often times it is unnecessary to map any
    characters.  A PPP implementation may use this Configuration
    Option to inform the remote end which control characters must
    remain mapped and which control characters need not remain mapped
    when the remote end sends them.  The remote end may still send
    these control characters in mapped format if it is necessary
    because of constraints at its (the remote) end.  This option does
    not solve problems for communications links that can send only 7-
    bit characters or that can not send all non-control characters.
    There may be some use of synchronous-to-asynchronous converters
    (some built into modems) in Point-to-point links resulting in a
    synchronous PPP implementation on one end of a link and an
    asynchronous implemention on the other. It is the responsibility
    of the converter to do all mapping conversions during operation.
    To enable this functionality, synchronous PPP implementations MUST
    always accept a Async-Control-Character-Map Configuration Option
    (it MUST always respond to an LCP Configure-Request specifying
    this Configuration Option with an LCP Configure-Ack). However,
    acceptance of this Configuration Option does not imply that the
    synchronous implementation will do any character mapping, since
    synchronous PPP uses bit-stuffing rather than character-stuffing.
    Instead, all such character mapping will be performed by the
    asynchronous-to-synchronous converter.
 A summary of the Async-Control-Character-Map Configuration Option
 format is shown below.  The fields are transmitted from left to
 right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |  Async-Control-Character-Map
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
           (cont)                |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    2

Perkins & Hobby [Page 3] RFC 1172 PPP Initial Options July 1990

 Length
    6
 Async-Control-Character-Map
    The Async-Control-Character-Map field is four octets and indicates
    the new async control character map.  The map is encoded in big-
    endian fashion where each numbered bit corresponds to the ASCII
    control character of the same value.  If the bit is cleared to
    zero, then that ASCII control character need not be mapped.  If
    the bit is set to one, then that ASCII control character must
    remain mapped.  E.g., if bit 19 is set to zero, then the ASCII
    control character 19 (DC3, Control-S) may be sent in the clear.
 Default
    All ones (0xffffffff).

Perkins & Hobby [Page 4] RFC 1172 PPP Initial Options July 1990

2.3. Authentication-Type

 Description
    On some links it may be desirable to require a peer to
    authenticate itself before allowing Network Layer protocol data to
    be exchanged.  This Configuration Option provides a way to
    negotiate the use of a specific authentication protocol.  By
    default, authentication is not necessary.  If an implementation
    requires that the remote end authenticate with some specific
    authentication protocol, then it should negotiate the use of that
    authentication protocol with this Configuration Option.
    Successful negotiation of the Authentication-Type option adds an
    additional Authentication phase to the Link Control Protocol.
    This phase is after the Link Quality Determination phase, and
    before the Network Layer Protocol Configuration Negotiation phase.
    Advancement from the Authentication phase to the Network Layer
    Protocol Configuration Negotiation phase may not occur until the
    peer is successfully authenticated using the negotiated
    authentication protocol.
    An implementation may allow the remote end to pick from more than
    one authentication protocol. To achieve this, it may include
    multiple Authentication-Type Configuration Options in its
    Configure-Request packets.  An implementation receiving a
    Configure-Request specifying multiple Authentication-Types may
    accept at most one of the negotiable authentication protocols and
    should send a Configure-Reject specifying all of the other
    specified authentication protocols.
    It is recommended that each PPP implementation support
    configuration of authentication parameters at least on a per-
    interface basis, if not a per peer entity basis.  The parameters
    should specify which authetication techniques are minimally
    required as a prerequisite to establishment of a PPP connection,
    either for the specified interface or for the specified peer
    entity.  Such configuration facilities are necessary to prevent an
    attacker from negotiating a reduced security authentication
    protocol, or no authentication at all, in an attempt to circumvent
    this authentication facility.
    If an implementation sends a Configure-Ack with this Configuration
    Option, then it is agreeing to authenticate with the specified
    protocol.  An implementation receiving a Configure-Ack with this
    Configuration Option should expect the remote end to authenticate
    with the acknowledged protocol.

Perkins & Hobby [Page 5] RFC 1172 PPP Initial Options July 1990

    There is no requirement that authentication be full duplex or that
    the same authentication protocol be used in both directions.  It
    is perfectly acceptable for different authentication protocols to
    be used in each direction.  This will, of course, depend on the
    specific authentication protocols negotiated.
    This document defines a simple Password Authentication Protocol in
    Section 4.  Development of other more secure protocols is
    encouraged.
 A summary of the Authentication-Type Configuration Option format is
 shown below.  The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |     Authentication-Type       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Data ...
 +-+-+-+-+
 Type
    3
 Length
    >= 4
 Authentication-Type
    The Authentication-Type field is two octets and indicates the type
    of authentication protocol desired.  Values for the
    Authentication-Type are always the same as the PPP Data Link Layer
    Protocol field values for that same authentication protocol.  The
    most up-to-date values of the Authentication-Type field are
    specified in "Assigned Numbers" [2].  Initial values are assigned
    as follows:
       Value (in hex)          Protocol
       c023                    Password Authentication Protocol
 Data
    The Data field is zero or more octets and contains additional data
    as determined by the particular authentication protocol.

Perkins & Hobby [Page 6] RFC 1172 PPP Initial Options July 1990

 Default
    No authentication protocol necessary.

2.4. Magic-Number

 Description
    This Configuration Option provides a way to detect looped-back
    links and other Data Link Layer anomalies.  This Configuration
    Option may be required by some other Configuration Options such as
    the Link-Quality-Monitoring Configuration Option.
    Before this Configuration Option is requested, an implementation
    must choose its Magic-Number.  It is recommended that the Magic-
    Number be chosen in the most random manner possible in order to
    guarantee with very high probability that an implementation will
    arrive at a unique number.  A good way to choose a unique random
    number is to start with an unique seed. Suggested sources of
    uniqueness include machine serial numbers, other network hardware
    addresses, time-of-day clocks, etc.  Particularly good random
    number seeds are precise measurements of the inter-arrival time of
    physical events such as packet reception on other connected
    networks, server response time, or the typing rate of a human
    user.  It is also suggested that as many sources as possible be
    used simultaneously.
    When a Configure-Request is received with a Magic-Number
    Configuration Option, the received Magic-Number should be compared
    with the Magic-Number of the last Configure-Request sent to the
    peer.  If the two Magic-Numbers are different, then the link is
    not looped-back, and the Magic-Number should be acknowledged.  If
    the two Magic-Numbers are equal, then it is possible, but not
    certain, that the link is looped-back and that this Configure-
    Request is actually the one last sent.  To determine this, a
    Configure-Nak should be sent specifying a different Magic-Number
    value.  A new Configure-Request should not be sent to the peer
    until normal processing would cause it to be sent (i.e., until a
    Configure-Nak is received or the Restart timer runs out).
    Reception of a Configure-Nak with a Magic-Number different from
    that of the last Configure-Nak sent to the peer proves that a link
    is not looped-back, and indicates a unique Magic-Number.  If the
    Magic-Number is equal to the one sent in the last Configure-Nak,
    the possibility of a loop-back is increased, and a new Magic-
    Number should be chosen.  In either case, a new Configure-Request
    should be sent with the new Magic-Number.

Perkins & Hobby [Page 7] RFC 1172 PPP Initial Options July 1990

    If the link is indeed looped-back, this sequence (transmit
    Configure-Request, receive Configure-Request, transmit Configure-
    Nak, receive Configure-Nak) will repeat over and over again.  If
    the link is not looped-back, this sequence may occur a few times,
    but it is extremely unlikely to occur repeatedly.  More likely,
    the Magic-Numbers chosen at either end will quickly diverge,
    terminating the sequence.  The following table shows the
    probability of collisions assuming that both ends of the link
    select Magic-Numbers with a perfectly uniform distribution:
       Number of Collisions        Probability
       --------------------   ---------------------
               1              1/2**32    = 2.3 E-10
               2              1/2**32**2 = 5.4 E-20
               3              1/2**32**3 = 1.3 E-29
    Good sources of uniqueness or randomness are required for this
    divergence to occur.  If a good source of uniqueness cannot be
    found, it is recommended that this Configuration Option not be
    enabled; Configure-Requests with the option should not be
    transmitted and any Magic-Number Configuration Options which the
    peer sends should be either acknowledged or rejected.  In this
    case, loop-backs cannot be reliably detected by the
    implementation, although they may still be detectable by the peer.
    If an implementation does transmit a Configure-Request with a
    Magic-Number Configuration Option, then it MUST NOT respond with a
    Configure-Reject if its peer also transmits a Configure-Request
    with a Magic-Number Configuration Option.  That is, if an
    implementation desires to use Magic Numbers, then it MUST also
    allow its peer to do so.  If an implementation does receive a
    Configure-Reject in response to a Configure-Request, it can only
    mean that the link is not looped-back, and that its peer will not
    be using Magic-Numbers.  In this case, an implementation may act
    as if the negotiation had been successful (as if it had instead
    received a Configure-Ack).
    The Magic-Number also may be used to detect looped-back links
    during normal operation as well as during Configuration Option
    negotiation.  All Echo-Request, Echo-Reply, Discard-Request, and
    Link-Quality-Report LCP packets have a Magic-Number field which
    MUST normally be transmitted as zero, and MUST normally be ignored
    on reception.  However, once a Magic-Number has been successfully
    negotiated, an LCP implementation MUST begin transmitting these
    packets with the Magic-Number field set to its negotiated Magic-
    Number.  Additionally, the Magic-Number field of these packets may
    be inspected on reception. All received Magic-Number fields should
    be equal to either zero or the peer's unique Magic-Number,

Perkins & Hobby [Page 8] RFC 1172 PPP Initial Options July 1990

    depending on whether or not the peer negotiated one.  Reception of
    a Magic-Number field equal to the negotiated local Magic-Number
    indicates a looped-back link.  Reception of a Magic-Number other
    than the negotiated local Magic-Number or or the peer's negotiated
    Magic-Number, or zero if the peer didn't negotiate one, indicates
    a link which has been (mis)configured for communications with a
    different peer.
    Procedures for recovery from either case are unspecified and may
    vary from implementation to implementation.  A somewhat
    pessimistic procedure is to assume an LCP Physical-Layer-Down
    event and make an immediate transition to the Closed state.  A
    further Active-Open event will begin the process of re-
    establishing the link, which can't complete until the loop-back
    condition is terminated and Magic-Numbers are successfully
    negotiated.  A more optimistic procedure (in the case of a loop-
    back) is to begin transmitting LCP Echo-Request packets until an
    appropriate Echo-Reply is received, indicating a termination of
    the loop-back condition.
 A summary of the Magic-Number Configuration Option format is shown
 below.  The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |          Magic-Number
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Magic-Number (cont)         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    5
 Length
    6
 Magic-Number
    The Magic-Number field is four octets and indicates a number which
    is very likely to be unique to one end of the link.  A Magic-
    Number of zero is illegal and must not be sent.
 Default
    None.

Perkins & Hobby [Page 9] RFC 1172 PPP Initial Options July 1990

2.5. Link-Quality-Monitoring

 Description
    On some links it may be desirable to determine when, and how
    often, the link is dropping data.  This process is called Link
    Quality Monitoring and is implemented by periodically transmitting
    Link-Quality-Report packets as described in Section 3.  The Link-
    Quality-Monitoring Configuration Option provides a way to enable
    the use of Link-Quality-Report packets, and also to negotiate the
    rate at which they are transmitted.  By default, Link Quality
    Monitoring and the use of Link-Quality-Report packets is disabled.
 A summary of the Link-Quality-Monitoring Configuration Option format
 is shown below.  The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |        Reporting-Period
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
     Reporting-Period (cont)     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    6
 Length
    6
 Reporting-Period
    The Reporting-Period field is four octets and indicates the
    maximum time in micro-seconds that the remote end should wait
    between transmission of LCP Link-Quality-Report packets.  A value
    of zero is illegal and should always be nak'd or rejected.  An LCP
    implementation is always free to transmit LCP Link-Quality-Report
    packets at a faster rate than that which was requested by, and
    acknowledged to, the remote end.
 Default
    None

Perkins & Hobby [Page 10] RFC 1172 PPP Initial Options July 1990

2.6. Protocol-Field-Compression

 Description
    This Configuration Option provides a way to negotiate the
    compression of the Data Link Layer Protocol field.  By default,
    all implementations must transmit standard PPP frames with two
    octet Protocol fields. However, PPP Protocol field numbers are
    chosen such that some values may be compressed into a single octet
    form which is clearly distinguishable from the two octet form.
    This Configuration Option may be sent to inform the remote end
    that you can receive compressed single octet Protocol fields.
    Compressed Protocol fields may not be transmitted unless this
    Configuration Option has been received.
    As previously mentioned, the Protocol field uses an extension
    mechanism consistent with the ISO 3309 extension mechanism for the
    Address field; the Least Significant Bit (LSB) of each octet is
    used to indicate extension of the Protocol field.  A binary "0" as
    the LSB indicates that the Protocol field continues with the
    following octet.  The presence of a binary "1" as the LSB marks
    the last octet of the Protocol field.  Notice that any number of
    "0" octets may be prepended to the field, and will still indicate
    the same value (consider the two representations for 3, 00000011
    and 00000000 00000011).
    In the interest of simplicity, the standard PPP frame uses this
    fact and always sends Protocol fields with a two octet
    representation.  Protocol field values less than 256 (decimal) are
    prepended with a single zero octet even though transmission of
    this, the zero and most significant octet, is unnecessary.
    However, when using low speed links, it is desirable to conserve
    bandwidth by sending as little redundant data as possible.  The
    Protocol Compression Configuration Option allows a trade-off
    between implementation simplicity and bandwidth efficiency.  If
    successfully negotiated, the ISO 3309 extension mechanism may be
    used to compress the Protocol field to one octet instead of two.
    The large majority of frames are compressible since data protocols
    are typically assigned with Protocol field values less than 256.
    To guarantee unambiguous recognition of LCP packets, the Protocol
    field must never be compressed when sending any LCP packet.  In
    addition, PPP implementations must continue to be robust and MUST
    accept PPP frames with double-octet, as well as single-octet,
    Protocol fields, and MUST NOT distinguish between them.
    When a Protocol field is compressed, the Data Link Layer FCS field

Perkins & Hobby [Page 11] RFC 1172 PPP Initial Options July 1990

    is calculated on the compressed frame, not the original
    uncompressed frame.
 A summary of the Protocol-Field-Compression Configuration Option
 format is shown below.  The fields are transmitted from left to
 right.
  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    7
 Length
    2
 Default
    Disabled.

Perkins & Hobby [Page 12] RFC 1172 PPP Initial Options July 1990

2.7. Address-and-Control-Field-Compression

 Description
    This Configuration Option provides a way to negotiate the
    compression of the Data Link Layer Address and Control fields.  By
    default all implementations must transmit frames with Address and
    Control fields and must use the hexadecimal values 0xff and 0x03
    respectively.  Since these fields have constant values, they are
    easily compressed.  this Configuration Option may be used to
    inform the remote end that you can receive compressed Address and
    Control fields.
    Compressed Address and Control fields are formed by simply
    omitting them in all non-ambiguous cases.  Ambiguous frames may
    not be compressed.  Ambiguous cases result when the two octets
    following the Address and Control fields have values that could be
    interpreted as valid Address and Control fields (i.e., 0xff,
    0x03).  This can happen when Protocol-Field-Compression is enabled
    and the Protocol field is compressed to one octet.  If the
    Protocol value is 0xff, and the first octet of the Information
    field is 0x03, the result is ambiguous and the Address and Control
    fields must not be compressed on transmission.
    On reception, the Address and Control fields are decompressed by
    examining the first two octets.  If they contain the values 0xff
    and 0x03, they are assumed to be the Address and Control fields.
    If not, it is assumed that the fields were compressed and were not
    transmitted.
    One additional case in which the Address and Control fields must
    never be compressed is when sending any LCP packet.  This rule
    guarantees unambiguous recognition of LCP packets.
    When the Address and Control fields are compressed, the Data Link
    Layer FCS field is calculated on the compressed frame, not the
    original uncompressed frame.
 A summary of the Address-and-Control-Field-Compression configuration
 option format is shown below.  The fields are transmitted from left
 to right.
  0                   1
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Perkins & Hobby [Page 13] RFC 1172 PPP Initial Options July 1990

 Type
    8
 Length
    2
 Default
    Not compressed.

Perkins & Hobby [Page 14] RFC 1172 PPP Initial Options July 1990

3. Link Quality Monitoring

 Data communications links are rarely perfect. Packets can be dropped
 or corrupted for various reasons (line noise, equipment failure,
 buffer overruns, etc.).  Sometimes, it is desirable to determine
 when, and how often, the link is dropping data.  Routers, for
 example, may want to temporarily allow another route to take
 precedence.  An implementation may also have the option of
 disconnecting and switching to an alternate link.  The process of
 determining data loss is called "Link Quality Monitoring".

3.1. Design Motivation

 There are many different ways to measure link quality, and even more
 ways to react to it.  Rather than specifying a single scheme, Link
 Quality Monitoring is divided into a "mechanism" and a "policy".  PPP
 fully specifies the "mechanism" for Link Quality Monitoring by
 defining the LCP Link-Quality-Report (LQR) packet and specifying a
 procedure for its use.  PPP does NOT specify a Link Quality
 Monitoring "policy" -- how to judge link quality or what to do when
 it is inadequate.  That is left as an implementation decision, and
 can be different at each end of the link.  Implementations are
 allowed, and even encouraged, to experiment with various link quality
 policies.  The Link Quality Monitoring mechanism specification
 insures that two implementations with different policies may
 communicate and interoperate.
 To allow flexible policies to be implemented, the PPP Link Quality
 Monitoring mechanism measures data loss in units of packets, octets,
 and Link-Quality-Reports.  Each measurement is made separately for
 each half of the link, both inbound and outbound.  All measurements
 are communicated to both ends of the link so that each end of the
 link can implement its own link quality policy for both its outbound
 and inbound links.
 Finally, the Link Quality Monitoring protocol is designed to be
 implementable on many different kinds of systems. Although it may be
 common to implement PPP (and especially Link Quality Monitoring) as a
 single software process, multi-process implementations with hardware
 support are also envisioned. The PPP Link Quality Monitoring
 mechanism provides for this by careful definition of the Link-
 Quality-Report packet format, and by specifiying reference points for
 all data transmission and reception measurements.

3.2. Design Overview

 Each Link Quality Monitoring implementation maintains counts of the
 number of packets and octets transmitted and successfully received,

Perkins & Hobby [Page 15] RFC 1172 PPP Initial Options July 1990

 and periodically transmits this information to its peer in a Link-
 Quality-Report packet.  These packets contain three sections: a
 Header section, a Counters section, and a Measurements section.
 The Header section of the packet consists of the normal LCP Link
 Maintenance packet header including Code, Identifier, Length and
 Magic-Number fields.
 The Counters section of the packet consists of four counters, and
 provides the information necessary to measure the quality of the
 link.  The LQR transmitter fills in two of these counters: Out-Tx-
 Packets-Ctr and Out-Tx-Octets-Ctr (described later).  The LQR
 receiver fills in the two remaining counters: In-Rx-Packets-Ctr and
 In-Rx-Octets-Ctr (described later).  These counters are similar to
 sequence numbers; they are constantly increasing to give a "relative"
 indication of the number of packets and octets communicated across
 the outbound link.  By comparing the values in successive Link-
 Quality-Reports, an LQR receiver can compute the "absolute" number of
 packets and octets communicated across its inbound link. Comparing
 these absolute numbers then gives an indication of an inbound link's
 quality.  Relative numbers, rather than absolute, are transmitted
 because they greatly simplify link synchronization; an implementation
 merely waits to receive two LQR packets.
 The Measurements section of the packet consists of six state
 variables: In-Tx-LQRs, Last-In-Id, In-Tx-Packets, In-Tx-Octets, In-
 Rx-Packets, and In-Rx-Octets (described later).  This section allows
 an implementation to report inbound link quality measurements to its
 peer (for which the report will instead indicate outbound link
 quality) by transmitting the absolute, rather than relative, number
 of LQRs, packets, and octets communicated across the inbound link.
 These values are calculated by observing the Counters section of the
 Link-Quality-Report packets received on the inbound link.  Absolute
 numbers may be used in this section without synchronization problems
 because it is necessary to receive only one LQR packet to have valid
 information.
 Link Quality Monitoring is described in more detail in the following
 sections.  First, a description of the processes comprising the Link
 Quality Monitoring mechanism is presented.  This is followed by the
 packet and byte counters maintained; the measurements, calculations,
 and state variables used; the format of the Link-Quality-Report
 packet; some policy suggestions; and, finally, an example link
 quality calculation.

3.3. Processes

 The PPP Link Quality Monitoring mechanism is described using a

Perkins & Hobby [Page 16] RFC 1172 PPP Initial Options July 1990

 "logical process" model. As shown below, there are five logical
 processes duplicated at each end of the duplex link.
 +---------+   +-------+   +----+ Outbound
 |         |-->|  Mux  |-->| Tx |=========>
 | Link-   |   +-------+   +----+
 | Manager |
 |         |   +-------+   +----+ Inbound
 |         |<--| Demux |<--| Rx |<=========
 +---------+   +-------+   +----+
 Link-Manager
    The Link-Manager process transmits and receives Link-Quality-
    Reports, and implements the desired link quality policy.  LQR
    packets are transmitted at a constant rate, which is negotiated by
    the LCP Link-Quality-Monitoring Configuration Option.  The Link-
    Manager process fills in only the Header and Measurements sections
    of the packet; the Counters section of the packet is filled in by
    the Tx and Rx processes.
 Mux
    The Mux process multiplexes packets from the various protocols
    (e.g., LCP, IP, XNS, etc.) into a single, sequential, and
    prioritized stream of packets.  Link-Quality-Report packets MUST
    be given the highest possible priority to insure that link quality
    information is communicated in a timely manner.
 Tx
    The Tx process maintains the counters Out-Tx-Packets-Ctr and Out-
    Tx-Octets-Ctr which are used to measure the amount of data which
    is transmitted on the outbound link.  When Tx processes a Link-
    Quality-Report packet, it inserts the values of these counters
    into the Counters section of the packet.  Because these counters
    represent relative, rather than absolute, values, the question of
    when to update the counters, before or after they are inserted
    into a Link-Quality-Report packet, is left as an implementation
    decision. However, an implementation MUST make this decision the
    same way every time.  The Tx process MUST follow the Mux process
    so that packets are counted in the order transmitted to the link.
 Rx
    The Rx process maintains the counters In-Rx-Packets-Ctr and In-
    Rx-Octets-Ctr which are used to measure the amount of data which
    is received by the inbound link.  When Rx processes a Link-

Perkins & Hobby [Page 17] RFC 1172 PPP Initial Options July 1990

    Quality-Report packet, it inserts the values of these counters
    into the Counters section of the packet.  Again, the question of
    when to update the counters, before or after they are inserted
    into a Link-Quality-Report packet, is left as an implementation
    decision which MUST be made consistently the same way.
 Demux
    The Demux process demultiplexes packets for the various protocols.
    The Demux process MUST follow the Rx process so that packets are
    counted in the order received from the link.

3.4. Counters

 In order to fill in the Counters section of a Link-Quality-Report
 packet, Link Quality Monitoring requires the implementation of one
 8-bit unsigned, and four 32-bit unsigned, monotonically increasing
 counters.  These counters may be reset to any initial value before
 the first Link-Quality-Report is transmitted, but MUST NOT be reset
 again until LCP has left the Open state.  Counters wrap to zero when
 their maximum value is reached (for 32 bit counters: 0xffffffff + 1 =
 0).
 Out-Identifier-Ctr
    Out-Identifier-Ctr is an 8-bit counter maintained by the Link-
    Manager process which increases by one for each transmitted Link-
    Quality-Report packet.
 Out-Tx-Packets-Ctr
    Out-Tx-Packets-Ctr is a 32-bit counter maintained by the Tx
    process which increases by one for each transmitted Data Link
    Layer packet.
 Out-Tx-Octets-Ctr
    Out-Tx-Octets-Ctr is a 32-bit counter maintained by the Tx process
    which increases by one for each octet in a transmitted Data Link
    Layer packet.  All octets which are included in the FCS
    calculation MUST be counted, as should the FCS octets themselves.
    All other octets MUST NOT be counted.
 In-Rx-Packets-Ctr
    In-Rx-Packets-Ctr is a 32-bit counter maintained by the Rx process
    which increases by one for each successfully received Data Link
    Layer packet.  Packets with incorrect FCS fields or other problems

Perkins & Hobby [Page 18] RFC 1172 PPP Initial Options July 1990

    MUST not be counted.
 In-Rx-Octets-Ctr
    In-Rx-Octets-Ctr is a 32-bit counter maintained by the Rx process
    which increases by one for each octet in a successfully received
    Data Link Layer packet.  All octets which are included in an FCS
    calculation MUST be counted, as should the FCS octets themselves.
    All other octets MUST NOT be counted.

3.5. Measurements, Calculations, State Variables

 In order to fill in the Measurements section of a Link-Quality-Report
 packet, Link Quality Monitoring requires the Link-Manager process to
 make a number of calculations and keep a number of state variables.
 These calculations are made, and these state variables updated, each
 time a Link-Quality-Report packet is received from the inbound link.
 In-Tx-LQRs
    In-Tx-LQRs is an 8-bit state variable which indicates the number
    of Link-Quality-Report packets which the peer had to transmit in
    order for the local end to receive exactly one LQR.  In-Tx-LQRs
    defines the length of the "period" over which In-Tx-Packets, In-
    Tx-Octets, In-Rx-Packets, and In-Rx-Octets were measured.  In-Tx-
    LQRs is calculated by subtracting Last-In-Id from the received
    Identifier.  If more than 255 LQRs in a row are lost, In-Tx-LQRs
    will be ambiguous since the Identifier field and all state
    variables based on it are only 8 bits.  It is assumed that the
    Link Quality Monitoring policy will be robust enough to handle
    this case (it should probably close down the link long before this
    happens).
 Last-In-Id
    Last-In-Id is an 8-bit state variable which stores the value of
    the last received Identifier.  Last-In-Id should be updated after
    In-Tx-LQRs has been calculated.
 In-Tx-Packets
    In-Tx-Packets is a 32-bit state variable which indicates the
    number of packets which were transmitted on the inbound link
    during the last period.  In-Tx-Packets is calculated by
    subtracting Last-Out-Tx-Packets-Ctr from the received Out-Tx-
    Packets-Ctr.

Perkins & Hobby [Page 19] RFC 1172 PPP Initial Options July 1990

 Last-Out-Tx-Packets-Ctr
    Last-Out-Tx-Packets-Ctr is a 32-bit state variable which stores
    the value of the last received Out-Tx-Packets-Ctr.  Last-Out-Tx-
    Packets-Ctr should be updated after In-Tx-Packets has been
    calculated.
 In-Tx-Octets
    In-Tx-Octets is a 32-bit state variable which indicates the number
    of octets which were transmitted on the inbound link during the
    last period.  In-Tx-Octets is calculated by subtracting Last-Out-
    Tx-Octets-Ctr from the received Out-Tx-Octets-Ctr.
 Last-Out-Tx-Octets-Ctr
    Last-Out-Tx-Octets-Ctr is a 32-bit state variable which stores the
    value of the last received Out-Tx-Octets-Ctr.  Last-Out-Tx-
    Octets-Ctr should be updated after In-Tx-Octets has been
    calculated.
 In-Rx-Packets
    In-Rx-Packets is a 32-bit state variable which indicates the
    number of packets which were received on the inbound link during
    the last period.  In-Rx-Packets is calculated by subtracting
    Last-In-Rx-Packets-Ctr from the received In-Rx-Packets-Ctr.
 Last-In-Rx-Packets-Ctr
    Last-In-Rx-Packets-Ctr is a 32-bit state variable which stores the
    value of the last received In-Rx-Packets-Ctr.  Last-In-Rx-
    Packets-Ctr should be updated after In-Rx-Packets has been
    calculated.
 In-Rx-Octets
    In-Rx-Octets is a 32-bit state variable which indicates the number
    of octets which were received on the inbound link during the last
    period.  In-Rx-Octets is calculated by subtracting Last-In-Rx-
    Octets-Ctr from the received In-Rx-Octets-Ctr.
 Last-In-Rx-Octets-Ctr
    Last-In-Rx-Octets-Ctr is a 32-bit state variable which stores the
    value of the last received In-Rx-Octets-Ctr.  Last-In-Rx-Octets-
    Ctr should be updated after In-Rx-Octets has been calculated.

Perkins & Hobby [Page 20] RFC 1172 PPP Initial Options July 1990

 Measurements-Valid
    Measurements-Valid is a 1-bit boolean state variable which
    indicates whether or not the In-Tx-Packets, In-Tx-Octets, In-Rx-
    Packets, and In-Rx-Octets state variables contain valid
    measurements.  These measurements cannot be considered valid until
    two or more Link-Quality-Report packets have been received on the
    inbound link.  This bit should be reset when LCP reaches the Open
    state and should be set after the receipt of exactly two LQRs.

3.6. Link-Quality-Report Packet Format

 A Summary of the Link-Quality-Report packet format is shown below.
 The fields are transmitted from left to right.  The Code, Identifier,
 Length, and Magic-Number fields make up the normal LCP Link
 Maintenance packet header; the In-Tx-LQRS, Last-In-Id, V, In-Tx-
 Packets, In-Tx-Octets, In-Rx-Packets, In-Rx-Octets fields contain
 digested absolute measurements; and the Out-Tx-Packets-Ctr, Out-Tx-
 Octets-Ctr, In-Rx-Packets-Ctr, and In-Rx-Octets-Ctr fields contain
 raw relative counts.  Note that as transmitted over the link, this
 packet format does not include the In-Rx-Packets-Ctr and In-Rx-
 Octets-Ctr fields which are logically appended to the packet by the
 Rx process after reception on the inbound link.

Perkins & Hobby [Page 21] RFC 1172 PPP Initial Options July 1990

  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |  Identifier   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         Magic-Number                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  In-Tx-LQRs   |   Last-In-Id  |           Reserved          |V|
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         In-Tx-Packets                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         In-Tx-Octets                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         In-Rx-Packets                         |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                         In-Rx-Octets                          |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Out-Tx-Packets-Ctr                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                       Out-Tx-Octets-Ctr                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 /
 /
 /
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        In-Rx-Packets-Ctr                      |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |                        In-Rx-Octets-Ctr                       |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Code
    12 for Link-Quality-Report.
 Identifier
    The Identifier field is one octet and indicates the sequence
    number for this Link-Quality-Report. The Identifier field is
    copied from the Out-Identifier-Ctr counter on transmission.  On
    reception, the Identifier field is used to calculate In-Tx-LQRs
    and is then stored in Last-In-Id.
    The Link-Quality-Report Identifier sequence number space MUST be
    separate from that of all other LCP packets; for example,
    transmission of an LCP Echo-Request must not cause the Out-
    Identifier-Ctr counter to be incremented.

Perkins & Hobby [Page 22] RFC 1172 PPP Initial Options July 1990

 Length
    The Length field is two octets and indicates the length of the LQM
    packet including the Code, Identifier, Length and all defined
    fields. Octets outside the range of the length field should be
    treated as Data Link Layer padding and should be ignored on
    reception.  In order for the correct In-Tx-Octets and In-Rx-Octets
    values to be calculated, Link-Quality-Reports MUST be consistently
    transmitted with the same amount of padding.
 Magic-Number
    The Magic-Number field is four octets and aids in detecting
    looped-back links.  Unless modified by a Configuration Option, the
    Magic-Number MUST always be transmitted as zero and MUST always be
    ignored on reception. If Magic-Numbers have been negotiated,
    incoming LQM packets should be checked to make sure that the local
    end is not seeing its own Magic-Number and thus a looped-back
    link.
 In-Tx-LQRs
    The In-Tx-LQRs field is one octet and indicates the number of
    periods covered by the Measurements section of this Link-Quality-
    Report.  The In-Tx-LQRs field is copied from the In-Tx-LQRs state
    variable on transmission.
 Last-In-Id
    The Prev-In-Id field is one octet and indicates the age of the
    Measurements section of this Link-Quality-Report. The Last-In-Id
    field is copied from the Last-In-Id field on transmission.  On
    reception, the Last-In-Id field may be compared with the Out-
    Identifier-Ctr to determine how many, if any, outbound Link-
    Quality-Reports have been lost.
 V
    The V field is 1 bit and indicates whether or not the Measurements
    section of this Link-Quality-Report is valid.  The V field is
    copied from the Measurements-Valid state variable on transmission.
    If the V field is not set to 1, then the In-Tx-LQRs, Last-In-Id,
    In-Tx-Packets, In-Tx-Octets, In-Rx-Packets and In-Rx-Octets fields
    should be ignored.
 Reserved
    The Reserved field is 15 bits and is intended to pad the remaining

Perkins & Hobby [Page 23] RFC 1172 PPP Initial Options July 1990

    packet fields to even four-octet boundaries for the convenience of
    hardware implementations. The Reserved field should always be
    transmitted as zero and ignored on reception.
 In-Tx-Packets
    The In-Tx-Packets field is four octets and indicates the number of
    packets transmitted on the inbound link of the Link-Quality-Report
    transmitter during the last measured period.  The In-Tx-Packets
    field is copied from the In-Tx-Packets state variable on
    transmission.
 In-Tx-Octets
    The In-Tx-Octets field is four octets and indicates the number of
    octets transmitted on the inbound link of the Link-Quality-Report
    transmitter during the last measured period.  The In-Tx-Octets
    field is copied from the In-Tx-Octets state variable on
    transmission.
 In-Rx-Packets
    The In-Rx-Packets field is four octets and indicates the number of
    packets received on the inbound link of the Link-Quality-Report
    transmitter during the last measured period.  The In-Rx-Packets
    field is copied from the In-Rx-Packets state variable on
    transmission.
 In-Rx-Octets
    The In-Rx-Octets field is four octets and indicates the number of
    octets received on the inbound link of the Link-Quality-Report
    transmitter during the last measured period.  The In-Rx-Octets
    field is copied from the In-Rx-Octets state variable on
    transmission.
 Out-Tx-Packets
    The Out-Tx-Packets field is four octets and is used to calculate
    the number of packets transmitted on the outbound link of the
    Link-Quality-Report transmitter during a period.  The Out-Tx-
    Packets field is copied from the Out-Tx-Packets-Ctr counter on
    transmission.
 Out-Tx-Octets
    The Out-Tx-Octets field is four octets and is used to calculate
    the number of octets transmitted on the outbound link of the

Perkins & Hobby [Page 24] RFC 1172 PPP Initial Options July 1990

    Link-Quality-Report transmitter during a period.  The Out-Tx-
    Octets field is copied from the Out-Tx-Octets-Ctr counter on
    transmission.
 In-Rx-Packets
    The In-Rx-Packets field is four octets and is used to calculate
    the number of packets received on the inbound link of the Link-
    Quality-Report receiver during a period.  The In-Rx-Packets field
    is copied from the In-Rx-Packets-Ctr counter on reception.  The
    In-Rx-Packets is not shown because it is not actually transmitted
    over the link.  Rather, it is logically appended (in an
    implementation dependent manner) to the packet by the
    implementation's Rx process.
 In-Rx-Octets
    The In-Rx-Octets field is four octets and is used to calculate the
    number of octets  received on the inbound link of the Link-
    Quality-Report receiver during a period.  The In-Rx-Octets field
    is copied from the In-Rx-Octets-Ctr counter on reception.  The
    In-Rx-Octets is not shown because it is not actually transmitted
    over the link.  Rather, it is logically appended (in an
    implementation dependent manner) to the packet by the
    implementation's Rx process.

3.7. Policy Suggestions

 Link-Quality-Report packets provide a mechanism to determine the link
 quality, but it is up to each implementation to decide when the link
 is usable.  It is recommended that this policy implement some amount
 of hysteresis so that the link does not bounce up and down.  A
 particularly good policy is to use a K out of N algorithm.  In such
 an algorithm, there must be K successes out of the last N periods for
 the link to be considered of good quality.
 Procedures for recovery from poor quality links are unspecified and
 may vary from implementation to implementation.  A suggested approach
 is to immediately close all other Network-Layer protocols (i.e.,
 cause IPCP to transmit a Terminate-Req), but to continue transmitting
 Link-Quality-Reports.  Once the link quality again reaches an
 acceptable level, Network-Layer protocols can be reconfigured.

3.8. Example

 An example may be helpful.  Assume that Link-Manager implementation A
 transmits a Link-Quality-Report which is received by Link-Manager
 implementation B at time t0 with the following values:

Perkins & Hobby [Page 25] RFC 1172 PPP Initial Options July 1990

    Out-Tx-Packets    5
    Out-Tx-Octets   100
    In-Rx-Packets     3
    In-Rx-Octets     70
 Assume that A then transmits 20 IP packets with 200 octets, of which
 15 packets and 150 octets are received by B.  At time t1, A transmits
 another LQR which is received by B as follows:
    Out-Tx-Packets   26 (5 old, plus 20 IP, plus 1 LQR)
    Out-Tx-Octets   342 (42 for LQR)
    In-Rx-Packets    19
    In-Rx-Octets    262
 Implementation B can now calculate the number of packets and octets
 transmitted, received and lost on its inbound link as follows:
    In-Tx-Packets   =  26 -   5 =  21
    In-Tx-Octets    = 342 - 100 = 242
    In-Rx-Packets   =  10 -   3 =  16
    In-Rx-Octets    = 262 -  70 = 192
    In-Lost-Packets =  21 -  16 =   5
    In-Lost-Octets  = 242 - 192 =  50
 After doing these calculations, B evaluates the measurements in what
 ever way its implemented policy specifies.  Also, the next time that
 B transmits an LQR to A, it will report these values in the
 Measurements section, thereby allowing A to evaluate these same
 measurements.

Perkins & Hobby [Page 26] RFC 1172 PPP Initial Options July 1990

4. Password Authentication Protocol

 The Password Authentication Protocol (PAP) may be used to
 authenticate a peer by verifying the identity of the remote end of
 the link.  Use of the PAP must first be negotiated using the LCP
 Authentication-Type Configuration Option.  Successful negotiation
 adds an additional Authentication phase to the Link Control Protocol,
 after the Link Quality Determination phase, and before the Network
 Layer Protocol Configuration Negotiation phase.  PAP packets received
 before the Authentication phase is reached should be silently
 discarded.  The Authentication phase is exited once an Authenticate-
 Ack packet is sent or received.
 PAP is intended for use primarily by hosts and routers that connect
 via switched circuits or dial-up lines to a PPP network server.  The
 server can then use the identification of the connecting host or
 router in the selection of options for network layer negotiations or
 failing authentication, drop the connection.
 Note that PAP is not a strong authentication method.  Passwords are
 passed over the circuit in the clear and there is no protection from
 repeated trial and error attacks.  Work is currently underway on more
 secure authentication methods for PPP and other protocols.  It is
 strongly recommended to switch to these methods when they become
 available.

4.1. Packet Format

 Exactly one Password Authentication Protocol packet is encapsulated
 in the Information field of PPP Data Link Layer frames where the
 protocol field indicates type hex c023 (Password Authentication
 Protocol).  A summary of the Password Authentication Protocol packet
 format is shown below.  The fields are transmitted from left to
 right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |  Identifier   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Data ...
 +-+-+-+-+
 Code
    The Code field is one octet and identifies the type of PAP packet.
    PAP Codes are assigned as follows:

Perkins & Hobby [Page 27] RFC 1172 PPP Initial Options July 1990

       1       Authenticate
       2       Authenticate-Ack
       3       Authenticate-Nak
 Identifier
    The Identifier field is one octet and aids in matching requests
    and replies.
 Length
    The Length field is two octets and indicates the length of the PAP
    packet including the Code, Identifier, Length and Data fields.
    Octets outside the range of the Length field should be treated as
    Data Link Layer padding and should be ignored on reception.
 Data
    The Data field is zero or more octets.  The format of the Data
    field is determined by the Code field.

Perkins & Hobby [Page 28] RFC 1172 PPP Initial Options July 1990

4.2. Authenticate

 Description
    The Authenticate packet is used to begin the Password
    Authentication Protocol.  An implementation having sent a LCP
    Configure-Ack packet with an Authentication-Type Configuration
    Option further specifying the Password Authentication Protocol
    must send an Authenticate packet during the Authentication phase.
    An implementation receiving a Configure-Ack with said
    Configuration Option should expect the remote end to send an
    Authenticate packet during this phase.
    An Authenticate packet is sent with the Code field set to 1
    (Authenticate) and the Peer-ID and Password fields filled as
    desired.
    Upon reception of an Authenticate, some type of Authenticate reply
    MUST be transmitted.
 A summary of the Authenticate packet format is shown below.  The
 fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |  Identifier   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | Peer-ID Length|  Peer-Id ...
 +-+-+-+-+-+-+-+-+-+-+-+-+
 | Passwd-Length |  Password  ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+
 Code
    1 for Authenticate.
 Identifier
    The Identifier field is one octet and aids in matching requests
    and replies.  The Identifier field should be changed each time a
    Authenticate is transmitted which is different from the preceding
    request.
 Peer-ID-Length
    The Peer-ID-Length field is one octet and indicates the length of
    the Peer-ID field

Perkins & Hobby [Page 29] RFC 1172 PPP Initial Options July 1990

 Peer-ID
    The Peer-ID field is zero or more octets and indicates the name of
    the peer to be authenticated.
 Passwd-Length
    The Passwd-Length field is one octet and indicates the length of
    the Password field
 Password
    The Password field is zero or more octets and indicates the
    password to be used for authentication.

Perkins & Hobby [Page 30] RFC 1172 PPP Initial Options July 1990

4.3. Authenticate-Ack

 Description
    If the Peer-ID/Password pair received in an Authenticate is both
    recognizable and acceptable, then a PAP implementation should
    transmit a PAP packet with the Code field set to 2 (Authenticate-
    Ack), the Identifier field copied from the received Authenticate,
    and the Message field optionally filled with an ASCII message.
 A summary of the Authenticate-Ack packet format is shown below.  The
 fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |  Identifier   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Msg-Length   |  Message  ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-
 Code
    2 for Authenticate-Ack.
 Identifier
    The Identifier field is one octet and aids in matching requests
    and replies.  The Identifier field MUST be copied from the
    Identifier field of the Authenticate which caused this
    Authenticate-Ack.
 Msg-Length
    The Msg-Length field is one octet and indicates the length of the
    Message field
 Message
    The Message field is zero or more octets and indicates an ASCII
    message.

Perkins & Hobby [Page 31] RFC 1172 PPP Initial Options July 1990

4.4. Authenticate-Nak

 Description
    If the Peer-ID/Password pair received in a Authenticate is not
    recognizable or acceptable, then a PAP implementation should
    transmit a PAP packet with the Code field set to 3 (Authenticate-
    Nak), the Identifier field copied from the received Authenticate,
    and the Message field optionally filled with an ASCII message.
 A summary of the Authenticate-Nak packet format is shown below.  The
 fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Code      |  Identifier   |            Length             |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |  Msg-Length   |  Message  ...
 +-+-+-+-+-+-+-+-+-+-+-+-+-
 Code
    3 for Authenticate-Nak.
 Identifier
    The Identifier field is one octet and aids in matching requests
    and replies.  The Identifier field MUST be copied from the
    Identifier field of the Authenticate which caused this
    Authenticate-Nak.
 Msg-Length
    The Msg-Length field is one octet and indicates the length of the
    Message field
 Message
    The Message field is zero or more octets and indicates an ASCII
    message.

Perkins & Hobby [Page 32] RFC 1172 PPP Initial Options July 1990

5. IP Control Protocol (IPCP) Configuration Options

IPCP Configuration Options allow negotiatiation of desirable Internet Protocol parameters. Negotiable modifications proposed in this document include IP addresses and compression protocols.

The initial proposed values for the IPCP Configuration Option Type field (see [1]) are assigned as follows:

 1       IP-Addresses
 2       Compression-Type

Perkins & Hobby [Page 33] RFC 1172 PPP Initial Options July 1990

5.1. IP-Addresses

 Description
    This Configuration Option provides a way to negotiate the IP
    addresses to be used on each end of the link.  By default, no IP
    addresses are assigned to either end.  An address specified as
    zero shall be interpreted as requesting the remote end to specify
    the address.  If an implementation allows the assignment of
    multiple IP addresses, then it may include multiple IP Address
    Configuration Options in its Configure-Request packets.  An
    implementation receiving a Configure-Request specifying multiple
    IP Address Configuration Options may send a Configure-Reject
    specifying one or more of the specified IP Addresses.  An
    implementation which desires that no IP addresses be assigned
    (such as a "half-gateway") may reject all IP Address Configuration
    Options.
 A summary of the IP-Addresses Configuration Option format is shown
 below.  The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |     Source-IP-Address
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Source-IP-Address (cont)      |  Destination-IP-Address
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  Destination-IP-Address (cont)  |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 Type
    1
 Length
    10
 Source-IP-Address
    The four octet Source-IP-Address is the desired local address of
    the sender of a Configure-Request.  In a Configure-Ack,
    Configure-Nak or Configure-Reject, the Source-IP-Address is the
    remote address of the sender, and is thus a local address with
    respect to the Configuration Option receiver.

Perkins & Hobby [Page 34] RFC 1172 PPP Initial Options July 1990

 Destination-IP-Address
    The four octet Destination-IP-Address is the remote address with
    respect to the sender of a Configure-Request.  In a Configure-Ack,
    Configure-Nak or Configure-Reject, the Destination-IP-Address is
    the local address of the sender, and is thus a remote address with
    respect to the Configuration Option receiver.
 Default
    No IP addresses assigned.

Perkins & Hobby [Page 35] RFC 1172 PPP Initial Options July 1990

5.2. Compression-Type

 Description
    This Configuration Option provides a way to negotiate the use of a
    specific compression protocol.  By default, compression is not
    enabled.
 A summary of the Compression-Type Configuration Option format is
 shown below.  The fields are transmitted from left to right.
  0                   1                   2                   3
  0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |     Type      |    Length     |       Compression-Type        |
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 |    Data ...
 +-+-+-+-+
 Type
    2
 Length
    >= 4
 Compression-Type
    The Compression-Type field is two octets and indicates the type of
    compression protocol desired.  Values for the Compression-Type are
    always the same as the PPP Data Link Layer Protocol field values
    for that same compression protocol.  The most up-to-date values of
    the Compression-Type field are specified in "Assigned Numbers"
    [2].  Initial values are assigned as follows:
       Value (in hex)          Protocol
       0037                    Van Jacobson Compressed TCP/IP
 Data
    The Data field is zero or more octets and contains additional data
    as determined by the compression protocol indicated in the
    Compression-Type field.

Perkins & Hobby [Page 36] RFC 1172 PPP Initial Options July 1990

 Default
    No compression protocol enabled.

References

 [1]   Perkins, D., "The Point-to-Point Protocol for the Transmission
       of Multi-Protocol of Datagrams Over Point-to-Point Links", RFC
       1171, July, 1990.
 [2]   Reynolds, J., and J. Postel, "Assigned Numbers", RFC 1060,
       USC/Information Sciences Institute, March 1990.

Security Considerations

 Security issues are discussed in Section 2.3.

Author's Address

 This proposal is the product of the Point-to-Point Protocol Working
 Group of the Internet Engineering Task Force (IETF). The working
 group can be contacted via the chair:
    Russ Hobby
    UC Davis
    Computing Services
    Davis, CA 95616
    Phone: (916) 752-0236
    EMail: rdhobby@ucdavis.edu
 Questions about this memo can also be directed to:
    Drew D. Perkins
    Carnegie Mellon University
    Networking and Communications
    Pittsburgh, PA 15213
    Phone: (412) 268-8576
    EMail: ddp@andrew.cmu.edu

Perkins & Hobby [Page 37] RFC 1172 PPP Initial Options July 1990

Acknowledgments

 Many people spent significant time helping to develop the Point-to-
 Point Protocol.  The complete list of people is too numerous to list,
 but the following people deserve special thanks: Ken Adelman (TGV),
 Craig Fox (NSC), Phill Gross (NRI), Russ Hobby (UC Davis), David
 Kaufman (Proteon), John LoVerso (Xylogics), Bill Melohn (Sun
 Microsystems), Mike Patton (MIT), Drew Perkins (CMU), Greg Satz
 (cisco systems) and Asher Waldfogel (Wellfleet).

Perkins & Hobby [Page 38]

/data/webs/external/dokuwiki/data/pages/rfc/rfc1172.txt · Last modified: 1990/07/24 21:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki