rfc2637.txt

来自「<VC++网络游戏建摸与实现>源代码」· 文本 代码 · 共 1,548 行 · 第 1/5 页

   Session

      PPTP is connection-oriented.  The PNS and PAC maintain state for
      each user that is attached to a PAC.  A session is created when
      end-to-end PPP connection is attempted between a dial user and the
      PNS.  The datagrams related to a session are sent over the tunnel
      between the PAC and PNS.

   Tunnel

      A tunnel is defined by a PNS-PAC pair.  The tunnel protocol is
      defined by a modified version of GRE [1,2].  The tunnel carries
      PPP datagrams between the PAC and the PNS.  Many sessions are
      multiplexed on a single tunnel.  A control connection operating
      over TCP controls the establishment, release, and maintenance of
      sessions and of the tunnel itself.

1.3.  Protocol Overview

   There are two parallel components of PPTP: 1) a Control Connection
   between each PAC-PNS pair operating over TCP and 2) an IP tunnel
   operating between the same PAC-PNS pair which is used to transport
   GRE encapsulated PPP packets for user sessions between the pair.



Hamzeh, et al.               Informational                      [Page 6]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


1.3.1.  Control Connection Overview

   Before PPP tunneling can occur between a PAC and PNS, a control
   connection must be established between them. The control connection
   is a standard TCP session over which PPTP call control and management
   information is passed. The control session is logically associated
   with, but separate from, the sessions being tunneled through a PPTP
   tunnel.  For each PAC-PNS pair both a tunnel and a control connection
   exist. The control connection is responsible for establishment,
   management, and release of sessions carried through the tunnel. It is
   the means by which a PNS is notified of an incoming call at an
   associated PAC, as well as the means by which a PAC is instructed to
   place an outgoing dial call.

   A control connection can be established by either the PNS or the PAC.
   Following the establishment of the required TCP connection, the PNS
   and PAC establish the control connection using the Start-Control-
   Connection-Request and -Reply messages.  These messages are also used
   to exchange information about basic operating capabilities of the PAC
   and PNS.  Once the control connection is established, the PAC or PNS
   may initiate sessions by requesting outbound calls or responding to
   inbound requests. The control connection may communicate changes in
   operating characteristics of an individual user session with a Set-
   Link-Info message.  Individual sessions may be released by either the
   PAC or PNS, also through Control Connection messages.

   The control connection itself is maintained by keep-alive echo
   messages.  This ensures that a connectivity failure between the PNS
   and the PAC can be detected in a timely manner. Other failures can be
   reported via the

   Wan-Error-Notify message, also on the control connection.

   It is intended that the control connection will also carry management
   related messages in the future, such as a message allowing the PNS to
   request the status of a given PAC; these message types have not yet
   been defined.

1.3.2.  Tunnel Protocol Overview

   PPTP requires the establishment of a tunnel for each communicating
   PNS-PAC pair.  This tunnel is used to carry all user session PPP
   packets for sessions involving a given PNS-PAC pair.  A key which is
   present in the GRE header indicates which session a particular PPP
   packet belongs to.






Hamzeh, et al.               Informational                      [Page 7]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


   In this manner, PPP packets are multiplexed and demultiplexed over a
   single tunnel between a given PNS-PAC pair.  The value to use in the
   key field is established by the call establishment procedure which
   takes place on the control connection.

   The GRE header also contains acknowledgment and sequencing
   information that is used to perform some level of congestion-control
   and error detection over the tunnel.  Again the control connection is
   used to determine rate and buffering parameters that are used to
   regulate the flow of PPP packets for a particular session over the
   tunnel.  PPTP does not specify the particular algorithms to use for
   congestion-control and flow-control.  Suggested algorithms for the
   determination of adaptive time-outs to recover from dropped data or
   acknowledgments on the tunnel are included in section 4.4 of this
   document.

1.4.  Message Format and Protocol Extensibility

   PPTP defines a set of messages sent as TCP data on the control
   connection between a PNS and a given PAC.  The TCP session for the
   control connection is established by initiating a TCP connection to
   port 1723 [6]. The source port is assigned to any unused port number.

   Each PPTP Control Connection message begins with an 8 octet fixed
   header portion.  This fixed header contains the following: the total
   length of the message, the PPTP Message Type indicator, and a "Magic
   Cookie".

   Two Control Connection message types are indicated by the PPTP
   Message Type field:

         1 - Control Message
         2 - Management Message

   Management messages are currently not defined.

   The Magic Cookie is always sent as the constant 0x1A2B3C4D.  Its
   basic purpose is to allow the receiver to ensure that it is properly
   synchronized with the TCP data stream.  It should not be used as a
   means for resynchronizing the TCP data stream in the event that a
   transmitter issues an improperly formatted message.  Loss of
   synchronization must result in immediate closing of the control
   connection's TCP session.

   For clarity, all Control Connection message templates in the next
   section include the entire PPTP Control Connection message header.
   Numbers preceded by 0x are hexadecimal values.




Hamzeh, et al.               Informational                      [Page 8]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


The currently defined Control Messages, grouped by function, are:

         Control Message                        Message Code

         (Control Connection Management)

         Start-Control-Connection-Request            1
         Start-Control-Connection-Reply              2
         Stop-Control-Connection-Request             3
         Stop-Control-Connection-Reply               4
         Echo-Request                                5
         Echo-Reply                                  6

         (Call Management)

         Outgoing-Call-Request                       7
         Outgoing-Call-Reply                         8
         Incoming-Call-Request                       9
         Incoming-Call-Reply                        10
         Incoming-Call-Connected                    11
         Call-Clear-Request                         12
         Call-Disconnect-Notify                     13

         (Error Reporting)

         WAN-Error-Notify                           14

         (PPP Session Control)

         Set-Link-Info                              15

   The Start-Control-Connection-Request and -Reply messages determine
   which version of the Control Connection protocol will be used.  The
   version number field carried in these messages consists of a version
   number in the high octet and a revision number in the low octet.
   Version handling is described in section 2. The current value of the
   version number field is 0x0100 for version 1, revision 0.

   The use of the GRE-like header for the encapsulation of PPP user
   packets is specified in section 4.1.

   The MTU for the user data packets encapsulated in GRE is 1532 octets,
   not including the IP and GRE headers.








Hamzeh, et al.               Informational                      [Page 9]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


2.  Control Connection Protocol Specification

   Control Connection messages are used to establish and clear user
   sessions.  The first set of Control Connection messages are used to
   maintain the control connection itself.  The control connection is
   initiated by either the PNS or PAC after they establish the
   underlying TCP connection.  The procedure and configuration
   information required to determine which TCP connections are
   established is not covered by this protocol.

   The following Control Connection messages are all sent as user data
   on the established TCP connection between a given PNS-PAC pair.  Note
   that care has been taken to ensure that all word (2 octet) and
   longword (4 octet) values begin on appropriate boundaries.  All data
   is sent in network order (high order octets first).  Any "reserved"
   fields MUST be sent as 0 values to allow for protocol extensibility.

2.1.  Start-Control-Connection-Request

   The Start-Control-Connection-Request is a PPTP control message used
   to establish the control connection between a PNS and a PAC.  Each
   PNS-PAC pair requires a dedicated control connection to be
   established.  A control connection must be established before any
   other PPTP messages can be issued.  The establishment of the control
   connection can be initiated by either the PNS or PAC.  A procedure
   which handles the occurrence of a collision between PNS and PAC
   Start-Control-Connection-Requests is described in section 3.1.3.
























Hamzeh, et al.               Informational                     [Page 10]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |             Length            |       PPTP Message Type       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Magic Cookie                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Control Message Type      |           Reserved0           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Protocol Version        |           Reserved1           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     Framing Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                      Bearer Capabilities                      |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |       Maximum Channels        |       Firmware Revision       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                     Host Name (64 octets)                     +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                   Vendor String (64 octets)                   +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Length                   Total length in octets of this PPTP
                               message, including the entire PPTP
                               header.

      PPTP Message Type        1 for Control Message.

      Magic Cookie             0x1A2B3C4D. This constant value is used
                               as a sanity check on received messages
                               (see section 1.4).

      Control Message Type     1 for Start-Control-Connection-Request.

      Reserved0                This field MUST be 0.

      Protocol Version         The version of the PPTP protocol that the
                               sender wishes to use.

      Reserved1                This field MUST be 0.







Hamzeh, et al.               Informational                     [Page 11]

RFC 2637        Point-to-Point Tunneling Protocol (PPTP)       July 1999