Section 5. LCP Packet Formats

There are three classes of LCP packets:
      1. Link Configuration packets used to establish and configure a
         link (Configure-Request, Configure-Ack, Configure-Nak and
         Configure-Reject).
      2. Link Termination packets used to terminate a link (Terminate-
         Request and Terminate-Ack).
      3. Link Maintenance packets used to manage and debug a link
         (Code-Reject, Protocol-Reject, Echo-Request, Echo-Reply, and
         Discard-Request).
   In the interest of simplicity, there is no version field in the LCP
   packet.  A correctly functioning LCP implementation will always
   respond to unknown Protocols and Codes with an easily recognizable
   LCP packet, thus providing a deterministic fallback mechanism for
   implementations of other versions.
   Regardless of which Configuration Options are enabled, all LCP Link
   Configuration, Link Termination, and Code-Reject packets (codes 1
   through 7) are always sent as if no Configuration Options were
   negotiated.  In particular, each Configuration Option specifies a
   default value.  This ensures that such LCP packets are always
   recognizable, even when one end of the link mistakenly believes the
   link to be open.
   Exactly one LCP packet is encapsulated in the PPP Information field,
   where the PPP Protocol field indicates type hex c021 (Link Control
   Protocol).
   A summary of the Link Control 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 kind of LCP
      packet.  When a packet is received with an unknown Code field, a
      Code-Reject packet is transmitted.
      Up-to-date values of the LCP Code field are specified in the most
      recent "Assigned Numbers" RFC [2].  This document concerns the
      following values:
         1       Configure-Request
         2       Configure-Ack
         3       Configure-Nak
         4       Configure-Reject
         5       Terminate-Request
         6       Terminate-Ack
         7       Code-Reject
         8       Protocol-Reject
         9       Echo-Request
         10      Echo-Reply
         11      Discard-Request
   Identifier
      The Identifier field is one octet, and aids in matching requests
      and replies.  When a packet is received with an invalid Identifier
      field, the packet is silently discarded without affecting the
      automaton.
   Length
      The Length field is two octets, and indicates the length of the
      LCP packet, including the Code, Identifier, Length and Data
      fields.  The Length MUST NOT exceed the MRU of the link.
      Octets outside the range of the Length field are treated as
      padding and are ignored on reception.  When a packet is received
      with an invalid Length field, the packet is silently discarded
      without affecting the automaton.
   Data
      The Data field is zero or more octets, as indicated by the Length
      field.  The format of the Data field is determined by the Code
      field.
5.1.  Configure-Request
   Description
      An implementation wishing to open a connection MUST transmit a
      Configure-Request.  The Options field is filled with any desired
      changes to the link defaults.  Configuration Options SHOULD NOT be
      included with default values.
      Upon reception of a Configure-Request, an appropriate reply MUST
      be transmitted.
   A summary of the Configure-Request 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+
   Code
      1 for Configure-Request.
   Identifier
      The Identifier field MUST be changed whenever the contents of the
      Options field changes, and whenever a valid reply has been
      received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.
   Options
      The options field is variable in length, and contains the list of
      zero or more Configuration Options that the sender desires to
      negotiate.  All Configuration Options are always negotiated
      simultaneously.  The format of Configuration Options is further
      described in a later chapter.
5.2.  Configure-Ack
   Description
      If every Configuration Option received in a Configure-Request is
      recognizable and all values are acceptable, then the
      implementation MUST transmit a Configure-Ack.  The acknowledged
      Configuration Options MUST NOT be reordered or modified in any
      way.
      On reception of a Configure-Ack, the Identifier field MUST match
      that of the last transmitted Configure-Request.  Additionally, the
      Configuration Options in a Configure-Ack MUST exactly match those
      of the last transmitted Configure-Request.  Invalid packets are
      silently discarded.
   A summary of the Configure-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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+
   Code
      2 for Configure-Ack.
   Identifier
      The Identifier field is a copy of the Identifier field of the
      Configure-Request which caused this Configure-Ack.
   Options
      The Options field is variable in length, and contains the list of
      zero or more Configuration Options that the sender is
      acknowledging.  All Configuration Options are always acknowledged
      simultaneously.
5.3.  Configure-Nak
   Description
      If every instance of the received Configuration Options is
      recognizable, but some values are not acceptable, then the
      implementation MUST transmit a Configure-Nak.  The Options field
      is filled with only the unacceptable Configuration Options from
      the Configure-Request.  All acceptable Configuration Options are
      filtered out of the Configure-Nak, but otherwise the Configuration
      Options from the Configure-Request MUST NOT be reordered.
      Options which have no value fields (boolean options) MUST use the
      Configure-Reject reply instead.
      Each Configuration Option which is allowed only a single instance
      MUST be modified to a value acceptable to the Configure-Nak
      sender.  The default value MAY be used, when this differs from the
      requested value.
      When a particular type of Configuration Option can be listed more
      than once with different values, the Configure-Nak MUST include a
      list of all values for that option which are acceptable to the
      Configure-Nak sender.  This includes acceptable values that were
      present in the Configure-Request.
      Finally, an implementation may be configured to request the
      negotiation of a specific Configuration Option.  If that option is
      not listed, then that option MAY be appended to the list of Nak'd
      Configuration Options, in order to prompt the peer to include that
      option in its next Configure-Request packet.  Any value fields for
      the option MUST indicate values acceptable to the Configure-Nak
      sender.
      On reception of a Configure-Nak, the Identifier field MUST match
      that of the last transmitted Configure-Request.  Invalid packets
      are silently discarded.
      Reception of a valid Configure-Nak indicates that when a new
      Configure-Request is sent, the Configuration Options MAY be
      modified as specified in the Configure-Nak.  When multiple
      instances of a Configuration Option are present, the peer SHOULD
      select a single value to include in its next Configure-Request
      packet.
      Some Configuration Options have a variable length.  Since the
      Nak'd Option has been modified by the peer, the implementation
      MUST be able to handle an Option length which is different from
      the original Configure-Request.
   A summary of the Configure-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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+
   Code
      3 for Configure-Nak.
   Identifier
      The Identifier field is a copy of the Identifier field of the
      Configure-Request which caused this Configure-Nak.
   Options
      The Options field is variable in length, and contains the list of
      zero or more Configuration Options that the sender is Nak'ing.
      All Configuration Options are always Nak'd simultaneously.
5.4.  Configure-Reject
   Description
      If some Configuration Options received in a Configure-Request are
      not recognizable or are not acceptable for negotiation (as
      configured by a network administrator), then the implementation
      MUST transmit a Configure-Reject.  The Options field is filled
      with only the unacceptable Configuration Options from the
      Configure-Request.  All recognizable and negotiable Configuration
      Options are filtered out of the Configure-Reject, but otherwise
      the Configuration Options MUST NOT be reordered or modified in any
      way.
      On reception of a Configure-Reject, the Identifier field MUST
      match that of the last transmitted Configure-Request.
      Additionally, the Configuration Options in a Configure-Reject MUST
      be a proper subset of those in the last transmitted Configure-
      Request.  Invalid packets are silently discarded.
      Reception of a valid Configure-Reject indicates that when a new
      Configure-Request is sent, it MUST NOT include any of the
      Configuration Options listed in the Configure-Reject.
   A summary of the Configure-Reject 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Options ...
   +-+-+-+-+
   Code
      4 for Configure-Reject.
   Identifier
      The Identifier field is a copy of the Identifier field of the
      Configure-Request which caused this Configure-Reject.
   Options
      The Options field is variable in length, and contains the list of
      zero or more Configuration Options that the sender is rejecting.
      All Configuration Options are always rejected simultaneously.
5.5.  Terminate-Request and Terminate-Ack
   Description
      LCP includes Terminate-Request and Terminate-Ack Codes in order to
      provide a mechanism for closing a connection.
      An implementation wishing to close a connection SHOULD transmit a
      Terminate-Request.  Terminate-Request packets SHOULD continue to
      be sent until Terminate-Ack is received, the lower layer indicates
      that it has gone down, or a sufficiently large number have been
      transmitted such that the peer is down with reasonable certainty.
      Upon reception of a Terminate-Request, a Terminate-Ack MUST be
      transmitted.
      Reception of an unelicited Terminate-Ack indicates that the peer
      is in the Closed or Stopped states, or is otherwise in need of
      re-negotiation.
   A summary of the Terminate-Request and Terminate-Ack packet formats
   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
      5 for Terminate-Request;
      6 for Terminate-Ack.
   Identifier
      On transmission, the Identifier field MUST be changed whenever the
      content of the Data field changes, and whenever a valid reply has
      been received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.
      On reception, the Identifier field of the Terminate-Request is
      copied into the Identifier field of the Terminate-Ack packet.
   Data
      The Data field is zero or more octets, and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value.  The end of the field is indicated by the Length.
5.6.  Code-Reject
   Description
      Reception of a LCP packet with an unknown Code indicates that the
      peer is operating with a different version.  This MUST be reported
      back to the sender of the unknown Code by transmitting a Code-
      Reject.
      Upon reception of the Code-Reject of a code which is fundamental
      to this version of the protocol, the implementation SHOULD report
      the problem and drop the connection, since it is unlikely that the
      situation can be rectified automatically.
   A summary of the Code-Reject 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Rejected-Packet ...
   +-+-+-+-+-+-+-+-+
   Code
      7 for Code-Reject.
   Identifier
      The Identifier field MUST be changed for each Code-Reject sent.
   Rejected-Packet
      The Rejected-Packet field contains a copy of the LCP packet which
      is being rejected.  It begins with the Information field, and does
      not include any Data Link Layer headers nor an FCS.  The
      Rejected-Packet MUST be truncated to comply with the peer's
      established MRU.
5.7.  Protocol-Reject
   Description
      Reception of a PPP packet with an unknown Protocol field indicates
      that the peer is attempting to use a protocol which is
      unsupported.  This usually occurs when the peer attempts to
      configure a new protocol.  If the LCP automaton is in the Opened
      state, then this MUST be reported back to the peer by transmitting
      a Protocol-Reject.
      Upon reception of a Protocol-Reject, the implementation MUST stop
      sending packets of the indicated protocol at the earliest
      opportunity.
      Protocol-Reject packets can only be sent in the LCP Opened state.
      Protocol-Reject packets received in any state other than the LCP
      Opened state SHOULD be silently discarded.
   A summary of the Protocol-Reject 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       Rejected-Protocol       |      Rejected-Information ...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   Code
      8 for Protocol-Reject.
   Identifier
      The Identifier field MUST be changed for each Protocol-Reject
      sent.
   Rejected-Protocol
      The Rejected-Protocol field is two octets, and contains the PPP
      Protocol field of the packet which is being rejected.
   Rejected-Information
      The Rejected-Information field contains a copy of the packet which
      is being rejected.  It begins with the Information field, and does
      not include any Data Link Layer headers nor an FCS.  The
      Rejected-Information MUST be truncated to comply with the peer's
      established MRU.
5.8.  Echo-Request and Echo-Reply
   Description
      LCP includes Echo-Request and Echo-Reply Codes in order to provide
      a Data Link Layer loopback mechanism for use in exercising both
      directions of the link.  This is useful as an aid in debugging,
      link quality determination, performance testing, and for numerous
      other functions.
      Upon reception of an Echo-Request in the LCP Opened state, an
      Echo-Reply MUST be transmitted.
      Echo-Request and Echo-Reply packets MUST only be sent in the LCP
      Opened state.  Echo-Request and Echo-Reply packets received in any
      state other than the LCP Opened state SHOULD be silently
      discarded.
   A summary of the Echo-Request and Echo-Reply packet formats 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic-Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+
   Code
      9 for Echo-Request;
      10 for Echo-Reply.
   Identifier
      On transmission, the Identifier field MUST be changed whenever the
      content of the Data field changes, and whenever a valid reply has
      been received for a previous request.  For retransmissions, the
      Identifier MAY remain unchanged.
      On reception, the Identifier field of the Echo-Request is copied
      into the Identifier field of the Echo-Reply packet.
   Magic-Number
      The Magic-Number field is four octets, and aids in detecting links
      which are in the looped-back condition.  Until the Magic-Number
      Configuration Option has been successfully negotiated, the Magic-
      Number MUST be transmitted as zero.  See the Magic-Number
      Configuration Option for further explanation.
   Data
      The Data field is zero or more octets, and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value.  The end of the field is indicated by the Length.
5.9.  Discard-Request
   Description
      LCP includes a Discard-Request Code in order to provide a Data
      Link Layer sink mechanism for use in exercising the local to
      remote direction of the link.  This is useful as an aid in
      debugging, performance testing, and for numerous other functions.
      Discard-Request packets MUST only be sent in the LCP Opened state.
      On reception, the receiver MUST silently discard any Discard-
      Request that it receives.
   A summary of the Discard-Request 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             |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Magic-Number                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+
   Code
      11 for Discard-Request.
   Identifier
      The Identifier field MUST be changed for each Discard-Request
      sent.
   Magic-Number
      The Magic-Number field is four octets, and aids in detecting links
      which are in the looped-back condition.  Until the Magic-Number
      Configuration Option has been successfully negotiated, the Magic-
      Number MUST be transmitted as zero.  See the Magic-Number
      Configuration Option for further explanation.
   Data
      The Data field is zero or more octets, and contains uninterpreted
      data for use by the sender.  The data may consist of any binary
      value.  The end of the field is indicated by the Length.