pptp-draft.txt

pptp第二层隧道模块

Internet Draft                                  Kory Hamzeh
                                                Ascend Communications
                                                Gurdeep Singh Pall
                                                Microsoft Corporation
                                                William Verthein
                                                U.S. Robotics/3Com
                                                Jeff Taarud
                                                Copper Mountain Networks
                                                W. Andrew Little
                                                ECI Telematics
July 1997
Expire in six months


                  Point-to-Point Tunneling Protocol--PPTP
                       draft-ietf-pppext-pptp-02.txt

Status of this Memo

   This document is an Internet-Draft.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   To learn the current status of any Internet-Draft, please check the
   "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow
   Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
   munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
   ftp.isi.edu (US West Coast).

Abstract

        This document specifies a protocol which allows the Point
        to Point Protocol (PPP) to be tunneled through an IP
        network. PPTP does not specify any changes to the PPP
        protocol but rather describes a new vehicle for carrying
        PPP. A client-server architecture is defined in order to
        decouple functions which exist in current Network Access
        Servers (NAS) and support Virtual Private Networks (VPNs).
        The PPTP Network Server (PNS) is envisioned to run on a
        general purpose operating system while the client, referred
        to as a PPTP Access Concentrator (PAC) operates on a dial
        access platform. PPTP specifies a call-control and



Hamzeh, et al                                                   [Page 1]

Internet Draft                    PPTP                         July 1997


        management protocol which allows the server to control
        access for dial-in circuit switched calls originating from
        a PSTN or ISDN or to initiate outbound circuit-switched
        connections. PPTP uses an enhanced GRE (Generic Routing
        Encapsulation) mechanism to provide a flow- and
        congestion-controlled encapsulated datagram service for
        carrying PPP packets.

1. Introduction

   PPTP allows existing Network Access Server (NAS) functions to be
   separated using a client-server architecture. Traditionally, the
   following functions are implemented by a NAS:

   1) Physical native interfacing to PSTN or ISDN and control of
      external modems or terminal adapters.

      A NAS may interface directly to a telco analog or digital circuit
      or attach via an external modem or terminal adapter. Control of a
      circuit-switched connection is accomplished with either modem
      control or DSS1 ISDN call control protocols.

      The NAS, in conjunction with the modem or terminal adapters, may
      perform rate adaption, analog to digital conversion, sync to async
      conversion or a number of other alterations of data streams.

   2) Logical termination of a Point-to-Point-Protocol (PPP) Link
      Control Protocol (LCP) session.

   3) Participation in PPP authentication protocols [3].

   4) Channel aggregation and bundle management for PPP Multilink
      Protocol.

   5) Logical termination of various PPP network control protocols
      (NCP).

   6) Multiprotocol routing and bridging between NAS interfaces.

   PPTP divides these functions between the PAC and PNS. The PAC is
   responsible for functions 1, 2, and possibly 3. The PNS may be
   responsible for function 3 and is responsible for functions 4, 5, and
   6. The protocol used to carry PPP protocol data units (PDUs) between
   the PAC and PNS, as well as call control and management is addressed
   by PPTP.

   The decoupling of NAS functions offers these benefits:




Hamzeh, et al                                                   [Page 2]

Internet Draft                    PPTP                         July 1997


      Flexible IP address management. Dial-in users may maintain a
      single IP address as they dial into different PACs as long as they
      are served from a common PNS. If an enterprise network uses
      unregistered addresses, a PNS associated with the enterprise
      assigns addresses meaningful to the private network.

      Support of non-IP protocols for dial networks behind IP networks.
      This allows Appletalk and IPX, for example to be tunneled through
      an IP-only provider. The PAC need not be capable of processing
      these protocols.

      A solution to the "multilink  hunt-group splitting" problem.
      Multilink PPP, typically used to aggregate ISDN B channels,
      requires that all of the channels composing a multilink bundle be
      grouped at a single NAS. Since a multilink PPP bundle can be
      handled by a single PNS, the channels comprising the bundle may be
      spread across multiple PACs.


1.1 Protocol Goals and Assumptions

   The PPTP protocol is implemented only by the PAC and PNS. No other
   systems need to be aware of PPTP. Dial networks may be connected to a
   PAC without being aware of PPTP. Standard PPP client software should
   continue to operate on tunneled PPP links.

   PPTP can also be used to tunnel a PPP session over an IP network. In
   this configuration the PPTP tunnel and the PPP session runs between
   the same two machines with the caller acting as a PNS.

   It is envisioned that there will be a many-to-many relationship
   between PACs and PNSs.  A PAC may provide service to many PNSs. For
   example, an Internet service provider may choose to support PPTP for
   a number of private network clients and create VPNs for them. Each
   private network may operate one or more PNSs. A single PNS may
   associate with many PACs to concentrate traffic from a large number
   of geographically diverse sites.

   PPTP uses an extended version of GRE to carry user PPP packets. These
   enhancements allow for low-level congestion and flow control to be
   provided on the tunnels used to carry user data between PAC and PNS.
   This mechanism allows for efficient use of the bandwidth available
   for the tunnels and avoids unnecessary retransmisions and buffer
   overruns.  PPTP does not dictate the particular algorithms to be used
   for this low level control but it does define the parameters that
   must be communicated in order to allow such algorithms to work.
   Suggested algorithms are included in Appendix A.


1.2 Terminology


Hamzeh, et al                                                   [Page 3]

Internet Draft                    PPTP                         July 1997


      Analog Channel

         A circuit-switched communication path which is intended to
         carry 3.1 Khz audio in each direction.

      Digital Channel

         A circuit-switched communication path which is intended to
         carry digital information in each direction.

      Call

         A connection or attempted connection between two terminal
         endpoints on a PSTN or ISDN--for example, a telephone call
         between two modems.

      Control Connection

         A control connection is created for each PAC, PNS pair and
         operates over TCP [4]. The control connection governs aspects
         of the tunnel and of sessions assigned to the tunnel.

      Dial User

         An end-system or router attached to an on-demand PSTN or ISDN
         which is either the initiator or recipient of a call.

      Network Access Server (NAS)

         A device providing temporary, on-demand network access to
         users.  This access is point-to-point using PSTN or ISDN lines.

      PPTP Access Concentrator (PAC)

         A device attached to one or more PSTN or ISDN lines capable of
         PPP operation and of handling the PPTP protocol. The PAC need
         only implement TCP/IP to pass traffic to one or more PNSs. It
         may also tunnel non-IP protocols.

      PPTP Network Server (PNS)

         A PNS is envisioned to operate on general-purpose
         computing/server platforms. The PNS handles the server side of
         the PPTP protocol. Since PPTP relies completely on TCP/IP and
         is independent of the interface hardware, the PNS may use any
         combination of IP interface hardware including LAN and WAN
         devices.




Hamzeh, et al                                                   [Page 4]

Internet Draft                    PPTP                         July 1997


      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.

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



Hamzeh, et al                                                   [Page 5]

Internet Draft                    PPTP                         July 1997


   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.  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 Appendix A of this
   document.

1.4 Specification Language

   In this document, several words are used to signify the requirements
   of the specification.  These words are often capitalized.

      MUST                This word, or the adjective "required", means
                          that the definition is an absolute requirement
                          of the specification.

      MUST NOT            This phrase means that the definition is an
                          absolute prohibition of the specification.

      SHOULD              This word, or the adjective "recommended",



Hamzeh, et al                                                   [Page 6]