rfc1172.txt

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

      specified authentication protocols.

      It is recommended that each PPP implementation support
      configuration of authentication parameters at least on a per-
      interface basis, if not a per peer entity basis.  The parameters
      should specify which authetication techniques are minimally
      required as a prerequisite to establishment of a PPP connection,
      either for the specified interface or for the specified peer
      entity.  Such configuration facilities are necessary to prevent an
      attacker from negotiating a reduced security authentication
      protocol, or no authentication at all, in an attempt to circumvent
      this authentication facility.

      If an implementation sends a Configure-Ack with this Configuration
      Option, then it is agreeing to authenticate with the specified
      protocol.  An implementation receiving a Configure-Ack with this
      Configuration Option should expect the remote end to authenticate
      with the acknowledged protocol.




Perkins & Hobby                                                 [Page 5]

RFC 1172                  PPP Initial Options                  July 1990


      There is no requirement that authentication be full duplex or that
      the same authentication protocol be used in both directions.  It
      is perfectly acceptable for different authentication protocols to
      be used in each direction.  This will, of course, depend on the
      specific authentication protocols negotiated.

      This document defines a simple Password Authentication Protocol in
      Section 4.  Development of other more secure protocols is
      encouraged.

   A summary of the Authentication-Type 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-Type       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Data ...
   +-+-+-+-+

   Type

      3

   Length

      >= 4

   Authentication-Type

      The Authentication-Type field is two octets and indicates the type
      of authentication protocol desired.  Values for the
      Authentication-Type are always the same as the PPP Data Link Layer
      Protocol field values for that same authentication protocol.  The
      most up-to-date values of the Authentication-Type field are
      specified in "Assigned Numbers" [2].  Initial values are assigned
      as follows:

         Value (in hex)          Protocol

         c023                    Password Authentication Protocol

   Data

      The Data field is zero or more octets and contains additional data
      as determined by the particular authentication protocol.




Perkins & Hobby                                                 [Page 6]

RFC 1172                  PPP Initial Options                  July 1990


   Default

      No authentication protocol necessary.


2.4.  Magic-Number

   Description

      This Configuration Option provides a way 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 Link-Quality-Monitoring Configuration Option.

      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 an 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 should be 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 should 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 (i.e., 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 loop-back is increased, and a new Magic-
      Number should be chosen.  In either case, a new Configure-Request
      should be sent with the new Magic-Number.



Perkins & Hobby                                                 [Page 7]

RFC 1172                  PPP Initial Options                  July 1990


      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 may 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, loop-backs 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 if its peer also transmits 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 may 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 Echo-Request, Echo-Reply, Discard-Request, and
      Link-Quality-Report LCP packets have a Magic-Number field which
      MUST normally be transmitted as zero, and MUST normally be ignored
      on reception.  However, once a Magic-Number has been successfully
      negotiated, an LCP implementation MUST begin transmitting these
      packets with the Magic-Number field set to its negotiated Magic-
      Number.  Additionally, the Magic-Number field of these packets may
      be inspected on reception. All received Magic-Number fields should
      be equal to either zero or the peer's unique Magic-Number,



Perkins & Hobby                                                 [Page 8]

RFC 1172                  PPP Initial Options                  July 1990


      depending on whether or not the peer negotiated one.  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 or or 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 an LCP Physical-Layer-Down
      event and make an immediate transition to the Closed state.  A
      further Active-Open event will begin the process of re-
      establishing the link, which can't complete until the loop-back
      condition is terminated and Magic-Numbers are successfully
      negotiated.  A more optimistic procedure (in the case of a loop-
      back) is to begin transmitting LCP Echo-Request packets until an
      appropriate Echo-Reply is received, indicating a termination of
      the loop-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 not be sent.

   Default

      None.



Perkins & Hobby                                                 [Page 9]

RFC 1172                  PPP Initial Options                  July 1990


2.5.  Link-Quality-Monitoring

   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 and is implemented by periodically transmitting
      Link-Quality-Report packets as described in Section 3.  The Link-
      Quality-Monitoring Configuration Option provides a way to enable
      the use of Link-Quality-Report packets, and also to negotiate the
      rate at which they are transmitted.  By default, Link Quality
      Monitoring and the use of Link-Quality-Report packets is disabled.

   A summary of the Link-Quality-Monitoring 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     |        Reporting-Period
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
       Reporting-Period (cont)     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type

      6

   Length

      6

   Reporting-Period

      The Reporting-Period field is four octets and indicates the
      maximum time in micro-seconds that the remote end should wait
      between transmission of LCP Link-Quality-Report packets.  A value
      of zero is illegal and should always be nak'd or rejected.  An LCP
      implementation is always free to transmit LCP Link-Quality-Report
      packets at a faster rate than that which was requested by, and
      acknowledged to, the remote end.

   Default

      None






Perkins & Hobby                                                [Page 10]

RFC 1172                  PPP Initial Options                  July 1990


2.6.  Protocol-Field-Compression

   Description

      This Configuration Option provides a way to negotiate the
      compression of the Data Link Layer Protocol field.  By default,
      all implementations must transmit standard PPP frames with two
      octet Protocol fields. However, 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 may be sent to inform the remote end
      that you can receive compressed single octet Protocol fields.
      Compressed Protocol fields may not be transmitted unless this
      Configuration Option has been received.

      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 representations for 3, 00000011
      and 00000000 00000011).

      In the interest of simplicity, the standard PPP frame uses this
      fact and always sends Protocol fields with a two octet
      representation.  Protocol field values less than 256 (decimal) are
      prepended with a single zero octet even though transmission of
      this, the zero and most significant octet, is unnecessary.

      However, when using low speed links, it is desirable to conserve
      bandwidth by sending as little redundant data as possible.  The
      Protocol 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 frames are compressible since data protocols
      are typically assigned with Protocol field values less than 256.

      To guarantee unambiguous recognition of LCP packets, the Protocol
      field must never be compressed when sending any LCP packet.  In
      addition, PPP implementations must continue to be robust and MUST
      accept PPP frames with double-octet, as well as single-octet,
      Protocol fields, and MUST NOT distinguish between them.

      When a Protocol field is compressed, the Data Link Layer FCS field



Perkins & Hobby                                                [Page 11]

RFC 1172                  PPP Initial Options                  July 1990


      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