rfc1570.txt

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

Network Working Group                                 W. Simpson, Editor
Request for Comments: 1570                                    Daydreamer
Updates: 1548                                               January 1994
Category: Standards Track


                           PPP LCP Extensions

Status of this Memo

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

Abstract

   The Point-to-Point Protocol (PPP) [1] provides a standard method for
   transporting multi-protocol datagrams over point-to-point links.  PPP
   defines an extensible Link Control Protocol (LCP) for establishing,
   configuring, and testing the data-link connection.  This document
   defines several additional LCP features which have been suggested
   over the past few years.

   This document is the product of the Point-to-Point Protocol Working
   Group of the Internet Engineering Task Force (IETF).  Comments should
   be submitted to the [e-mail] mailing list.

Table of Contents

     1.     Additional LCP Packets ................................    1
        1.1       Identification ..................................    1
        1.2       Time-Remaining ..................................    3
     2.     Additional LCP Configuration Options ..................    6
        2.1       FCS-Alternatives ................................    6
           2.1.1  LCP considerations ..............................    7
           2.1.2  Null FCS ........................................    8
        2.2       Self-Describing-Padding .........................    9
        2.3       Callback ........................................   11
        2.4       Compound-Frames .................................   12
           2.4.1  LCP considerations ..............................   14
     APPENDICES ...................................................   15
     A.     Fast Frame Check Sequence (FCS) Implementation ........   15
        A.1       32-bit FCS Computation Method ...................   15
     SECURITY CONSIDERATIONS ......................................   17
     REFERENCES ...................................................   17
     ACKNOWLEDGEMENTS .............................................   18
     CHAIR'S ADDRESS ..............................................   18
     EDITOR'S ADDRESS .............................................   18








Simpson                                                         [Page i]
RFC 1570                   PPP LCP extensions               January 1994


1.  Additional LCP Packets

   The Packet format and basic facilities are already defined for LCP
   [1].

   Up-to-date values of the LCP Code field are specified in the most
   recent "Assigned Numbers" RFC [2].  This specification concerns the
   following values:

      12      Identification
      13      Time-Remaining




1.1.  Identification

   Description

      This Code provides a method for an implementation to identify
      itself to its peer.  This Code might be used for many diverse
      purposes, such as link troubleshooting, license enforcement, etc.

      Identification is a Link Maintenance packet.  Identification
      packets MAY be sent at any time, including before LCP has reached
      the Opened state.

      The sender transmits a LCP packet with the Code field set to 12
      (Identification), the Identifier field set, the local Magic-Number
      (if any) inserted, and the Message field filled with any desired
      data, but not exceeding the default MRU minus eight.

      Receipt of an Identification packet causes the RXR or RUC event.
      There is no response to the Identification packet.

      Receipt of a Code-Reject for the Identification packet SHOULD
      generate the RXJ+ (permitted) event.

      Rationale:

         This feature is defined as part of LCP, rather than as a
         separate PPP Protocol, in order that its benefits may be
         available during the earliest possible stage of the Link
         Establishment phase.  It allows an operator to learn the
         identification of the peer even when negotiation is not
         converging.  Non-LCP packets cannot be sent during the Link
         Establishment phase.




Simpson                                                         [Page 1]
RFC 1570                   PPP LCP extensions               January 1994


         This feature is defined as a separate LCP Code, rather than a
         Configuration-Option, so that the peer need not include it with
         other items in configuration packet exchanges, and handle
         "corrected" values or "rejection", since its generation is both
         rare and in one direction.  It is recommended that
         Identification packets be sent whenever a Configure-Reject is
         sent or received, as a final message when negotiation fails to
         converge, and when LCP reaches the Opened state.

   A summary of the Identification 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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Message ...
   +-+-+-+-+-+-+-+-+


   Code

      12 for Identification

   Identifier

      The Identifier field MUST be changed for each Identification sent.

   Length

      >= 8

   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.

   Message

      The Message field is zero or more octets, and its contents are
      implementation dependent.  It is intended to be human readable,
      and MUST NOT affect operation of the protocol.  It is recommended



Simpson                                                         [Page 2]
RFC 1570                   PPP LCP extensions               January 1994


      that the message contain displayable ASCII characters 32 through
      126 decimal.  Mechanisms for extension to other character sets are
      the topic of future research.  The size is determined from the
      Length field.

      Implementation Note:

         The Message will usually contain such things as the sender's
         hardware type, PPP software revision level, and PPP product
         serial number, MIB information such as link speed and interface
         name, and any other information that the sender thinks might be
         useful in debugging connections.  The format is likely to be
         different for each implementor, so that those doing serial
         number tracking can validate their numbers.  A robust
         implementation SHOULD treat the Message as displayable text,
         and SHOULD be able to receive and display a very long Message.



1.2.  Time-Remaining

   Description

      This Code provides a mechanism for notifying the peer of the time
      remaining in this session.

      The nature of this information is advisory only.  It is intended
      that only one side of the connection will send this packet
      (generally a "network access server").  The session is actually
      concluded by the Terminate-Request packet.

      Time-Remaining is a Link Maintenance packet.  Time-Remaining
      packets may only be sent in the LCP Opened state.

      The sender transmits a LCP packet with the Code field set to 13
      (Time-Remaining), the Identifier field set, the local Magic-Number
      (if any) inserted, and the Message field filled with any desired
      data, but not exceeding the peer's established MRU minus twelve.

      Receipt of an Time-Remaining packet causes the RXR or RUC event.
      There is no response to the Time-Remaining packet.

      Receipt of a Code-Reject for the Time-Remaining packet SHOULD
      generate the RXJ+ (permitted) event.

      Rationale:

         This notification is defined as a separate LCP Code, rather



Simpson                                                         [Page 3]
RFC 1570                   PPP LCP extensions               January 1994


         than a Configuration-Option, in order that changes and warning
         messages may occur dynamically during the session, and that the
         information might be determined after Authentication has
         occurred.  Typically, this packet is sent when the link enters
         Network-Layer Protocol phase, and at regular intervals
         throughout the session, particularly near the end of the
         session.

   A summary of the Time-Remaining 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                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Seconds-Remaining                       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |    Message ...
   +-+-+-+-+-+-+-+-+


   Code

      13 for Time-Remaining

   Identifier

      The Identifier field MUST be changed for each Time-Remaining sent.

   Length

      >= 12

   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.

   Seconds-Remaining

      The Seconds-Remaining field is four octets and indicates the
      number of integral seconds remaining in this session.  This 32 bit



Simpson                                                         [Page 4]
RFC 1570                   PPP LCP extensions               January 1994


      unsigned value is sent most significant octet first.  A value of
      0xffffffff (all ones) represents no timeout, or "forever".

   Message

      The Message field is zero or more octets, and its contents are
      implementation dependent.  It is intended to be human readable,
      and MUST NOT affect operation of the protocol.  It is recommended
      that the message contain displayable ASCII characters 32 through
      126 decimal.  Mechanisms for extension to other character sets are
      the topic of future research.  The size is determined from the
      Length field.







































Simpson                                                         [Page 5]
RFC 1570                   PPP LCP extensions               January 1994


2.  Additional LCP Configuration Options

   The Configuration Option format and basic options are already defined
   for LCP [1].

   Up-to-date values of the LCP Option Type field are specified in the
   most recent "Assigned Numbers" RFC [2].  This document concerns the
   following values:

      9       FCS-Alternatives