Section 6. LCP Configuration Options

LCP Configuration Options allow negotiation of modifications to the
   default characteristics of a point-to-point link.  If a Configuration
   Option is not included in a Configure-Request packet, the default
   value for that Configuration Option is assumed.
   Some Configuration Options MAY be listed more than once.  The effect
   of this is Configuration Option specific, and is specified by each
   such Configuration Option description.  (None of the Configuration
   Options in this specification can be listed more than once.)
   The end of the list of Configuration Options is indicated by the
   Length field of the LCP packet.
   Unless otherwise specified, all Configuration Options apply in a
   half-duplex fashion; typically, in the receive direction of the link
   from the point of view of the Configure-Request sender.
   Design Philosophy
      The options indicate additional capabilities or requirements of
      the implementation that is requesting the option.  An
      implementation which does not understand any option SHOULD
      interoperate with one which implements every option.
      A default is specified for each option which allows the link to
      correctly function without negotiation of the option, although
      perhaps with less than optimal performance.
      Except where explicitly specified, acknowledgement of an option
      does not require the peer to take any additional action other than
      the default.
      It is not necessary to send the default values for the options in
      a Configure-Request.
   A summary of the 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 6 7 8 9
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Type      |    Length     |    Data ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type
      The Type field is one octet, and indicates the type of
      Configuration Option.  Up-to-date values of the LCP Option Type
      field are specified in the most recent "Assigned Numbers" RFC [2].
      This document concerns the following values:
         0       RESERVED
         1       Maximum-Receive-Unit
         3       Authentication-Protocol
         4       Quality-Protocol
         5       Magic-Number
         7       Protocol-Field-Compression
         8       Address-and-Control-Field-Compression
   Length
      The Length field is one octet, and indicates the length of this
      Configuration Option including the Type, Length and Data fields.
      If a negotiable Configuration Option is received in a Configure-
      Request, but with an invalid or unrecognized Length, a Configure-
      Nak SHOULD be transmitted which includes the desired Configuration
      Option with an appropriate Length and Data.
   Data
      The Data field is zero or more octets, and contains information
      specific to the Configuration Option.  The format and length of
      the Data field is determined by the Type and Length fields.
      When the Data field is indicated by the Length to extend beyond
      the end of the Information field, the entire packet is silently
      discarded without affecting the automaton.
6.1.  Maximum-Receive-Unit (MRU)
   Description
      This Configuration Option may be sent to inform the peer that the
      implementation can receive larger packets, or to request that the
      peer send smaller packets.
      The default value is 1500 octets.  If smaller packets are
      requested, an implementation MUST still be able to receive the
      full 1500 octet information field in case link synchronization is
      lost.
      Implementation Note:
         This option is used to indicate an implementation capability.
         The peer is not required to maximize the use of the capacity.
         For example, when a MRU is indicated which is 2048 octets, the
         peer is not required to send any packet with 2048 octets.  The
         peer need not Configure-Nak to indicate that it will only send
         smaller packets, since the implementation will always require
         support for at least 1500 octets.
   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 specifies the
      maximum number of octets in the Information and Padding fields.
      It does not include the framing, Protocol field, FCS, nor any
      transparency bits or bytes.
6.2.  Authentication-Protocol
   Description
      On some links it may be desirable to require a peer to
      authenticate itself before allowing network-layer protocol packets
      to be exchanged.
      This Configuration Option provides a method to negotiate the use
      of a specific protocol for authentication.  By default,
      authentication is not required.
      An implementation MUST NOT include multiple Authentication-
      Protocol Configuration Options in its Configure-Request packets.
      Instead, it SHOULD attempt to configure the most desirable
      protocol first.  If that protocol is Configure-Nak'd, then the
      implementation SHOULD attempt the next most desirable protocol in
      the next Configure-Request.
      The implementation sending the Configure-Request is indicating
      that it expects authentication from its peer.  If an
      implementation sends a Configure-Ack, then it is agreeing to
      authenticate with the specified protocol.  An implementation
      receiving a Configure-Ack SHOULD expect the peer to authenticate
      with the acknowledged protocol.
      There is no requirement that authentication be full-duplex or that
      the same protocol be used in both directions.  It is perfectly
      acceptable for different protocols to be used in each direction.
      This will, of course, depend on the specific protocols negotiated.
   A summary of the Authentication-Protocol 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-Protocol   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+
   Type
      3
   Length
      >= 4
   Authentication-Protocol
      The Authentication-Protocol field is two octets, and indicates the
      authentication protocol desired.  Values for this field are always
      the same as the PPP Protocol field values for that same
      authentication protocol.
      Up-to-date values of the Authentication-Protocol field are
      specified in the most recent "Assigned Numbers" RFC [2].  Current
      values are assigned as follows:
      Value (in hex)  Protocol
      c023            Password Authentication Protocol
      c223            Challenge Handshake Authentication Protocol
   Data
      The Data field is zero or more octets, and contains additional
      data as determined by the particular protocol.
6.3.  Quality-Protocol
   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.
      This Configuration Option provides a method to negotiate the use
      of a specific protocol for link quality monitoring.  By default,
      link quality monitoring is disabled.
      The implementation sending the Configure-Request is indicating
      that it expects to receive monitoring information from its peer.
      If an implementation sends a Configure-Ack, then it is agreeing to
      send the specified protocol.  An implementation receiving a
      Configure-Ack SHOULD expect the peer to send the acknowledged
      protocol.
      There is no requirement that quality monitoring be full-duplex or
      that the same protocol be used in both directions.  It is
      perfectly acceptable for different protocols to be used in each
      direction.  This will, of course, depend on the specific protocols
      negotiated.
   A summary of the Quality-Protocol 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     |        Quality-Protocol       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+
   Type
      4
   Length
      >= 4
   Quality-Protocol
      The Quality-Protocol field is two octets, and indicates the link
      quality monitoring protocol desired.  Values for this field are
      always the same as the PPP Protocol field values for that same
      monitoring protocol.
      Up-to-date values of the Quality-Protocol field are specified in
      the most recent "Assigned Numbers" RFC [2].  Current values are
      assigned as follows:
      Value (in hex)  Protocol
      c025            Link Quality Report
   Data
      The Data field is zero or more octets, and contains additional
      data as determined by the particular protocol.
6.4.  Magic-Number
   Description
      This Configuration Option provides a method 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 Quality-Protocol Configuration Option.  By default, the
      Magic-Number is not negotiated, and zero is inserted where a
      Magic-Number might otherwise be used.
      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 a 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 is 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
      MUST 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 (that is, 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 looped-back link is increased, and a new
      Magic-Number MUST be chosen.  In either case, a new Configure-
      Request SHOULD be sent with the new Magic-Number.
      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 might 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, looped-back links 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 when it receives 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 SHOULD 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 LCP Echo-Request, Echo-Reply, and Discard-
      Request packets have a Magic-Number field.  If Magic-Number has
      been successfully negotiated, an implementation MUST transmit
      these packets with the Magic-Number field set to its negotiated
      Magic-Number.
      The Magic-Number field of these packets SHOULD be inspected on
      reception.  All received Magic-Number fields MUST be equal to
      either zero or the peer's unique Magic-Number, depending on
      whether or not the peer negotiated a Magic-Number.
      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, 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 a LCP Down event.  A further
      Open event will begin the process of re-establishing the link,
      which can't complete until the looped-back condition is
      terminated, and Magic-Numbers are successfully negotiated.  A more
      optimistic procedure (in the case of a looped-back link) is to
      begin transmitting LCP Echo-Request packets until an appropriate
      Echo-Reply is received, indicating a termination of the looped-
      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 always be Nak'd, if it is
      not Rejected outright.
6.5.  Protocol-Field-Compression (PFC)
   Description
      This Configuration Option provides a method to negotiate the
      compression of the PPP Protocol field.  By default, all
      implementations MUST transmit packets with two octet PPP Protocol
      fields.
      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 is sent to inform the peer that the implementation can
      receive such single octet Protocol fields.
      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 binary representations for 3,
      00000011 and 00000000 00000011).
      When using low speed links, it is desirable to conserve bandwidth
      by sending as little redundant data as possible.  The Protocol-
      Field-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 packets are compressible since data
      protocols are typically assigned with Protocol field values less
      than 256.
      Compressed Protocol fields MUST NOT be transmitted unless this
      Configuration Option has been negotiated.  When negotiated, PPP
      implementations MUST accept PPP packets with either double-octet
      or single-octet Protocol fields, and MUST NOT distinguish between
      them.
      The Protocol field is never compressed when sending any LCP
      packet.  This rule guarantees unambiguous recognition of LCP
      packets.
      When a Protocol field is compressed, the Data Link Layer FCS field
      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
6.6.  Address-and-Control-Field-Compression (ACFC)
   Description
      This Configuration Option provides a method 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 appropriate to the link framing.
      Since these fields usually have constant values for point-to-point
      links, they are easily compressed.  This Configuration Option is
      sent to inform the peer that the implementation can receive
      compressed Address and Control fields.
      If a compressed frame is received when Address-and-Control-Field-
      Compression has not been negotiated, the implementation MAY
      silently discard the frame.
      The Address and Control fields MUST NOT be compressed 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     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Type
      8
   Length
      2
Security Considerations
   Security issues are briefly discussed in sections concerning the
   Authentication Phase, the Close event, and the Authentication-
   Protocol Configuration Option.
References
   [1]   Perkins, D., "Requirements for an Internet Standard Point-to-
         Point Protocol", RFC 1547, Carnegie Mellon University,
         December 1993.
   [2]   Reynolds, J., and Postel, J., "Assigned Numbers", STD 2, RFC
         1340, USC/Information Sciences Institute, July 1992.
Acknowledgements
   This document is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the ietf-ppp@merit.edu mailing list.
   Much of the text in this document is taken from the working group
   requirements [1]; and RFCs 1171 & 1172, by Drew Perkins while at
   Carnegie Mellon University, and by Russ Hobby of the University of
   California at Davis.
   William Simpson was principally responsible for introducing
   consistent terminology and philosophy, and the re-design of the phase
   and negotiation state machines.
   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: Rick Adams, Ken
   Adelman, Fred Baker, Mike Ballard, Craig Fox, Karl Fox, Phill Gross,
   Kory Hamzeh, former WG chair Russ Hobby, David Kaufman, former WG
   chair Steve Knowles, Mark Lewis, former WG chair Brian Lloyd, John
   LoVerso, Bill Melohn, Mike Patton, former WG chair Drew Perkins, Greg
   Satz, John Shriver, Vernon Schryver, and Asher Waldfogel.
   Special thanks to Morning Star Technologies for providing computing
   resources and network access support for writing this specification.
Chair's Address
   The working group can be contacted via the current chair:
      Fred Baker
      Advanced Computer Communications
      315 Bollay Drive
      Santa Barbara, California  93117
      fbaker@acc.com
Editor's Address
   Questions about this memo can also be directed to:
      William Allen Simpson
      Daydreamer
      Computer Systems Consulting Services
      1384 Fontaine
      Madison Heights, Michigan  48071
      Bill.Simpson@um.cc.umich.edu
          bsimpson@MorningStar.com