[Search] [txt|pdfized|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]
Versions: 00 01 02 03 04 05 06 07 08                                    
Network Working Group                                             J. Lau
Internet-Draft                                               M. Townsley
Category: Standards Track                                    A. Valencia
<draft-ietf-l2tpext-l2tp-ppp-01.txt>                             G. Zorn
                                                           cisco Systems
                                                                M. Verma
                                               CommWorks, a 3Com company
                                                               I. Goyret
                                                     Lucent Technologies
                                                                 G. Pall
                                                   Microsoft Corporation
                                                               A. Rubens
                                                                 Nexthop
                                                               B. Palter
                                                        Redback Networks
                                                           November 2001


            PPP Tunneling Using Layer Two Tunneling Protocol


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of section 10 of RFC2026.

   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.ietf.org (US East Coast), nic.nordu.net (Europe),
   ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific Rim).

   The distribution of this memo is unlimited.  It is filed as <draft-
   ietf-l2tpext-l2tp-ppp-01.txt> and expires May 2002.  Please send
   comments to the L2TP mailing list (l2tp@l2tp.net).

Copyright Notice





Townsley, et al.             Standards Track                    [Page 1]


INTERNET DRAFT                    L2TP                     November 2001


   Copyright (C) The Internet Society (1999).  All Rights Reserved.

Abstract

   This document describes the use of Layer Two Tunneling Protocol
   (L2TP) to tunnel PPP packets.













































Townsley, et al.             Standards Track                    [Page 2]


INTERNET DRAFT                    L2TP                     November 2001


   Contents

   Status of this Memo..........................................    1

   1. Introduction..............................................    3
      1.1 Specification of Requirements.........................    4
      1.2 Terminology...........................................    4

   2. Topology..................................................    5

   3. Control Channel Specifics for PPP.........................    5

   4. Data Channel Specifics for PPP............................    6
      4.1 PPP-Specific Sublayer.................................    6
      4.2 Forwarding PPP Frames.................................    7

   5. AVP Description...........................................    7
      5.1 PPP-Specific AVPs.....................................    8
         5.1.1 Control Connection Management AVPs...............    8
         5.1.2 Call Management AVPs.............................    9
         5.1.3 Proxy LCP and Authentication AVPs................   13
         5.1.4 Call Status AVPs.................................   17
      5.2 Service Type Independent AVPs.........................   18

   6. Data Channel Sequencing...................................   19
      6.1 Sequence Numbers......................................   19
      6.2 Data Channel Sequencing over Specific Media...........   20

   7. IANA Considerations.......................................   21
      7.1 AVP Attributes........................................   21
      7.2 SLI Message Type......................................   21
      7.3 Framing Capabilities and Bearer Capabilities..........   21
      7.4 Framing Type and Bearer Type..........................   21
      7.5 Proxy Authen Type AVP Values..........................   22
      7.6 PPP Sublayer Header Bits..............................   22

   8. References................................................   22

   9. Acknowledgments...........................................   23

   10. Authors' Addresses.......................................   24

1. Introduction

   The Point-to-Point Protocol (PPP) is a data link layer protocol that
   provides a standard method for carrying multiprotocol packets across
   point-to-point links.  It is the most commonly used protocol to
   provide remote access over various access media such as dial-up POTS,



Townsley, et al.             Standards Track                    [Page 3]


INTERNET DRAFT                    L2TP                     November 2001


   ISDN, ADSL, etc.

   Typically, a user obtains a Layer 2 (L2) connection to a Network
   Access Server (NAS) using one of a number of techniques (e.g. dial-up
   POTS, ISDN, ADSL, etc.), then runs PPP over that connection.  In such
   a configuration, the L2 termination point and PPP session endpoint
   reside on the same physical device (i.e. the NAS).

   Tunneling protocols, such as the Layer Two Tunneling Protocol defined
   in [L2TP], extend PPP by allowing the L2 and PPP endpoints to reside
   on different devices that are interconnected by a network.  This
   separation allows the actual processing of PPP packets to be divorced
   from the termination of the L2 circuit.

   This document defines the specific mechanisms for tunneling of PPP
   using L2TP.

   This is a companion document to be read in conjunction with [L2TP].
   A large part of this document is derived from [RFC2661], which
   describes the L2TP protocol signaling as well as the encapsulation
   method to tunnel PPP sessions.  This document is a result of the
   rewriting of [RFC2661] to separate the base L2TP protocol from the
   PPP tunneling details.

1.1 Specification of Requirements

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].

1.2 Terminology

   This document uses terminology defined in [L2TP].  Additional
   terminology is defined here.

   Called Number

      The telephone number dialed by a caller to reach the receiver of
      the call.

   Calling Number

      The telephone number of the caller.

   CHAP

      Challenge Handshake Authentication Protocol [RFC1994], a point-to-
      point cryptographic challenge/response authentication protocol in



Townsley, et al.             Standards Track                    [Page 4]


INTERNET DRAFT                    L2TP                     November 2001


      which the cleartext password is not passed over the line.

   DSLAM

      Digital Subscriber Line (DSL) Access Module.  A network device
      used in the deployment of DSL service.  This is typically a
      concentrator of individual DSL lines located in a central office
      (CO) or local exchange.

   Network Access Server (NAS)

      A device providing local network access to users across a remote
      access network, such as the PSTN.

   POTS

      Plain Old Telephone Service.

2. Topology

   Although PPP tunneling can be deployed in all of the different
   tunneling models specified in [L2TP], it is most commonly deployed in
   the LAC-LNS reference model.  The LAC physically terminates the L2
   connection and tunnels the PPP packets to the LNS.  The LNS then
   terminates the logical PPP connection.

3. Control Channel Specifics for PPP

   When PPP is tunneled through L2TP, a session control message, Set-
   Link-Info (SLI), is used to send PPP-specific link level information
   from the LNS to the LAC.

   The SLI is sent by the LNS to the LAC to set any PPP-negotiated
   options.  It is sent after the last LCP CONFACK is received during
   PPP LCP negotiation.  This AVP contains any relevant link level
   parameters of which the LAC may need to be aware (e.g. ACCM info).
   If there is no relevant information to be sent in the SLI, then the
   sending of this message MAY be omitted.  Since LCP may be
   renegotiated at any time, an SLI may be sent at any time during the
   life of the call.  For this reason, the LAC MUST be able to update
   its internal call information and behavior on an active session.
   Furthermore, if there are packets in queue at the LAC when an SLI is
   received, these must be flushed before applying the SLI information
   to the link.

   If the PPP session at the LNS renegotiates LCP during the call, an
   SLI MUST be sent to the LAC to return link level information to the
   initial default values while the negotiation occurs.  However, if the



Townsley, et al.             Standards Track                    [Page 5]


INTERNET DRAFT                    L2TP                     November 2001


   last SLI sent was already set to default values or no SLI was sent at
   all, this step MAY be omitted.

   The following AVPs MUST be present in the SLI:

   Message Type

      This AVP is described in [L2TP].  In the SLI, the value of this
      attribute is 16.

   ACCM

      This AVP is described in Section 5.1.4.

4. Data Channel Specifics for PPP

   This section describes the encapsulation mechanism for forwarding PPP
   frames over the L2TP data channel.

4.1 PPP-Specific Sublayer

   According to the base L2TP specification [L2TP], the header format for
   the data messages consists of a fixed header followed by a L2-specific
   sublayer.  The PPP sublayer is formatted as follows:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |P|S|x|x| OffSz | Reserved      | Sequence Number               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Offset padding... (optional, up to 15 octets)
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

             Figure 4.1: PPP Sublayer in L2TP Data Message Header

   If the Priority (P) bit is 1, this data message should receive
   preferential treatment in its local queuing and transmission.

   If the Sequence (S) bit is 1, it indicates that the Sequence Number
   field has meaningful data and that the receiver of this data packet
   should interpret it accordingly.

   The x bits are reserved for future extensions.  All reserved bits
   MUST be set to 0 on outgoing messages and ignored on incoming
   messages.

   The Offset Size (OffSz) field specifies the number of octets past the
   PPP sublayer header at which the payload data is expected to start.



Townsley, et al.             Standards Track                    [Page 6]


INTERNET DRAFT                    L2TP                     November 2001


   An Offset Size of 0 indicates no offset.  Otherwise, the PPP sublayer
   header ends after the last octet of the Offset Padding.  The maximum
   offset value that may be specified is 15 octets.

   The Sequence Number field indicates the sequence number for this data
   message, beginning at zero and incrementing by one (modulo 2**16) for
   each message sent.  See Section 6.1 for more information on using
   this field.

   The minimum length for the PPP sublayer is 4 octets (corresponding to
   an Offset Size of 0).

4.2 Forwarding PPP Frames

   PPP tunneling via L2TP utilizes both the control connection for
   session management and the base L2TP encapsulation to tunnel the PPP
   frames.  Both of these mechanisms are defined in [L2TP].

   After L2TP control channel establishment (see [L2TP] for details on
   control channel establishment), PPP frames are tunneled.

   The PPP frames from the remote system are received at the LAC,
   stripped of CRC, link framing, and transparency bytes, encapsulated
   with the PPP sublayer header followed by the fixed L2TP data header
   [L2TP], and forwarded over the session.  The LNS receives the L2TP
   packet and processes the encapsulated PPP frame as if it were
   received on a local PPP interface.  The LNS assumes the operation of
   PPP over HDLC and performs the HDLC Address and Control field
   processing for PPP frames.  Besides this HDLC processing, all other
   framing operations (e.g. CRC, character escaping, etc.) are handled
   by the LAC.

   When encapsulating the PPP frame in L2TP, both the LAC and the LNS
   MUST always include the HDLC header (Address and Control fields) as
   well as the PPP Protocol ID fields along with the PPP frame.  This
   implies that the LNS MUST always reject the Address and Control Field
   Compression (ACFC) as well as the Protocol Field Compression (PFC)
   LCP options.  For non-HDLC connections between the LAC and the remote
   systems, the LAC MUST translate the addressing method to HDLC
   addressing.

5. AVP Description

   The base L2TP specification [L2TP] describes the use of service type
   specific Attribute Value Pairs (AVPs).  These AVPs are specific to
   the L2 payload carried by the L2TP sessions.  This section provides a
   description of all PPP-specific AVPs.  It also provides additional
   PPP-specific information about certain other service-independent AVPs



Townsley, et al.             Standards Track                    [Page 7]


INTERNET DRAFT                    L2TP                     November 2001


   when PPP is tunneled by L2TP.

   Following the name of each AVP is a list indicating the message types
   that utilize each AVP.  These message types are described in the base
   L2TP specification [L2TP].  After each AVP title follows a short
   description of the purpose of the AVP, a detail (including a graphic)
   of the format for the Attribute Value, and any additional information
   needed for proper use of the AVP.

5.1 PPP-Specific AVPs

5.1.1 Control Connection Management AVPs

   The AVPs described in this section are included in the control
   connection messages.

Framing Capabilities (SCCRP, SCCRQ)

   The Framing Capabilities AVP, Attribute Type 3, provides the peer
   with an indication of the types of PPP framing that will be supported
   for outgoing call requests.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reserved for future framing type definitions          |A|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Attribute Value field is a 32-bit mask, with two bits defined.
   If bit A is set, asynchronous framing is supported.  If bit S is set,
   synchronous framing is supported.

   The framing capabilities defined in this AVP refer only to the
   physical interfaces available for dialout usage on an LAC.  An LNS
   MUST not send an OCRQ with a Framing Type AVP specifying a value not
   advertised in this AVP.  Presence of this message is not a guarantee
   that a given outgoing call will be placed by the sender if requested,
   just that the physical capability exists.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) is 10.

Bearer Capabilities (SCCRP, SCCRQ)

   The Bearer Capabilities AVP, Attribute Type 4, provides the peer with
   an indication of the bearer device types supported by the hardware



Townsley, et al.             Standards Track                    [Page 8]


INTERNET DRAFT                    L2TP                     November 2001


   interfaces of the sender for outgoing calls.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Reserved for future bearer type definitions         |V|A|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   This is a 32-bit mask, with two bits defined.  If bit A is set,
   analog access is supported.  If bit D is set, digital access is
   supported.  If bit V is set, virtual access is supported.  (Virtual
   access refers to access in which there is no physical point-to-point
   link.)

   The bearer capabilities defined in this AVP refer only to the
   physical interfaces available for dialout usage on an LAC.  An LNS
   MUST not send an OCRQ with a Bearer Type AVP specifying a value not
   advertised in this AVP.

   This AVP MUST be present if the sender can place outgoing calls when
   requested.  Presence of this message is not a guarantee that a given
   outgoing call will be placed by the sender if requested, just that
   the physical capability exists.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) is 10.

5.1.2 Call Management AVPs

Bearer Type (ICRQ, OCRQ)

   The Bearer Type AVP, Attribute Type 18, encodes the bearer type for
   the incoming or outgoing call.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved for future Bearer Types              |V|A|D|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Bearer Type is a 32-bit bit mask indicating the bearer capability
   of the call (ICRQ) or required for the call (OCRQ).  Bit A refers to
   an analog channel.  Bit D refers to a digital channel.  Bit V
   (virtual) refers to a channel for which there is no physical point-



Townsley, et al.             Standards Track                    [Page 9]


INTERNET DRAFT                    L2TP                     November 2001


   to-point link.

   Bits set in the Bearer Type AVP in an OCRQ message indicate the
   bearer type(s) on which an outgoing call may be placed.  If more than
   one bit is set, the LAC may choose the bearer type with which to
   place the call.  If no bits are set, any type of available channel
   may be used.

   Bits in the Value field of this AVP MUST only be set by the LNS for
   an OCRQ if the same bit was set in the Bearer Capabilities AVP
   received from the LAC during control connection establishment.

   Bits set in the Bearer Type AVP in an ICRQ message indicate the
   bearer type on which an incoming call was received at the LAC.  If no
   bits are set in an ICRQ, then it is assumed that the bearer type was
   indeterminable.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 10.

Framing Type (ICCN, OCCN, OCRQ)

   The Framing Type AVP, Attribute Type 19, encodes the framing type for
   the incoming or outgoing call.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |           Reserved for future Framing Types               |A|S|
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Framing Type is a 32-bit mask, which indicates the type of PPP
   framing requested for an OCRQ, or the type of PPP framing negotiated
   for an OCCN or ICCN.

   Bit A indicates asynchronous framing.  Bit S indicates synchronous
   framing.  For an OCRQ, both may be set, indicating that the LAC may
   decide the type of framing to be used.

   For an ICRQ, only one framing type bit may be set.  The framing type
   SHOULD be used as an indication to PPP on the LNS as to what link
   options to use for LCP negotiation [RFC1662].  For example, if the A
   bit is not set in the Framing Type AVP in an ICRQ message and an ACCM
   LCP option is requested by the PPP client, then the LNS should try to
   respond with no bits set in the ACCM mask, since the LAC will not
   likely perform async mapping on a non-async interface.  Similarly, if



Townsley, et al.             Standards Track                   [Page 10]


INTERNET DRAFT                    L2TP                     November 2001


   the S bit is set, PPP may wish to reject address field compression
   and protocol field compression options.

   Bits in the Value field of this AVP MUST only be set by the LNS for
   an OCRQ if it was set in the Framing Capabilities AVP received from
   the LAC during control connection establishment.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 10.

Called Number (ICRQ, OCRQ)

   The Called Number AVP, Attribute Type 21, encodes the telephone
   number to be called for an OCRQ, and the called number for an ICRQ.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Called Number... (arbitrary number of octets)                 |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Called Number is an ASCII string.  Contact between the
   administrator of the LAC and the LNS may be necessary to coordinate
   interpretation of the value needed in this AVP.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 6
   plus the length of the Called Number.

Calling Number (ICRQ)

   The Calling Number AVP, Attribute Type 22, encodes the originating
   number for the incoming call.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Calling Number... (arbitrary number of octets)                |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Calling Number is an ASCII string.  Contact between the
   administrator of the LAC and the LNS may be necessary to coordinate
   interpretation of the value in this AVP.




Townsley, et al.             Standards Track                   [Page 11]


INTERNET DRAFT                    L2TP                     November 2001


   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 6
   plus the length of the Calling Number.

Sub-Address (ICRQ, OCRQ)

   The Sub-Address AVP, Attribute Type 23, encodes additional dialing
   information.  For instance, it can be used by the LNS to encode the
   ISDN sub-address information for an outgoing call request.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Sub-Address ... (arbitrary number of octets)                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Sub-Address is an ASCII string.  Contact between the
   administrator of the LAC and the LNS may be necessary to coordinate
   interpretation of the value in this AVP.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 6
   plus the length of the Sub-Address.

Q.931 Cause Code (CDN)

   The Q.931 Cause Code AVP, Attribute Type 12, is used to give
   additional information in case of unsolicited call disconnection.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Cause Code           |   Cause Msg   | Advisory Msg...
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Cause Code field is the returned Q.931 cause code, and the Cause
   Msg field is the returned Q.931 message code (e.g., DISCONNECT)
   associated with the cause code.  Both values are returned in their
   native ITU encodings [DSS1].  An additional ASCII text Advisory
   Message may also be included (presence indicated by the AVP Length)
   to further explain the reason for disconnecting.

   This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
   this AVP MUST be set to 1.  The Length of this AVP is 9, plus the



Townsley, et al.             Standards Track                   [Page 12]


INTERNET DRAFT                    L2TP                     November 2001


   size of the Advisory Message.

Sequencing Required (ICCN, OCCN, ICRP, OCRQ)

   The Sequencing Required AVP, Attribute Type 39, indicates to the peer
   that Sequence Numbers MUST always be present on the data channel.

   This AVP has no Attribute Value field.

   This AVP MUST NOT be hidden (the H bit MUST be 0).  The M bit for
   this AVP MUST be set to 1.  The Length of this AVP is 6.

5.1.3 Proxy LCP and Authentication AVPs

   The LAC may have answered the call and negotiated LCP with the remote
   system, perhaps in order to establish the system's apparent identity.
   In this case, these AVPs may be included to indicate, first, the link
   properties the remote system initially requested, and second, the
   properties the remote system and LAC ultimately negotiated.  In
   addition, the authentication information can be sent by the LAC by
   including the proxy authentication AVPs.  This information may be
   used to initiate the PPP LCP and authentication states on the LNS,
   allowing PPP to continue without renegotiation of LCP.  Note that the
   LNS policy may be to enter an additional round of LCP negotiation
   and/or authentication if the LAC is not trusted.

Initial Received LCP CONFREQ (ICCN)

   In the Initial Received LCP CONFREQ AVP, Attribute Type 26, the LAC
   provides the LNS with the Initial CONFREQ received by the LAC from
   the PPP Peer.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LCP CONFREQ... (arbitrary number of octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LCP CONFREQ is a copy of the body of the initial CONFREQ
   received, starting at the first option within the body of the LCP
   message.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) of this AVP is 6
   plus the length of the CONFREQ.




Townsley, et al.             Standards Track                   [Page 13]


INTERNET DRAFT                    L2TP                     November 2001


Last Sent LCP CONFREQ (ICCN)

   In the Last Sent LCP CONFREQ AVP, Attribute Type 27, provides the LNS
   with the Last CONFREQ sent by the LAC to the PPP Peer.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LCP CONFREQ... (arbitrary number of octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LCP CONFREQ is a copy of the body of the final CONFREQ sent to
   the client to complete LCP negotiation, starting at the first option
   within the body of the LCP message.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) of this AVP is 6
   plus the length of the CONFREQ.

Last Received LCP CONFREQ (ICCN)

   The Last Received LCP CONFREQ AVP, Attribute Type 28, provides the
   LNS with the Last CONFREQ received by the LAC from the PPP Peer.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | LCP CONFREQ... (arbitrary number of octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The LCP CONFREQ is a copy of the body of the final CONFREQ received
   from the client to complete LCP negotiation, starting at the first
   option within the body of the LCP message.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) of this AVP is 6
   plus the length of the CONFREQ.

Proxy Authen Type (ICCN)

   The Proxy Authen Type AVP, Attribute Type 29, indicates the type of
   authentication that was performed for this call by the LAC, if any.

   The Attribute Value field for this AVP has the following format:



Townsley, et al.             Standards Track                   [Page 14]


INTERNET DRAFT                    L2TP                     November 2001


    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Authen Type          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Authen Type is a 2-octet unsigned integer.

   Defined Authen Type values are:
      0 - Reserved
      1 - Textual username/password exchange
      2 - PPP CHAP
      3 - PPP PAP
      4 - No authentication
      5 - Microsoft CHAP Version 1 (MSCHAPv1)
      TBA - Microsoft CHAP Version 2 (MSCHAPv2)
      TBA - PPP EAP
      TBA - Others

   This AVP MUST be present if proxy authentication is to be utilized.
   If it is not present, then it is assumed that this peer cannot
   perform proxy authentication.  In this case, a restart of the
   authentication phase at the LNS is required if the client has already
   entered this phase with the LAC (which may be determined by the
   presence of the Proxy LCP AVP).

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) of this AVP is 8.

   Associated AVPs for each type of authentication follow.

Proxy Authen Name (ICCN)

   The Proxy Authen Name AVP, Attribute Type 30, specifies the name of
   the authenticating client when using proxy authentication.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Authen Name... (arbitrary number of octets)                   |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Authen Name is a string of octets of arbitrary length.  It contains
   the name specified in the client's authentication response.

   This AVP MUST be present in messages containing a Proxy Authen Type



Townsley, et al.             Standards Track                   [Page 15]


INTERNET DRAFT                    L2TP                     November 2001


   AVP with an Authen Type of 1, 2, 3 or 5.  It may be desirable to
   employ AVP hiding for obscuring the cleartext name.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) is 6 plus the
   length of the cleartext name.

Proxy Authen Challenge (ICCN)

   The Proxy Authen Challenge AVP, Attribute Type 31, specifies the
   challenge sent by the LAC to the PPP Peer when using proxy
   authentication.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Challenge... (arbitrary number of octets)                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Challenge is a string of one or more octets.

   This AVP MUST be present for Proxy Authen Types 2 and 5.  The
   Challenge field contains the CHAP challenge presented to the client
   by the LAC.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) of this AVP is 6,
   plus the length of the Challenge.

Proxy Authen ID (ICCN)

   The Proxy Authen ID AVP, Attribute Type 32, specifies the ID value of
   the PPP Authentication that was started between the LAC and the PPP
   Peer when proxy authentication is being used.

   The Attribute Value field for this AVP has the following format:

    0                   1
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   Reserved    |      ID       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   ID is a 2-octet unsigned integer.  The most significant octet MUST be
   0.




Townsley, et al.             Standards Track                   [Page 16]


INTERNET DRAFT                    L2TP                     November 2001


   The Proxy Authen ID AVP MUST be present for Proxy Authen Types 2, 3
   and 5.  For 2 and 5, the ID field contains the byte ID value
   presented to the client by the LAC in its Challenge.  For 3, it is
   the Identifier value of the Authenticate-Request.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.

Proxy Authen Response (ICCN)

   The Proxy Authen Response AVP, Attribute Type 33, specifies the PPP
   Authentication response received by the LAC from the PPP Peer, when
   proxy authentication is used.

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   | Response... (arbitrary number of octets)                      |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Response is a string of octets.

   This AVP MUST be present for Proxy Authen Types 1, 2, 3 and 5.  The
   Response field contains the client's response to the challenge.  For
   Proxy Authen Types 2 and 5, this field contains the response value
   received by the LAC.  For 1 and 3, it contains the cleartext password
   received from the client by the LAC.  In the case of cleartext
   passwords, AVP hiding is recommended.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 0.  The Length (before hiding) of this AVP is 6
   plus the length of the Response.

5.1.4 Call Status AVPs

ACCM (SLI)

   The ACCM AVP, Attribute Type 35, is used by the LNS to inform LAC of
   the ACCM negotiated with the PPP Peer by the LNS.

   The Attribute Value field for this AVP has the following format:








Townsley, et al.             Standards Track                   [Page 17]


INTERNET DRAFT                    L2TP                     November 2001


    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Reserved             |    Send ACCM (H)              |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Send ACCM   (L)      |    Receive ACCM (H)           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |          Receive ACCM  (L)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Send ACCM and Receive ACCM fields are 4-octet values preceded by
   a 2-octet reserved quantity.  The Send ACCM value should be used by
   the LAC to process packets it sends on the connection.  The Receive
   ACCM value should be used by the LAC to process incoming packets on
   the connection.  The default values used by the LAC for both these
   fields are 0xFFFFFFFF.  The LAC should honor these fields unless it
   has specific configuration information to indicate that the requested
   mask must be modified to permit operation.

   This AVP may be hidden (the H bit MAY be 1 or 0).  The M bit for this
   AVP MUST be set to 1.  The Length of this AVP is 16.

5.2 Service Type Independent AVPs

   The base L2TP specification [L2TP] gives a detailed description of
   these AVPs.  However, the AVP values described in [L2TP] should be
   interpreted differently for different service type payloads carried
   by L2TP.  This section describes the AVP values in the context of PPP
   payload.  This section should be read in conjunction with the
   relevant sections from [L2TP].

Minimum BPS (OCRQ)

   The Minimum BPS AVP, Attribute Type 16, encodes the lowest acceptable
   line speed for this call over a dial-up network.  This is the lowest
   acceptable line speed in the transmit direction (i.e. the direction
   from the LAC to the user).

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Minimum BPS                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Minimum BPS is a 32-bit value indicating the speed in bits per
   second.



Townsley, et al.             Standards Track                   [Page 18]


INTERNET DRAFT                    L2TP                     November 2001


   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 10.

Maximum BPS (OCRQ)

   The Maximum BPS AVP, Attribute Type 17, encodes the highest
   acceptable line speed for this call in the transmit direction (i.e.
   from LAC to the user).

   The Attribute Value field for this AVP has the following format:

    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
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Maximum BPS                           |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Maximum BPS is a 32-bit value indicating the speed in bits per
   second.  This speed is the line speed (for example, modem connect
   speed) in the transmit direction.

   This AVP may be hidden (the H bit may be 0 or 1).  The M bit for this
   AVP MUST be set to 1.  The Length (before hiding) of this AVP is 10.

6. Data Channel Sequencing

   This section describes the method for using sequence numbers on the
   L2TP data plane carrying PPP frames.  It also provides guidelines on
   when to use these sequence numbers.

6.1 Sequence Numbers

   The Sequence Number field defined in the PPP sublayer header allows
   an LCCE to convey sequence information to a peer.  Unlike the L2TP
   control plane, the L2TP data plane carrying PPP frames does not use
   sequencing to retransmit lost data messages.  Rather, sequencing may
   be used to detect lost packets and/or restore the original sequence
   of packets that may have been reordered during traversal of the
   packet network.

   The sequence number begins at 0.  Each subsequent message is sent
   with the next increment of the sequence number.  The sequence number
   is thus a free-running counter represented modulo 2**16.  The
   sequence number in the header of a received message is considered
   less than or equal to the last received number if its value lies in
   the range of the last received number and the preceding (2**16 - 1)
   values, inclusive.  For example, if the last received sequence number
   was 15, then messages with sequence numbers 0 through 15, as well as



Townsley, et al.             Standards Track                   [Page 19]


INTERNET DRAFT                    L2TP                     November 2001


   32784 through 65535, would be considered less than or equal.

   Usage of this field is a matter of local policy for each LCCE.  An
   LCCE SHOULD update the Sequence Number field in the manner described
   above for outgoing packets. If an LCCE chooses to update the Sequence
   Number field for outgoing packets, it MUST set the Sequence bit in
   the PPP sublayer header to 1 (see Section 4.1).  In the other
   direction, an LCCE may choose to honor the sequence numbers received
   in incoming messages.  The precise mechanism for dealing with
   reordered or lost packets is also a matter of local policy.
   Alternatively, an LCCE may choose to ignore sequence numbers
   altogether.

   One LCCE may convey to its peer that the Sequence Number field will
   be honored for incoming data messages by sending the Sequencing
   Required AVP.  If this AVP is sent during session establishment, it
   is recommended that the peer update the Sequence Number field in the
   manner described above.

6.2 Data Channel Sequencing over Specific Media

   When PPP frames are carried over an L2TP-over-IP or L2TP-over-UDP/IP
   data channel to the PPP client, this link has the characteristic of
   being able to reorder or silently drop packets.  Reordering may break
   non-IP protocols being carried by PPP, especially LAN-centric ones
   such as bridging.  Silent dropping of packets may break protocols
   that assume per-packet indication of error, such as TCP header
   compression.

   If any protocol being transported by PPP over these L2TP data
   channels cannot tolerate reordering, sequencing may be turned on by
   using the sequence number field in the PPP sublayer header.  The
   sequence dependency characteristics of individual protocols are
   outside the scope of this document.

   Allowing packets to be dropped silently is perhaps more problematic
   with some protocols.  If PPP reliable delivery [RFC1663] is enabled,
   no upper PPP protocol will encounter lost packets.  If sequence
   numbers are enabled, L2TP can detect the packet loss.  In the case of
   an LNS, the PPP and L2TP stacks are both present within the LNS, and
   packet loss signaling may occur precisely as if a packet was received
   with a CRC error.  Where the LAC and PPP stack are co-resident, this
   technique also applies.  Where the LAC and PPP client are physically
   distinct, the analogous signaling MAY be accomplished by sending a
   packet with a CRC error to the PPP client.  Note that this would
   greatly increase the complexity of debugging client line problems,
   since the client statistics could not distinguish between true media
   errors and LAC-initiated ones.  Further, this technique is not



Townsley, et al.             Standards Track                   [Page 20]


INTERNET DRAFT                    L2TP                     November 2001


   possible on all hardware.

   If VJ compression is used, and neither PPP reliable delivery nor
   sequence numbers are enabled, each lost packet results in a 1 in
   2**16 chance of a TCP segment being forwarded with incorrect contents
   [RFC1144].  Where the combination of the packet loss rate with this
   statistical exposure is unacceptable, TCP header compression SHOULD
   NOT be used.

   In general, it is wise to remember that the L2TP-over-IP as well as
   the L2TP-over-UDP/IP transports are unreliable transport media.  As
   with any PPP medium that is subject to loss, care should be taken
   when using protocols that are particularly loss-sensitive.  Such
   protocols include compression and encryption protocols that employ
   history.

7. IANA Considerations

   This document defines "magic" numbers to be maintained by the IANA.
   This section explains the criteria to be used by the IANA to assign
   additional numbers in each of these lists.  The following subsections
   describe the assignment policy for the namespaces defined elsewhere
   in this document.

7.1 AVP Attributes

   As defined in [L2TP], AVPs contain Vendor ID, Attribute, and Value
   fields.  For a Vendor ID value of 0, IANA will maintain a registry of
   assigned Attributes for PPP-specific AVPs described in Section 3.1,
   and in some cases, values for those attributes.

7.2 SLI Message Type

   Section 3 of this document defines the value 16 for the SLI message
   type.  This value will be maintained by the IANA.

7.3 Framing Capabilities and Bearer Capabilities

   The Framing Capabilities AVP and Bearer Capabilities AVP (defined in
   Section 5.1) both contain 32-bit bitmasks.  Additional bits should
   only be defined via a Standards Action [RFC 2434].

7.4 Framing Type and Bearer Type

   The Framing Type AVP and Bearer Type AVP (defined in Section 5.1)
   both contain 32-bit bitmasks.  Additional bits should only be defined
   via a Standards Action [RFC 2434].




Townsley, et al.             Standards Track                   [Page 21]


INTERNET DRAFT                    L2TP                     November 2001


7.5 Proxy Authen Type AVP Values

   The Proxy Authen Type AVP (Attribute Type 29) has an associated value
   maintained by IANA.  Values 0-5 are defined in Section 5.1, the
   remaining values are available for assignment upon Expert Review [RFC
   2434].

7.6 PPP Sublayer Header Bits

   There are three remaining reserved bits in the PPP Sublayer header.
   Additional bits should only be assigned via a Standards Action [RFC
   2434].

8. References

   [L2TP]    J. Lau, M. Townsley, A. Valencia, G. Zorn, I. Goyret, G. Singh
             Pall, A. Rubens, B. Palter, "Layer Two Tunneling Protocol (L2TP)",
             <draft-ietf-l2tpext-l2tp-base-00.txt>, July 2001

   [RFC2661] W.M. Townsley, A. Valencia, A. Rubens, G. Singh Pall,
             G. Zorn, B. Palter, "Layer Two Tunneling Protocol (L2TP)",
             RFC 2661, August 1999

   [DSS1]    ITU-T Recommendation, "Digital subscriber Signaling System
             No. 1 (DSS 1) - ISDN user-network interface layer 3
             specification for basic call control", Rec. Q.931(I.451),
             May 1998

   [KPS]     Kaufman, C., Perlman, R., and Speciner, M., "Network
             Security:  Private Communications in a Public World",
             Prentice Hall, March 1995, ISBN 0-13-061466-1

   [RFC791]  Postel, J., "Internet Protocol", STD 5, RFC 791, September
             1981.

   [RFC1034] Mockapetris, P., "Domain Names - Concepts and Facilities",
             STD 13, RFC 1034, November 1987.

   [RFC1144] Jacobson, V., "Compressing TCP/IP Headers for Low-Speed
             Serial Links", RFC 1144, February 1990.

   [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
             RFC 1661, July 1994.

   [RFC1662] Simpson, W., "PPP in HDLC-like Framing", STD 51, RFC 1662,
             July 1994.

   [RFC1663] Rand, D., "PPP Reliable Transmission", RFC 1663, July 1994.



Townsley, et al.             Standards Track                   [Page 22]


INTERNET DRAFT                    L2TP                     November 2001


   [RFC1700] Reynolds, J. and J. Postel, "Assigned Numbers", STD 2, RFC
             1700, October 1994.  See also:
             http://www.iana.org/numbers.html

   [RFC1990] Sklower, K., Lloyd, B., McGregor, G., Carr, D. and T.
             Coradetti, "The PPP Multilink Protocol (MP)", RFC 1990,
             August 1996.

   [RFC1994] Simpson, W., "PPP Challenge Handshake Authentication
             Protocol (CHAP)", RFC 1994, August 1996.

   [RFC1918] Rekhter, Y., Moskowitz, B., Karrenberg, D., de Groot, G.
             and E. Lear, "Address Allocation for Private Internets",
             BCP 5, RFC 1918, February 1996.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

   [RFC2138] Rigney, C., Rubens, A., Simpson, W. and S. Willens, "Remote
             Authentication Dial In User Service (RADIUS)", RFC 2138,
             April 1997.

   [RFC2277] Alvestrand, H., "IETF Policy on Character Sets and
             Languages", BCP 18, RFC 2277, January 1998.

   [RFC2341] Valencia, A., Littlewood, M. and T. Kolar, "Cisco Layer Two
             Forwarding (Protocol) L2F", RFC 2341, May 1998.

   [RFC2401] Kent, S. and R. Atkinson, "Security Architecture for the
             Internet Protocol", RFC 2401, November 1998.

   [RFC2434] Narten, T. and H. Alvestrand, "Guidelines for Writing an
             IANA Considerations section in RFCs", BCP 26, RFC 2434,
             October 1998.

   [RFC2637] Hamzeh, K., Pall, G., Verthein, W., Taarud, J., Little, W.
             and G. Zorn, "Point-to-Point Tunneling Protocol (PPTP)",
             RFC 2637, July 1999.

   [STEVENS] Stevens, W. Richard, "TCP/IP Illustrated, Volume I The
             Protocols", Addison-Wesley Publishing Company, Inc., March
             1996, ISBN 0-201-63346-9

9. Acknowledgments

   The basic concept for L2TP and many of its protocol constructs were
   adopted from L2F [RFC2341] and PPTP [RFC2637].  Authors of these are
   A. Valencia, M. Littlewood, T. Kolar, K. Hamzeh, G. Pall, W.



Townsley, et al.             Standards Track                   [Page 23]


INTERNET DRAFT                    L2TP                     November 2001


   Verthein, J. Taarud, W. Little, and G. Zorn.

   The L2TP rewrite team for splitting RFC2661 into the base and
   companion PPP specifications consisted of Ignacio Goyret, Jed Lau,
   Bill Palter, Mark Townsley, and Madhvi Verma.

   This document was based upon RFC2661, for which a number of people
   provided valuable input and effort.

   John Bray, Greg Burns, Rich Garrett, Don Grosser, Matt Holdrege,
   Terry Johnson, Dory Leifer, and Rich Shea provided valuable input and
   review at the 43rd IETF in Orlando, FL., which led to improvement of
   the overall readability and clarity of RFC2661.

   Thomas Narten provided a great deal of critical review, formatting,
   and wrote the IANA Considerations section.

   Dory Leifer made valuable refinements to the protocol definition of
   L2TP and contributed to the editing of early drafts leading to
   RFC2661.

   Steve Cobb and Evan Caves redesigned the state machine tables.

   Barney Wolff provided a great deal of design input on the endpoint
   authentication mechanism.

10. Authors' Addresses

   Ignacio Goyret
   Lucent Technologies
   1701 Harbor Bay Parkway
   Alameda, CA 94502

   Email: igoyret@lucent.com

   Jed Lau
   cisco Systems
   170 W. Tasman Drive
   San Jose, CA  95134

   Email: jedlau@cisco.com

   Gurdeep Singh Pall
   Microsoft Corporation
   Redmond, WA

   Email: gurdeep@microsoft.com




Townsley, et al.             Standards Track                   [Page 24]


INTERNET DRAFT                    L2TP                     November 2001


   Bill Palter
   RedBack Networks, Inc
   1389 Moffett Park Drive
   Sunnyvale, CA 94089

   Email: palter@zev.net

   Allan Rubens

   Email: acr@del.com

   W. Mark Townsley
   cisco Systems
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC 27709

   Email: mark@townsley.net

   Andrew J. Valencia
   P.O. Box 2928
   Vashon, WA 98070

   Email: vandys@zendo.com

   Madhvi Verma
   CommWorks, a 3Com company
   3800 Golf Road
   Rolling Meadows, IL 60008

   Email: madhvi_verma@3com.com

   Glen Zorn
   cisco Systems
   500 108th Avenue N.E., Suite 500
   Bellevue, WA 98004

   Email: gwz@cisco.com













Townsley, et al.             Standards Track                   [Page 25]