rfc1172.txt

<VC++网络游戏建摸与实现>源代码

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