⭐ 欢迎来到虫虫下载站! | 📦 资源下载 📁 资源专辑 ℹ️ 关于我们
⭐ 虫虫下载站

📄 rfc1171.txt

📁 著名的RFC文档,其中有一些文档是已经翻译成中文的的.
💻 TXT
📖 第 1 页 / 共 5 页
字号:
Perkins                                                        [Page 26]RFC 1171                Point-to-Point Protocol                July 19904.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 19904.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 19904.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 19904.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 reception of a Protocol-Reject, a LCP implementation should      stop transmitting frames of the indicated protocol.      Protocol-Reject packets may only be sent in the LCP Open state.      Protocol-Reject packets received in any state other than the LCP      Open state should be discarded and no further action should be      taken.   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 is one octet and is for use by the      transmitter.   Rejected-Protocol      The Rejected-Protocol field is two octets and contains the      Protocol of the Data Link Layer frame which is being rejected.Perkins                                                        [Page 32]RFC 1171                Point-to-Point Protocol                July 1990   Rejected-Information      The Rejected-Information field contains a copy from the frame      which is being rejected.  It begins with the Information field,      and does not include any PPP Data Link Layer headers or the FCS.      The Rejected-Information field should be truncated to comply with      the established maximum Information field length.Perkins                                                        [Page 33]RFC 1171                Point-to-Point Protocol                July 19

⌨️ 快捷键说明

复制代码 Ctrl + C
搜索代码 Ctrl + F
全屏模式 F11
切换主题 Ctrl + Shift + D
显示快捷键 ?
增大字号 Ctrl + =
减小字号 Ctrl + -