[Docs] [txt|pdf] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06 07 08

L2TPEXT Working Group                                  C. Pignataro, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Expires: April 9, 2006                                   October 6, 2005


  PPP Tunneling Using Layer Two Tunneling Protocol Version 3 (L2TPv3)
                   draft-ietf-l2tpext-l2tp-ppp-02.txt

Status of this Memo

   By submitting this Internet-Draft, each author represents that any
   applicable patent or other IPR claims of which he or she is aware
   have been or will be disclosed, and any of which he or she becomes
   aware will be disclosed, in accordance with Section 6 of BCP 79.

   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."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 9, 2006.

Copyright Notice

   Copyright (C) The Internet Society (2005).

Abstract

   This document describes the use of "version 3" of Layer Two Tunneling
   Protocol (L2TPv3) to tunnel Point-to-Point (PPP) packets.  This
   document defines the control protocol and encapsulation specifics for
   tunneling PPP over L2TPv3, and is a companion document to the L2TPv3
   base specification.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",



Pignataro                 Expires April 9, 2006                 [Page 1]


Internet-Draft               PPP over L2TPv3                October 2005


   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in [RFC2119].


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5

   2.  Topology . . . . . . . . . . . . . . . . . . . . . . . . . . .  6

   3.  Control Channel Specifics for PPP  . . . . . . . . . . . . . .  6
     3.1.  Control Connection Establishment . . . . . . . . . . . . .  6
     3.2.  Session Establishment  . . . . . . . . . . . . . . . . . .  7
     3.3.  Session Maintenance  . . . . . . . . . . . . . . . . . . .  8

   4.  Data Channel Specifics for PPP . . . . . . . . . . . . . . . .  9
     4.1.  L2-Specific Sublayer . . . . . . . . . . . . . . . . . . . 10
     4.2.  Offset Padding . . . . . . . . . . . . . . . . . . . . . . 10
     4.3.  Forwarding PPP Frames  . . . . . . . . . . . . . . . . . . 10

   5.  AVP Description  . . . . . . . . . . . . . . . . . . . . . . . 11
     5.1.  PPP-Specific AVPs  . . . . . . . . . . . . . . . . . . . . 12
       5.1.1.  Control Connection Management AVPs . . . . . . . . . . 12
       5.1.2.  Session Management AVPs  . . . . . . . . . . . . . . . 13
       5.1.3.  Proxy LCP and Authentication AVPs  . . . . . . . . . . 23
       5.1.4.  Session Status AVPs  . . . . . . . . . . . . . . . . . 28
     5.2.  Service Type Independent AVPs  . . . . . . . . . . . . . . 28

   6.  Data Channel Sequencing  . . . . . . . . . . . . . . . . . . . 30
     6.1.  Sequence Numbers . . . . . . . . . . . . . . . . . . . . . 31
     6.2.  Data Channel Sequencing over Specific Media  . . . . . . . 31

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 32

   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 33
     8.1.  AVP Attributes . . . . . . . . . . . . . . . . . . . . . . 33
     8.2.  Pseudowire Type  . . . . . . . . . . . . . . . . . . . . . 34
     8.3.  Result Code AVP Values . . . . . . . . . . . . . . . . . . 34
     8.4.  Bearer Capabilities and Bearer Type  . . . . . . . . . . . 34
     8.5.  Framing Capabilities and Framing Type  . . . . . . . . . . 35
     8.6.  Proxy Authen Type AVP Values . . . . . . . . . . . . . . . 35

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 35
     9.1.  Proxy PPP Authentication . . . . . . . . . . . . . . . . . 35

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 36
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 36



Pignataro                 Expires April 9, 2006                 [Page 2]


Internet-Draft               PPP over L2TPv3                October 2005


     10.2. Informative References . . . . . . . . . . . . . . . . . . 36

   Appendix A.  Revision History  . . . . . . . . . . . . . . . . . . 37

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 40
   Intellectual Property and Copyright Statements . . . . . . . . . . 41













































Pignataro                 Expires April 9, 2006                 [Page 3]


Internet-Draft               PPP over L2TPv3                October 2005


Contributing Authors

   This document is a result of the combined effort of several
   individuals.  The following are the authors that contributed to this
   document:

   Ignacio Goyret
   Jed Lau
   Gurdeep Singh Pall
   Bill Palter
   Allan Rubens
   W. Mark Townsley
   Andrew J. Valencia
   Madhvi Verma
   Glen Zorn
   Carlos Pignataro


1.  Introduction

   The Point-to-Point Protocol (PPP) [RFC1661] 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, ISDN, ADSL, ATM SVC (Switched Virtual Circuits) or PVC
   (Permanent Virtual Circuits) based access [RFC3301], etc.

   Typically, a user obtains a Layer 2 (L2) connection to a Network
   Access Server (NAS) using one of a number of access techniques (e.g.
   dial-up POTS, ISDN, ADSL, ATM access, 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 -
   Version 3 (L2TPv3) defined in [RFC3931], provide a dynamic mechanism
   for extending PPP by allowing the L2 and PPP endpoints to reside on
   different devices that are interconnected by a packet switched
   network (PSN), for example over IP.  This separation allows the
   actual processing of PPP packets to be divorced from the termination
   of the L2 circuit.

   L2TPv3 can also be used as the control protocol and for data
   encapsulation in the creation of Pseudowires to transport PPP frames
   over an IP or other packet-based network.  A PPP Pseudowire emulates
   a single PPP link between exactly two endpoints.

   This document defines the specific mechanisms for tunneling of PPP



Pignataro                 Expires April 9, 2006                 [Page 4]


Internet-Draft               PPP over L2TPv3                October 2005


   using L2TPv3.

   This is a companion document to be read in conjunction with
   [RFC3931].  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.  Terminology

   This document uses terminology defined in Section 1.3 of [RFC3931].
   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
      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.

   ISDN

      Integrated Services Digital Network

   Network Access Server (NAS)

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

   POTS





Pignataro                 Expires April 9, 2006                 [Page 5]


Internet-Draft               PPP over L2TPv3                October 2005


      Plain Old Telephone Service.

   PW

      Pseudowire.  See [RFC3985].  There is one Pseudowire per L2TP
      Session.

   PPPPW

      PPP Pseudowire.


2.  Topology

   PPP tunneling can be deployed in all of the different tunneling
   models specified in Section 2 of [RFC3931].  Traditionally, it is
   most commonly deployed for access applications in the LAC-LNS
   reference model.  The LAC physically terminates the L2 connection and
   tunnels the PPP packets across a packet-based network (i.e., IP
   network) to the LNS.  The LNS then terminates the logical PPP
   connection.  The L2 service extends between Remote System and LNS,
   and the emulated service extends between LAC and LNS (see Section 2
   of [RFC3931]).  The session establishment can be driven by the LAC
   (an incoming call) or the LNS (an outgoing call).

   In the LNS-LNS reference model, both the emulated service and L2
   service extend between the two LNS devices.  A software package on a
   host which runs L2TP natively and acts as an LNS is often referred to
   as a "LAC Client" [RFC2661].

   More recently, in the symmetric LAC-LAC reference model, the emulated
   service extends between LACs while the L2 service extends between
   remote systems.  In the most basic form, the LAC acts as a cross-
   connect between a PPP interface to a remote system and an L2TP
   session, and forwards PPP traffic from the remote system to the peer
   LAC using L2TP and viceversa.


3.  Control Channel Specifics for PPP

   The following sections highlight Control Connection and Session
   management details in the context of PPP over L2TPv3.  This includes
   AVPs that need special attention for the PPP PW Type or that differ
   from [RFC2661].

3.1.  Control Connection Establishment

   In order to tunnel PPP over L2TPv3, an L2TPv3 Control Connection MUST



Pignataro                 Expires April 9, 2006                 [Page 6]


Internet-Draft               PPP over L2TPv3                October 2005


   first be established as described in Section 3.3 of [RFC3931].

   The L2TPv3 SCCRQ Control Message and corresponding SCCRP Control
   Message MUST include the "PPP Pseudowire Type" of 0x0007 (See IANA
   Considerations Section), in the Pseudowire Capabilities List AVP,
   Attribute Type 62, as defined in Section 5.4.3 of [RFC3931].  This
   identifies the control connection as being able to establish PPP
   L2TPv3 sessions.

   During Control Connection Establishment, LCCEs are identified either
   by the Host Name AVP, Attribute Type 7, the Router ID AVP, Attribute
   Type 60, or a combination of the two.  See Section 3.3 of [RFC3931]
   that describes LCCE identity.

   The Assigned Control Connection ID defined in Section 5.4.3 of
   [RFC3931], Attribute Type 61, is the L2TPv3 analogous to the Assigned
   Tunnel ID in L2TPv2.  The Control Connection Tie Breaker AVP defined
   in Section 5.4.3 of [RFC3931], Attribute Type 5, is used to choose a
   single control connection when two LCCEs request a control connection
   simultaneously.

3.2.  Session Establishment

   The following signaling elements are needed for session
   establishment:

   The Pseudowire Type AVP defined in Section 5.4.4 of [RFC3931],
   Attribute Type 68, MUST be present in the ICRQ and OCRQ messages and
   MUST include the PPP PW Type of 0x0007.

   The Remote End ID AVP, Attribute Type 66, binds the L2TP session to a
   given PPP circuit, and MUST be present in ICRQ messages in the LAC-
   LAC cross-connect application (see Section 2(b) of [RFC3931]).  In
   this case, an implementation MUST support a Remote End ID of an
   unstructured four-octet value that is known to both LCCEs (either by
   manual configuration of some other means outside of the scope of this
   document).

   The Circuit Status AVP, Attribute Type 71, MUST be included in ICRQ,
   ICRP, OCRQ and OCRP messages.  The N (New) bit of the Circuit Status
   AVP MUST be set to 1 in these messages indicating a new circuit, and
   the A (Active) bit is set to 0 (INACTIVE) or 1 (ACTIVE) reflecting
   the operational circuit status underneath PPP.  This AVP is further
   described in the context of PPP over L2TPv3 in Section 5.2.

   The Local Session ID AVP, Attribute Type 63, is analogous to the
   Assigned Session ID in L2TPv2.  The Remote Session ID AVP, Attribute
   Type 64, echoes the value of the Local Session ID AVP received, and



Pignataro                 Expires April 9, 2006                 [Page 7]


Internet-Draft               PPP over L2TPv3                October 2005


   MUST be present in all session-level control messages.  Additionally,
   when using the Remote End ID AVP, the Session Tie Breaker AVP,
   Attribute Type 5, is used to break session-level ties (detected by
   comparing both the peer's identity as described in Section 3.1 and
   the value of the Remote End ID AVP).

3.3.  Session Maintenance

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

   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 in case
   of PPP LCP renegotiations, or after the ICCN message with PPP Last
   CONFREQ AVPs is received when proxy LCP is accepted.  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
   last SLI sent was already set to default values or no SLI was sent at
   all, this step MAY be omitted.

   The SLI MAY be sent from the LAC to indicate a change in the circuit
   status underneath PPP.

   The following AVPs MUST be present in the SLI:

   Message Type

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

   ACCM

      This AVP is described in Section 5.1.4.

   The following AVP MAY be present in the SLI:




Pignataro                 Expires April 9, 2006                 [Page 8]


Internet-Draft               PPP over L2TPv3                October 2005


   Circuit Status

      In SLI messages, the N (New) bit MUST be set to 0 indicating that
      the status is for an existing circuit.  This AVP is described in
      Section 5.2.


4.  Data Channel Specifics for PPP

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

   The general format for tunneling PPP frames over L2TPv3 is 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                       Session Header                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |            Default L2-Specific Sublayer (Optional)            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |Offset Pad (Variable, Optional)|                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
      |                                                               |
      ~                          PPP Frames                           ~
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Figure 1: PPP over L2TPv3 encapsulation

   The header format for the PPP over L2TPv3 data messages consists of a
   Session Header header followed by the optional Default L2-specific
   sublayer, an optional variable-length Offset Padding and then the
   Tunnel Payload (PPP Frames).

   This document decouples the L2-Specific Sublayer intermediary
   function (see Section 4.1) from the Offset padding function (see
   Section 4.2), making them independent from each other.  Because those
   two fields perform orthogonal functions, separating them enables
   their independent request and existance (i.e., only the Offset
   Padding field can be requested and present when no functions of the
   L2-Specific Sublayer such as sequencing are needed).  It also
   simplifies moving the control of the Offset Size downstream to the
   LCCE receiver of the data packet (see Section 4.2) and Offset Size
   AVP in Section 5.1.2.





Pignataro                 Expires April 9, 2006                 [Page 9]


Internet-Draft               PPP over L2TPv3                October 2005


4.1.  L2-Specific Sublayer

   This section defines the usage and specifics of an L2-Specific
   Sublayer for PPP over L2TPv3.  When an intermediary L2-Specific
   Sublayer is needed or desired to support features such as sequencing,
   PPP over L2TPv3 uses the Default L2-Specific Sublayer defined in
   Section 4.6 of [RFC3931].

   The usage of the Default L2-Specific Sublayer is OPTIONAL.  However
   if an L2-Specific Sublayer is requested, it MUST be the Default one.
   Its presence is requested by a peer during session negotiation using
   the L2-Specific Sublayer Type AVP, Attribute Type 69, with a value of
   1.  If the AVP is not received, it is assumed that there is no
   sublayer present.

4.2.  Offset Padding

   The optional Offset Padding Field MAY be included containing offset
   padding before the tunneled PPP frame.  This field can be used to
   provide alignment of the data carried in PPP to longword size
   boundaries for performance reasons, but increases the size of the
   L2TPv3 packet.  The Offset field follows the Default L2-Specific
   Sublayer if present or the L2TPv3 Session Header otherwise.

   The number of octets past the L2TPv3 Session Header or optional L2-
   Specific Sublayer if present at which the payload data is expected to
   start (i.e., the size of the Offset Padding field) is signaled during
   session establishment using the Offset Size AVP (see Section 5.1.2).
   When an LCCE agrees to support a requested Offset Size during session
   establishment, it MUST send all data packets including an Offset
   Padding of that agreed size.  The size of the Offset Padding field
   MAY be different in both directions of the session.  An Offset Size
   of zero signaled during session establishment indicates no offset.
   The maximum offset value that may be specified is 15 octets.

   Actual data within the Offset Padding field is undefined, and MUST be
   ignored on receipt.

4.3.  Forwarding PPP Frames

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

   After L2TP control channel establishment (see [RFC3931], Section 3.1
   and Section 3.2 for details on control connection and session
   establishment), PPP frames are tunneled.



Pignataro                 Expires April 9, 2006                [Page 10]


Internet-Draft               PPP over L2TPv3                October 2005


   The PPP frames from the remote system are received at the LAC,
   stripped of CRC, link framing, and transparency bytes, encapsulated
   with the L2TPv3 data header (see [RFC3931]) followed by the optional
   Default L2-Specific Sublayer (see Section 4.1) and Offset Padding
   (see Section 4.2) fields, and forwarded over the session.  When using
   PPP in HDLC framing (See [RFC1662]) the PPP frame is stripped of HDLC
   header (HDLC address and control fields), flags and trailing FCS.
   The remaining data, including the protocol field, is transported over
   the session.  The LNS receives the L2TPv3 packet and processes the
   encapsulated PPP frame as if it were received on a local PPP
   interface.  The LNS receives the PPP frame over the L2TP session
   without the HDLC Address and Control fields.  All framing operations
   (e.g., CRC, character escaping, etc.) are handled by the LAC.

   When encapsulating the PPP frame in L2TPv3, both the LAC and the LNS
   MUST always include the PPP Protocol ID field along with the PPP
   frame.  They MUST not include the HDLC header (Address and Control
   fields).  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.  While the sender MUST omit and not
   send the HDLC Address and Control fields, a robust implementation
   SHOULD allow the HDLC Address and Control fields to be present in a
   received packet (strict sender, lenient receiver).

   It is worth noting however that if an implementation wishes to
   receive the space equivalent to the HDLC Address and Control fields
   in the tunneled PPP frame, it MAY request a two-octet offset padding
   with the Offset Size AVP.


5.  AVP Description

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

   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
   L2TPv3 specification [RFC3931].  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.






Pignataro                 Expires April 9, 2006                [Page 11]


Internet-Draft               PPP over L2TPv3                October 2005


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.

      It is RECOMMENDED that an implementation includes all the Framing
      Capabilities that its software module supports rather than
      conveying its physical interface capabilities at the time of
      Control Connection establishment.  This way, a shut down and re-
      establishment of the Control Connection is prevented if new
      physical interface capabilities are added to the LCCE.  This step
      pushes the capability check to the Session establishment phase.
      The same recommendation applies to the Bearer Capabilities.

      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)




Pignataro                 Expires April 9, 2006                [Page 12]


Internet-Draft               PPP over L2TPv3                October 2005


      The Bearer Capabilities AVP, Attribute Type 4, provides the peer
      with an indication of the bearer device types supported by the
      hardware 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|B|A|D|
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      This is a 32-bit mask, with four bits defined.  If bit A is set,
      analog access is supported.  If bit D is set, digital access is
      supported.  If bit B is set, broadband access is supported (ATM).
      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.  Session Management AVPs

   This section describes Session (i.e., Call) Management AVPs.

   Bearer Type (ICRQ, OCRQ)

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









Pignataro                 Expires April 9, 2006                [Page 13]


Internet-Draft               PPP over L2TPv3                October 2005


      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|B|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 B refers to broadband access.  Bit V (virtual)
      refers to a channel for which there is no physical point-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.













Pignataro                 Expires April 9, 2006                [Page 14]


Internet-Draft               PPP over L2TPv3                October 2005


      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 ICCN, 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 ICCN 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 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.












Pignataro                 Expires April 9, 2006                [Page 15]


Internet-Draft               PPP over L2TPv3                October 2005


      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.
      Additionally, other Called Number encodings MAY be defined to be
      interpreted in the context of the Bearer Type in use for the
      specific call.  An example of alternate encoding is defined in
      [RFC3301].

      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.  Additionally,
      other Called Number encodings MAY be defined to be interpreted in
      the context of the Bearer Type in use for the specific call.  An
      example of alternate encoding is defined in [RFC3301].

      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)




Pignataro                 Expires April 9, 2006                [Page 16]


Internet-Draft               PPP over L2TPv3                October 2005


      The Sub-Address AVP, Attribute Type 23, encodes additional called
      party 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.  Additionally,
      other Called Number encodings MAY be defined to be interpreted in
      the context of the Bearer Type in use for the specific call.  An
      example of alternate encoding is defined in [RFC3301].

      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.

   Calling Sub-Address (ICRQ)

      The Calling Sub-Address AVP, Attribute Type 44, encodes additional
      calling party information.  For instance, it can be used by the
      LAC to encode the ISDN sub-address information for an incoming
      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Calling Sub-Address ... (arbitrary number of octets)          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Calling 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.  Additionally,
      other Called Number encodings MAY be defined to be interpreted in
      the context of the Bearer Type in use for the specific call.  An



Pignataro                 Expires April 9, 2006                [Page 17]


Internet-Draft               PPP over L2TPv3                October 2005


      example of alternate encoding is defined in [RFC3301].

      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 [ITU.Q931.1998].
      Additionally, the Cause Code field can carry Cause Codes specific
      to ATM signalling messages as described in [RFC3301].  The Cause
      code should be interpreted relative to the Bearer Type in use for
      the specific call.  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
      size of the Advisory Message.

   Private Group ID (ICCN)

      The Private Group ID AVP, Attribute Type 37, is used by the LAC to
      indicate that this call is to be associated with a particular
      customer group.










Pignataro                 Expires April 9, 2006                [Page 18]


Internet-Draft               PPP over L2TPv3                October 2005


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

      The Private Group ID is a string of octets of arbitrary length.

      The LNS MAY treat the PPP session as well as network traffic
      through this session in a special manner determined by the peer.
      For example, if the LNS is individually connected to several
      private networks using unregistered addresses, this AVP may be
      included by the LAC to indicate that a given call should be
      associated with one of the private networks.

      The Private Group ID is a string corresponding to a table in the
      LNS that defines the particular characteristics of the selected
      group.  A LAC MAY determine the Private Group ID from a RADIUS
      response, local configuration, or some other source.

      This AVP may be hidden (the H-bit MAY be 1 or 0).  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 Private Group ID.

   Offset Size (ICRQ, ICRP, ORCQ, OCRP)

      The Offset Size AVP, Attribute Type AVP-TBD-1, indicates the size
      in octets of the Offset Padding field the sender of this AVP
      requires on all incoming data packets for this L2TP session.  It
      allows an LCCE to request the peer includes an Offset Padding in
      all data messages (see Section 4.2).



      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Offset Size          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Offset Size is a 2-octet unsigned integer.  The maximum value
      for the Offset Size is 15 octets.  If absent, the peer MUST assume
      a value of zero.




Pignataro                 Expires April 9, 2006                [Page 19]


Internet-Draft               PPP over L2TPv3                October 2005


      A missing Offset Size AVP or an Offset Size AVP with a value of
      zero indicates that the Offset Padding field should not be present
      in any data packets sent to the LCCE sending this AVP.  If this
      AVP is received and has a value other than zero (and less than or
      equal to 15), the receiving LCCE MUST include an Offset Padding of
      the requested size in its outgoing data messages.

      If the LCCE receiving this AVP is not capable, configured or
      willing to include an Offset Padding field of the requested size,
      or if the requested size is greater than 15 octets, the LCCE MUST
      reject the session via a CDN mesage with the following General
      Result Code:



         RC-TBD1: Session not established due to unsupported Offset Size

      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 8.

   Tx Minimum Speed (OCRQ)

      The Tx Minimum Speed AVP, Attribute Type AVP-TBD-2, encodes the
      lowest acceptable line speed for this call over a dial-up or ATM
      access 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Tx Minimum Speed in bps...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    ...Tx Minimum Speed in bps (64 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tx Minimum Speed BPS is an 8-octet value indicating the speed
      in bits per second.  This speed is the minimum line speed (for
      example, modem connect speed) in the transmit direction.

      The Minimum BPS AVP, Attribute Type 16, MUST NOT be used in PPP
      over L2TPv3.





Pignataro                 Expires April 9, 2006                [Page 20]


Internet-Draft               PPP over L2TPv3                October 2005


      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 14.

   Tx Maximum Speed (OCRQ)

      The Tx Maximum Speed AVP, Attribute Type AVP-TBD-3, 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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Tx Maximum Speed in bps...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    ...Tx Maximum Speed in bps (64 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Tx Maximum Speed BPS is an 8-octet value indicating the speed
      in bits per second.  This speed is the maximum line speed (for
      example, modem connect speed) in the transmit direction.

      The Maximum BPS AVP, Attribute Type 17, MUST NOT be used in PPP
      over L2TPv3.

      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 14.

   Rx Minimum Speed (OCRQ)

      The Rx Minimum Speed AVP, Attribute Type AVP-TBD-4, encodes the
      lowest acceptable line speed for this call in the receive
      direction (i.e., data flowing from the remote system to the LAC),
      for cases where asymmetric transmission may be required.












Pignataro                 Expires April 9, 2006                [Page 21]


Internet-Draft               PPP over L2TPv3                October 2005


      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Rx Minimum Speed in bps...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    ...Rx Minimum Speed in bps (64 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Rx Minimum Speed BPS is an 8-octet value indicating the speed
      in bits per second.  This speed is the minimum line speed (for
      example, modem connect speed) in the receive direction.  Presence
      of this AVP implies that the connection speed may be asymmetric
      with respect to the Tx Minimum Speed BPS.

      The Rx Minimum BPS AVP, Attribute Type 40, MUST NOT be used in PPP
      over L2TPv3.

      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 14.

   Rx Maximum Speed (OCRQ)

      The Rx Maximum Speed AVP, Attribute Type AVP-TBD-5, encodes the
      highest acceptable line speed for this call in the receive
      direction (i.e., data flowing from the remote system to the LAC),
      for cases where asymmetric transmission may be required.



      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                  Rx Maximum Speed in bps...
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
                    ...Rx Maximum Speed in bps (64 bits)              |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The Rx Maximum Speed BPS is an 8-octet value indicating the speed
      in bits per second.  This speed is the maximum line speed (for
      example, modem connect speed) in the receive direction.  Presence
      of this AVP implies that the connection speed may be asymmetric
      with respect to the Tx Maximum Speed BPS.




Pignataro                 Expires April 9, 2006                [Page 22]


Internet-Draft               PPP over L2TPv3                October 2005


      The Rx Maximum BPS AVP, Attribute Type 41, MUST NOT be used in PPP
      over L2TPv3.

      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 14.

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.

   Last Sent LCP CONFREQ (ICCN)





Pignataro                 Expires April 9, 2006                [Page 23]


Internet-Draft               PPP over L2TPv3                October 2005


      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



Pignataro                 Expires April 9, 2006                [Page 24]


Internet-Draft               PPP over L2TPv3                October 2005


      any.



      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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |          Authen Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      Authen Type is a 2-octet unsigned integer.

      Defined Authen Type values are maintained by IANA.  Currently
      defined values, which are referenced in upcoming AVP definitions,
      are:

         0 - Reserved

         1 - Textual username/password exchange

         2 - PPP CHAP

         3 - PPP PAP

         4 - No authentication

         5 - Microsoft CHAP Version 1 (MSCHAPv1)

      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.




Pignataro                 Expires April 9, 2006                [Page 25]


Internet-Draft               PPP over L2TPv3                October 2005




      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 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.




Pignataro                 Expires April 9, 2006                [Page 26]


Internet-Draft               PPP over L2TPv3                October 2005


   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.

      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.  The Length (before hiding) of this AVP
      is 8.

   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



Pignataro                 Expires April 9, 2006                [Page 27]


Internet-Draft               PPP over L2TPv3                October 2005


      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.  Session 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:

       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 L2TPv3 specification [RFC3931] gives a detailed description
   of these AVPs.  However, the AVP values described in [RFC3931] should
   be interpreted differently for different service type payloads



Pignataro                 Expires April 9, 2006                [Page 28]


Internet-Draft               PPP over L2TPv3                October 2005


   carried by L2TPv3.  This section describes the AVP values in the
   context of PPP payload.  This section should be read in conjunction
   with the relevant sections from [RFC3931].

   Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The Data Sequencing AVP, Attribute Type 70, indicates that the
      sender requires some or all of the data packets that it receives
      to be sequenced.

      The Data Sequencing AVP contains a 2-octet unsigned integer value,
      Data Sequencing Level, that indicates the degree of incoming data
      traffic that the sender of this AVP wishes to be marked with
      sequence numbers.

      For PPP over L2TPv3 session establishment, Data sequencing may
      only be requested when the Default L2-Specific Sublayer is present
      to provide sequence numbers.  If sequencing is requested without
      requesting the Default L2-Specific Sublayer in the L2-Specific
      Sublayer AVP, the session MUST be disconnected with a Result Code
      of 15 (see Section 5.4.2) of [RFC3931].

      The Data Sequencing AVP is defined in Section 5.4.4 of [RFC3931].
      The Sequencing Required AVP, Attribute Type 39, MUST NOT be used
      in PPP over L2TPv3.

   Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN, SLI)

      The Circuit Status AVP, Attribute Type 71, indicates the initial
      status of or a status change in the call to which the session is
      bound.

      The Circuit Status AVP contains a 2-octet bitmask with two bits
      currently defined: The A (Active) bit and the N (New) bit.

      For PPP over L2TPv3 session establishment, this AVP MUST be
      included in ICRQ, ICRP, OCRQ and OCRP messages, and MAY be
      included in ICCN, OCCN and SLI messages.  In ICRQ, ICRP, OCRQ and
      OCRP messages, the N (New) bit MUST be set to 1 to indicate a new
      circuit.

      In SLI messages, the Circuit Status AVP MAY be sent to advertise a
      change to Inactive to indicate that the call is down without
      tearing down the entire session.  In this case, all data traffic
      for that session MUST cease (or not begin) in the direction
      towards the sender of the Circuit Status AVP and data traffic from
      the sender of the SLI message with Inactive Circuit Status MUST be
      ignored.  If the receiver of the SLI message with the Inactive



Pignataro                 Expires April 9, 2006                [Page 29]


Internet-Draft               PPP over L2TPv3                October 2005


      indication is unable to stop data traffic, it MUST tear down the
      session with a CDN message.  When the call comes back up, a new
      SLI message is used to re-advertise the subsequent Active state,
      the LNS MUST renegotiate PPP, and data traffic MUST continue (or
      start) upon successful renegotiation.

      If a session is started with an initial status of Inactive, the
      Circuit Status AVP MUST be sent in an SLI when the circuit becomes
      Active.

      The Circuit Status AVP is defined in Section 5.4.5 of [RFC3931].

   Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The Tx Connect Speed BPS AVP, Attribute Type 74, contains the
      speed of the facility chosen for the connection attempt.

      The Tx Connect Speed AVP contains an 8-octet value, Tx Connect
      Speed BPS, that indicates the speed in bits per second.  A value
      of zero indicates that the speed is indeterminable or that there
      is no physical point-to-point link.

      The Tx Connect Speed AVP is defined in Section 5.4.4 of [RFC3931].
      The (Tx) Connect Speed BPS AVP, Attribute Type 24, MUST NOT be
      used in PPP over L2TPv3.

   Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ, OCRP, OCCN)

      The Rx Connect Speed AVP, Attribute Type 75, represents the speed
      of the connection from the perspective of the LAC (i.e., data
      flowing from the remote system to the LAC).

      The Rx Connect Speed AVP contains an 8-octet value, Connect Speed
      BPS, that indicates the speed in bits per second.  A value of zero
      indicates that the speed is indeterminable or that there is no
      physical point-to-point link.  Presence of this AVP implies that
      the connection speed may be asymmetric with respect to the
      transmit connect speed given in the Tx Connect Speed AVP.

      The Rx Connect Speed AVP is defined in Section 5.4.4 of [RFC3931].
      The Rx Connect Speed AVP, Attribute Type 38, MUST NOT be used in
      PPP over L2TPv3.


6.  Data Channel Sequencing

   The general procedures for sequencing data packets are defined in
   Section 4.6.1 of the base L2TPv3 specification [RFC3931].



Pignataro                 Expires April 9, 2006                [Page 30]


Internet-Draft               PPP over L2TPv3                October 2005


   Additionally, Appendix C of [RFC3931] provides sequence number
   processing considerations.

   This section describes the method for using sequence numbers on the
   L2TPv3 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 Default L2-Specific sublayer
   header allows an LCCE to convey sequence information to a peer.
   Unlike the L2TPv3 control plane, the L2TPv3 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, which is a valid sequence number.
   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^24.  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^23 - 1) values, inclusive.  For example,
   if the last received sequence number was 15, then messages with
   sequence numbers 0 through 15, as well as 8388624 through 16777215,
   would be considered less than or equal.

   When desired, sequencing may be enabled on some or all packets by
   using the S bit and Sequence Number field defined in the L2-Specific
   Sublayer (see Section 4.1).  For a given L2TPv3 session, each LCCE is
   responsible for communicating to its peer the level of sequencing
   support that it requires of data packets that it receives using the
   Data Sequencing AVP in Section 5.2.  Mechanisms to advertise this
   information during session negotiation are provided (see Data
   Sequencing AVP in Section 5.4.4).

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



Pignataro                 Expires April 9, 2006                [Page 31]


Internet-Draft               PPP over L2TPv3                October 2005


   channels cannot tolerate reordering, sequencing may be turned on by
   using the sequence number field in the L2-Specific 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
   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^24
   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.  Acknowledgements

   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.
   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.



Pignataro                 Expires April 9, 2006                [Page 32]


Internet-Draft               PPP over L2TPv3                October 2005


   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 initial 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.

   Bill Storer, Madhvi Verma, Skip Booth and Maria Alice Dos Santos
   provided a thorough review, most helpful input and many valuable
   comments.


8.  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.

   Section 8.1 through Section 8.6 are requests for new values already
   managed by IANA.

8.1.  AVP Attributes

   As defined in [RFC3931], 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 5, and
   in some cases, values for those attributes.  Five new AVPs need
   assignment by IANA as described in Section 2.2 of [RFC3438].

   A summary of the new AVPs follows:









Pignataro                 Expires April 9, 2006                [Page 33]


Internet-Draft               PPP over L2TPv3                October 2005


   Control Message Attribute Value Pairs

         Attribute
         Type        Description
         ---------   ------------------
         AVP-TBD-1   Offset Size AVP
         AVP-TBD-2   Tx Minimum Speed AVP
         AVP-TBD-3   Tx Maximum Speed AVP
         AVP-TBD-4   Rx Minimum Speed AVP
         AVP-TBD-5   Rx Maximum Speed AVP

8.2.  Pseudowire Type

   The signaling mechanisms defined in this document rely upon the
   allocation of following Pseudowire Type (see Pseudo Wire Capabilities
   List as defined in 5.4.3 of [RFC3931] and L2TPv3 Pseudowire Types in
   10.6 of [RFC3931] (number space created as part of publication of
   [RFC3931]:


      Pseudowire Type
      ---------------

      0x0007  PPP Pseudowire Type

8.3.  Result Code AVP Values

   A new L2TP Result Code for the CDN message appears in Section 5.1.2
   which need assignment by IANA as described in Section 2.3 of
   [RFC3438].



      RC-TBD1: Session not established due to unsupported Offset Size

8.4.  Bearer Capabilities and Bearer Type

   The Bearer Capabilities AVP and Bearer Type AVP (defined in
   Section 5.1.1 and Section 5.1.2 respectively) both contain a 32-bit
   bitmask called Bearer Field, which is maintained by IANA.

   There is one new bitfield value allocated for this specification:

      Value       Meaning
      0x00000008      V-bit (Virtual access)

   Additional bits should only be defined via a Standards Action
   [RFC2434].



Pignataro                 Expires April 9, 2006                [Page 34]


Internet-Draft               PPP over L2TPv3                October 2005


8.5.  Framing Capabilities and Framing Type

   The Framing Capabilities AVP and Framing Type AVP (defined in
   Section 5.1.1 and Section 5.1.2 respectively) both contain a 32-bit
   bitmask, Framing Field, maintained by IANA.  Additional bits should
   only be defined via a Standards Action [RFC2434].

8.6.  Proxy Authen Type AVP Values

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


9.  Security Considerations

   PPP over L2TPv3 is subject to the security considerations defined in
   [RFC3931].  Specifically, Control Connection Endpoint and Message
   Security mechanisms are provided in Section 4.3 and Section 5.4.1 of
   [RFC3931].  Data Packet Level Security is described in Section 8.2 of
   [RFC3931].  When running over L2TP-over-IP or L2TP-over-UDP/IP, IPsec
   can provide packet-level security via ESP and/or AH, as described in
   Section 4.1.3 of [RFC3931].  Additional security considerations
   specific to carrying PPP frames over L2TPv3 are described in the
   following section.

9.1.  Proxy PPP Authentication

   L2TP defines Proxy LCP and Authentication AVPs that MAY be exchanged
   during session establishment to provide forwarding of PPP LCP and
   authentication information obtained at the LAC to the LNS for
   validation (see Section 5.1.3).  This authentication information may
   be used to initiate the PPP authentication states on the LNS,
   allowing PPP to continue without renegotiation.  This implies a
   direct trust relationship of the LAC on behalf of the LNS.  If the
   LAC is not trusted, the LNS policy may mandate to enter an additional
   round of LCP negotiation and/or authentication.  Therefore, if the
   LNS chooses to implement proxy authentication, it MUST be able to be
   turned off by configuration, requiring a new round of PPP
   authentication initiated by the LNS (which may or may not include a
   new round of LCP negotiation).


10.  References







Pignataro                 Expires April 9, 2006                [Page 35]


Internet-Draft               PPP over L2TPv3                October 2005


10.1.  Normative References

   [ITU.Q931.1998]
              "Digital Subscriber Signalling System No. 1 (DSS 1) - ISDN
              User - Network Interface Layer 3 Specification for Basic
              Call Control", ISO Standard 9594-1, May 1998.

   [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.

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

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

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

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

   [RFC3301]  T'Joens, Y., Crivellari, P., and B. Sales, "Layer Two
              Tunnelling Protocol (L2TP): ATM access network
              extensions", RFC 3301, June 2002.

   [RFC3931]  Lau, J., Townsley, M., and I. Goyret, "Layer Two Tunneling
              Protocol - Version 3 (L2TPv3)", RFC 3931, March 2005.

10.2.  Informative References

   [RFC1144]  Jacobson, V., "Compressing TCP/IP headers for low-speed
              serial links", RFC 1144, February 1990.

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

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

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



Pignataro                 Expires April 9, 2006                [Page 36]


Internet-Draft               PPP over L2TPv3                October 2005


   [RFC3438]  Townsley, W., "Layer Two Tunneling Protocol (L2TP)
              Internet Assigned Numbers Authority (IANA) Considerations
              Update", BCP 68, RFC 3438, December 2002.

   [RFC3985]  Bryant, S. and P. Pate, "Pseudo Wire Emulation Edge-to-
              Edge (PWE3) Architecture", RFC 3985, March 2005.


Appendix A.  Revision History

   [Note to RFC Editor: please remove this entire appendix, and the
   corresponding entries in the table of contents, prior to
   publication.]

   Changes from draft-ietf-l2tpext-l2tp-ppp-01:

   o  Updated title and title abbrev to reflect L2TPv3.

   o  Updated abstract, introduction and topology sections.

   o  Added contributing authors and editors.

   o  Added Section 3.1 and Section 3.2, turned Section 3 into
      Section 3.3.  Added the "PPP PW Type" in Section 3.1.

   o  Added Figure 1 in Section 4.

   o  Decoupled the L2-Specific Sublayer from the Offset Padding in
      Section 4.1, and added new Offset Padding in Section 4.2.

   o  Removed the HDLC Address and Control fields from the encapsulation
      in Section 4.3.

   o  Changed Section 5.1.2 and Section 5.1.4 title, substituting Call
      for Session.

   o  Updated Bearer Capabilities AVP in Section 5.1.1 and Bearer Type
      AVP in Section 5.1.2 with the existing bit B (broadband access) in
      bit 30 and moved bit V (virtual access) to bit 29.

   o  Substituted ICRQ for ICCN in the Framing Type AVP description in
      Section 5.1.2.

   o  Added a note for Called Number AVP, Calling Number AVP and Sub-
      Address AVP to interpret the encoding in the context of the Bearer
      Type in use for the specific call in Section 5.1.2.





Pignataro                 Expires April 9, 2006                [Page 37]


Internet-Draft               PPP over L2TPv3                October 2005


   o  Added Calling Sub-Address AVP (ICRQ) Type 44 in Section 5.1.2.

   o  Added a note to the Q.931 Cause Code AVP to interprete the Cause
      Code relative to the Bearer Type in Section 5.1.2.

   o  Replaced Sequencing Required AVP Type 39 in Section 5.1.2 with the
      Data Sequencing AVP Type 70 defined in [RFC3931], and moved it to
      Section 5.2.

   o  Added Private Group ID AVP existing in [RFC2661] to Section 5.1.2.

   o  Added new Offset Size AVP in Section 5.1.2.

   o  Listed only currently assigned enumerations of "Defined Authen
      Type values" for Proxy Authen Type AVP in Section 5.1.3 and
      Section 8.6, and pointed to Section 8.6.

   o  Added Circuit Status AVP usage in Section 5.2, Section 3.2 and
      Section 3.3.

   o  Added short reference in Section 5.2 to 8-octet Tx/Rx Connect
      Speed AVPs, Type 74 and 75 defined in [RFC3931], instead of
      4-octet Types 24 and 38.

   o  Moved Minimum BPS and Maximum BPS from Section 5.2 to
      Section 5.1.2 because not defined in [RFC3931], and changed them
      to new 8-octet value AVPs renaming them to Tx Minimum Speed and Tx
      Maximum Speed respectively in Section 5.1.2 and Section 8.1.

   o  Added 8-octet Rx Minimum Speed and Rx Maximum Speed in
      Section 5.1.2 and Section 8.1.

   o  Added general sequencing procedures note from [RFC3931] in
      Section 6 as well as updated Section 6.1 with 24-bit Sequence
      Number and usage of Data Sequencing AVP.

   o  Added small paragraph to the IANA Considerations generic section
      about existing vs. new registries.

   o  Added Section 8.2 and Section 8.3 with IANA Considerations for
      Pseudowire Type and Result Code AVP Values.

   o  Regrouped, updated and added the new value from -01 in IANA
      Considerations Section 8.4 (Bearer Capabilities and Bearer Type)
      and Section 8.5 (Framing Capabilities and Framing Type).

   o  Added Security Considerations Section.




Pignataro                 Expires April 9, 2006                [Page 38]


Internet-Draft               PPP over L2TPv3                October 2005


   o  Updated References and split them into Normative and Informative.


















































Pignataro                 Expires April 9, 2006                [Page 39]


Internet-Draft               PPP over L2TPv3                October 2005


Author's Address

   Carlos Pignataro (editor)
   Cisco Systems, Inc.
   7025 Kit Creek Road
   PO Box 14987
   Research Triangle Park, NC  27709
   USA

   Email: cpignata@cisco.com









































Pignataro                 Expires April 9, 2006                [Page 40]


Internet-Draft               PPP over L2TPv3                October 2005


Intellectual Property Statement

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at
   ietf-ipr@ietf.org.


Disclaimer of Validity

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.


Copyright Statement

   Copyright (C) The Internet Society (2005).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.


Acknowledgment

   Funding for the RFC Editor function is currently provided by the
   Internet Society.




Pignataro                 Expires April 9, 2006                [Page 41]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/