rfc1171.txt

RFC 的详细文档！

      On reception of a Configure-Nak, the Identifier field must match
      that of the last transmitted Configure-Request, or the packet is
      invalid and should be silently discarded.

      Reception of a valid Configure-Nak indicates that a new
      Configure-Request should be sent with the Configuration Options
      modified as specified in the Configure-Nak.

   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.



Perkins                                                        [Page 25]

RFC 1171                Point-to-Point Protocol                July 1990


   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.









































Perkins                                                        [Page 26]

RFC 1171                Point-to-Point Protocol                July 1990


4.4.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 manager), then a LCP implementation should
      transmit a LCP packet with the Code field set to 4 (Configure-
      Reject), the Identifier field copied from the received Configure-
      Request, and the Options field filled with only the unrecognized
      Configuration Options from the Configure-Request.  All
      recognizable and negotiable Configuration Options must be filtered
      out of the Configure-Reject, but otherwise the Configuration
      Options MUST not be reordered.

      On reception of a Configure-Reject, the Identifier field must
      match that of the last transmitted Configure-Request, or the
      packet is invalid.  Additionally, the Configuration Options in a
      Configure-Reject must be a proper subset of those in the last
      transmitted Configure-Request, or the packet is invalid.  Invalid
      packets should be silently discarded.

      Reception of a Configure-Reject indicates that a new Configure-
      Request should be sent which does 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.





Perkins                                                        [Page 27]

RFC 1171                Point-to-Point Protocol                July 1990


   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.














































Perkins                                                        [Page 28]

RFC 1171                Point-to-Point Protocol                July 1990


4.4.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.

      A LCP implementation wishing to close a connection should transmit
      a LCP packet with the Code field set to 5 (Terminate-Request) and
      the Data field filled with any desired data.  Terminate-Request
      packets should continue to be sent until Terminate-Ack is
      received, the Physical Layer indicates that it has gone down, or a
      sufficiently large number have been transmitted such that the
      remote end is down with reasonable certainty.

      Upon reception of a Terminate-Request, a LCP packet MUST be
      transmitted with the Code field set to 6 (Terminate-Ack), the
      Identifier field copied from the Terminate-Request packet, and the
      Data field filled with any desired data.

      Reception of an unelicited Terminate-Ack indicates that the
      connection has been closed.

   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

      The Identifier field is one octet and aids in matching requests
      and replies.






Perkins                                                        [Page 29]

RFC 1171                Point-to-Point Protocol                July 1990


   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 and may be of any length from zero to the established
      maximum Information field length minus four.













































Perkins                                                        [Page 30]

RFC 1171                Point-to-Point Protocol                July 1990


4.4.6.  Code-Reject


   Description

      Reception of a LCP packet with an unknown Code indicates that one
      of the communicating LCP implementations is faulty or incomplete.
      This error MUST be reported back to the sender of the unknown Code
      by transmitting a LCP packet with the Code field set to 7 (Code-
      Reject), and the inducing packet copied to the Rejected-Packet
      field.

      Upon reception of a Code-Reject, a LCP implementation should make
      an immediate transition to the Closed state, and should report the
      error, 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 is one octet and is for use by the
      transmitter.

   Rejected-Packet

      The Rejected-Packet field contains a copy of the LCP packet which
      is being rejected.  It begins with the rejected Code field; it
      does not include any PPP Data Link Layer headers.  The Rejected-
      Packet should be truncated to comply with the established maximum
      Information field length.







Perkins                                                        [Page 31]

RFC 1171                Point-to-Point Protocol                July 1990


4.4.7.  Protocol-Reject


   Description

      Reception of a PPP frame with an unknown Data Link Layer Protocol
      indicates that the remote end is attempting to use a protocol
      which is unsupported at the local end.  This typically occurs when
      the remote end attempts to configure a new, but unsupported
      protocol.  If the LCP state machine is in the Open state, then
      this error MUST be reported back to the sender of the unknown
      protocol by transmitting a LCP packet with the Code field set to 8
      (Protocol-Reject), the Rejected-Protocol field set to the received
      Protocol, and the Data field filled with any desired data.

      Upon recep