[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.
Intended status: Standards Track                           July 10, 2008
Expires: January 11, 2009


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

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 January 11, 2009.

Abstract

   This document describes the use of "version 3" of Layer Two Tunneling
   Protocol (L2TPv3) to tunnel Point-to-Point Protocol (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.










Pignataro               Expires January 11, 2009                [Page 1]


Internet-Draft               PPP over L2TPv3                   July 2008


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Requirements Language  . . . . . . . . . . . . . . . . . .  6
     1.3.  Contributing Authors . . . . . . . . . . . . . . . . . . .  6

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

   3.  Control Channel Specifics for PPP  . . . . . . . . . . . . . .  7
     3.1.  Control Connection Establishment . . . . . . . . . . . . .  7
     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  . . . . . . . . . . . . . . . . . . 11

   5.  AVP Description  . . . . . . . . . . . . . . . . . . . . . . . 12
     5.1.  PPP-Specific AVPs  . . . . . . . . . . . . . . . . . . . . 12
       5.1.1.  Control Connection Management AVPs . . . . . . . . . . 13
         5.1.1.1.  Framing Capabilities (SCCRP, SCCRQ)  . . . . . . . 13
         5.1.1.2.  Bearer Capabilities (SCCRP, SCCRQ) . . . . . . . . 13
         5.1.1.3.  Offset Capability (SCCRP, SCCRQ) . . . . . . . . . 14
       5.1.2.  Session Management AVPs  . . . . . . . . . . . . . . . 15
         5.1.2.1.  Bearer Type (ICRQ, OCRQ) . . . . . . . . . . . . . 15
         5.1.2.2.  Framing Type (ICCN, OCCN, OCRQ)  . . . . . . . . . 16
         5.1.2.3.  Called Number (ICRQ, OCRQ) . . . . . . . . . . . . 16
         5.1.2.4.  Calling Number (ICRQ)  . . . . . . . . . . . . . . 17
         5.1.2.5.  Called Sub-Address (ICRQ, OCRQ)  . . . . . . . . . 18
         5.1.2.6.  Calling Sub-Address (ICRQ) . . . . . . . . . . . . 18
         5.1.2.7.  Q.931 Cause Code (CDN) . . . . . . . . . . . . . . 19
         5.1.2.8.  Private Group ID (ICCN)  . . . . . . . . . . . . . 19
         5.1.2.9.  Offset Size (ICRQ, ICRP, ORCQ, OCRP) . . . . . . . 20
         5.1.2.10. Tx Minimum Speed (OCRQ)  . . . . . . . . . . . . . 21
         5.1.2.11. Tx Maximum Speed (OCRQ)  . . . . . . . . . . . . . 22
         5.1.2.12. Rx Minimum Speed (OCRQ)  . . . . . . . . . . . . . 23
         5.1.2.13. Rx Maximum Speed (OCRQ)  . . . . . . . . . . . . . 23
       5.1.3.  Proxy LCP and Authentication AVPs  . . . . . . . . . . 24
         5.1.3.1.  Initial Received LCP CONFREQ (ICCN)  . . . . . . . 24
         5.1.3.2.  Last Sent LCP CONFREQ (ICCN) . . . . . . . . . . . 25
         5.1.3.3.  Last Received LCP CONFREQ (ICCN) . . . . . . . . . 25
         5.1.3.4.  Proxy Authen Type (ICCN) . . . . . . . . . . . . . 26
         5.1.3.5.  Proxy Authen Name (ICCN) . . . . . . . . . . . . . 27
         5.1.3.6.  Proxy Authen Challenge (ICCN)  . . . . . . . . . . 27
         5.1.3.7.  Proxy Authen ID (ICCN) . . . . . . . . . . . . . . 28
         5.1.3.8.  Proxy Authen Response (ICCN) . . . . . . . . . . . 28



Pignataro               Expires January 11, 2009                [Page 2]


Internet-Draft               PPP over L2TPv3                   July 2008


       5.1.4.  Session Status AVPs  . . . . . . . . . . . . . . . . . 29
         5.1.4.1.  PPP Circuit Errors (WEN) . . . . . . . . . . . . . 29
         5.1.4.2.  ACCM (SLI) . . . . . . . . . . . . . . . . . . . . 30
     5.2.  Service Type Independent AVPs  . . . . . . . . . . . . . . 30
       5.2.1.  Session Management AVPs  . . . . . . . . . . . . . . . 31
         5.2.1.1.  Data Sequencing (ICRQ, ICRP, ICCN, OCRQ, OCRP,
                   OCCN)  . . . . . . . . . . . . . . . . . . . . . . 31
         5.2.1.2.  Circuit Status (ICRQ, ICRP, ICCN, OCRQ, OCRP,
                   OCCN, SLI) . . . . . . . . . . . . . . . . . . . . 31
         5.2.1.3.  Tx Connect Speed (ICRQ, ICRP, ICCN, OCRQ,
                   OCRP, OCCN)  . . . . . . . . . . . . . . . . . . . 32
         5.2.1.4.  Rx Connect Speed (ICRQ, ICRP, ICCN, OCRQ,
                   OCRP, OCCN)  . . . . . . . . . . . . . . . . . . . 32

   6.  Data Channel Sequencing  . . . . . . . . . . . . . . . . . . . 33
     6.1.  Sequence Numbers . . . . . . . . . . . . . . . . . . . . . 33
     6.2.  Data Channel Sequencing over Specific Media  . . . . . . . 34

   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35

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

   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 37
     9.1.  Proxy PPP Authentication . . . . . . . . . . . . . . . . . 38

   10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 38
     10.1. Normative References . . . . . . . . . . . . . . . . . . . 38
     10.2. Informative References . . . . . . . . . . . . . . . . . . 39

   Appendix A.  Revision History  . . . . . . . . . . . . . . . . . . 40

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 43
   Intellectual Property and Copyright Statements . . . . . . . . . . 44












Pignataro               Expires January 11, 2009                [Page 3]


Internet-Draft               PPP over L2TPv3                   July 2008


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 Circuit) or PVC
   (Permanent Virtual Circuit) 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.), and 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 (PWs) to transport PPP
   frames over an IP or other packet-based network.  A PPP Pseudowire
   (PPPPW) emulates a single PPP link between exactly two endpoints.

   This document defines the specific mechanisms for the tunneling of
   PPP 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.



Pignataro               Expires January 11, 2009                [Page 4]


Internet-Draft               PPP over L2TPv3                   July 2008


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

   Packet Switched Network (PSN)

      A network that uses packet switching technology for data delivery.
      For L2TPv3, this layer is principally IP.  Other examples include
      MPLS, Frame Relay, and ATM.  See also [RFC3985].

   POTS

      Plain Old Telephone Service.

   Pseudowire (PW)

      An emulated circuit as it traverses a PSN.  See also [RFC3985].
      There is one Pseudowire per L2TP Session.

   PPPPW

      PPP Pseudowire.







Pignataro               Expires January 11, 2009                [Page 5]


Internet-Draft               PPP over L2TPv3                   July 2008


1.2.  Requirements Language

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


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 vice versa.  This model typically involves



Pignataro               Expires January 11, 2009                [Page 6]


Internet-Draft               PPP over L2TPv3                   July 2008


   symmetric establishment: Either side of the connection may initiate a
   session at any time, or simultaneously (utilizing the tie breaking
   mechanism defined in Section 5.4.4. of [RFC3931]).


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 PPP over L2TPv3 or that differ
   from [RFC2661].

3.1.  Control Connection Establishment

   In order to tunnel PPP over L2TPv3, an L2TPv3 Control Connection MUST
   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
   Section 8.2), 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 the 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



Pignataro               Expires January 11, 2009                [Page 7]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.1.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
   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 a LAC to indicate a change in the circuit
   status underneath PPP.



Pignataro               Expires January 11, 2009                [Page 8]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

   The following AVP MAY be present in the SLI:

   ACCM

      This AVP is described in Section 5.1.4.2.

   Circuit Status

      In SLI messages, the N (New) bit of the Circuit Status AVP MUST be
      set to 0 indicating that the status is for an existing circuit.
      This AVP is described in Section 5.2.1.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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                     L2TP 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
   an L2TP Session Header (see Section 4.1 of [RFC3931]) followed by the
   optional Default L2-specific Sublayer, an optional variable-length
   Offset Padding and then the Tunnel Payload (PPP Frames).



Pignataro               Expires January 11, 2009                [Page 9]


Internet-Draft               PPP over L2TPv3                   July 2008


   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 existence (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 request 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.9), in a similar fashion as requesting the presence
   and format of the L2-Specific Sublayer (with the L2-Specific Sublayer
   AVP) or the size and value of the Cookie (with the Assigned Cookie
   AVP).  The Offset Size request is conditioned by the upstream's LCCE
   capability (see Section 4.2).

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 Padding field follows the Default L2-
   Specific Sublayer if present or the L2TPv3 Session Header otherwise.
   For a given L2TPv3 Session and direction, all Data Messages have the
   same Offset Padding Size.

   During Control Connection establishment, an LCCE advertises the
   maximum Offset Padding size that it is willing to insert, if
   requested at Session establishment, for all the associated Sessions
   within that Control Connection.  This capability advertisement is
   performed using the Offset Capability AVP (see Section 5.1.1.3), and
   allows the sender of L2TP data messages (i.e., the upstream LCCE) to
   have control over the offset size.



Pignataro               Expires January 11, 2009               [Page 10]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.9).  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 requested by a peer during session negotiation is limited by the
   offset capability value advertised during control connection
   establishment.  An offset capability of zero advertised during
   control connection establishment indicates that no offset padding can
   be requested on sessions within the control connection.

   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], and
   Section 3.1 and Section 3.2 of this document for details on Control
   Connection and Session 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 L2TPv3 data header (see [RFC3931]) followed by the optional
   Default L2-Specific Sublayer (see Section 4.1) and optional 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 or ACF),
   flags and trailing FCS.  The remaining data, including the protocol
   field, is transported over the L2TPv3 session.  The LNS then 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.  If the LNS wishes to support Address-and-
   Control-Field-Compression (ACFC) [RFC1661], it MUST support the "LCP
   Options From LNS to LAC" extensions defined in Section 2.3 of
   [RFC3437].  The LAC needs to learn the negotiated ACFC settings to
   know whether the ACF needs to be re-inserted on output towards the



Pignataro               Expires January 11, 2009               [Page 11]


Internet-Draft               PPP over L2TPv3                   July 2008


   remote system.

   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 SHOULD NOT include the HDLC Address and Control Fields
   (ACF).  An LCCE SHOULD strip off the ACF before encapsulating the PPP
   frames in L2TP and forwarding them over the PPPPW session.  The
   reception and transmission of the HDLC header on a PPP Attachment
   Circuit (AC) is media specific.  If the LAC is providing L2TPv3
   transport for a PPP AC that requires HDLC Address and Control Fields,
   then this information SHOULD be stripped before transmitting the
   packet into the L2TPv3 session.  Similarly, for a PPP AC that
   requires the HDLC header, the LAC MUST check the presence of the ACF
   and, if ACF is not present, prepend it to packets received from the
   L2TPv3 session before transmitting them out of the AC.  While the
   sender SHOULD omit and not send the HDLC Address and Control Fields,
   a receiver MUST allow the HDLC Address and Control Fields to be
   present in a received packet, for robustness reasons.

   It is worth noting that if an implementation wishes to receive the
   space equivalent to the HDLC Address and Control Fields in the
   tunneled PPP frame, it can request a two-octet offset padding with
   the Offset Size AVP if it received the Offset Capability of at least
   two from the peer during control connection establishment.


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.

5.1.  PPP-Specific AVPs








Pignataro               Expires January 11, 2009               [Page 12]


Internet-Draft               PPP over L2TPv3                   July 2008


5.1.1.  Control Connection Management AVPs

   The AVPs described in this section are included in the Control
   Connection messages.

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

5.1.1.2.  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
   interfaces of the sender for outgoing calls.




Pignataro               Expires January 11, 2009               [Page 13]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.1.3.  Offset Capability (SCCRP, SCCRQ)

   The Offset Capability AVP, Attribute Type AVP-TBD-1, indicates the
   size in octets of the Offset Padding field the sender of this AVP is
   willing and capable to insert, if requested at Session establishment.
   The Offset Capability AVP sets the maximum value that an LCCE peer
   can request in the Offset Size AVP for a session within this control
   connection (see Section 4.2), allowing the sender of L2TP data
   messages (i.e., the upstream LCCE) to have control over the offset
   size.

   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 Capability       |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Offset Capability is a 2-octet unsigned integer.  If absent, the
   peer MUST assume a value of zero, which implies that the peer MUST



Pignataro               Expires January 11, 2009               [Page 14]


Internet-Draft               PPP over L2TPv3                   July 2008


   NOT request Offset Padding (i.e., MUST NOT send the Offset Size AVP
   for sessions within this control connection).

   A missing Offset Capability AVP or an Offset Capability AVP with a
   value of zero indicates that the Offset Size AVP cannot be sent by
   the peer LCCE.  If this AVP is received and has a value other than
   zero, the receiving LCCE can request an Offset Padding using the
   Offset Size AVP up to the value indicated 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 8.

5.1.2.  Session Management AVPs

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

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



Pignataro               Expires January 11, 2009               [Page 15]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

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

   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.

5.1.2.3.  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 January 11, 2009               [Page 16]


Internet-Draft               PPP over L2TPv3                   July 2008


   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].  Newly defined
   alternate encodings qualified by the Bearer Type SHOULD use ASCII
   encoding of the value, although the value of this AVP is binary
   encoded when the B bit is set in the Bearer Type AVP [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.

5.1.2.4.  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 Calling
   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].  Newly defined alternate
   encodings qualified by the Bearer Type SHOULD use ASCII encoding of
   the value, although the value of this AVP is binary encoded when the
   B bit is set in the Bearer Type AVP [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.



Pignataro               Expires January 11, 2009               [Page 17]


Internet-Draft               PPP over L2TPv3                   July 2008


5.1.2.5.  Called Sub-Address (ICRQ, OCRQ)

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

   The Called 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
   Sub-Address 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].  Newly defined alternate
   encodings qualified by the Bearer Type SHOULD use ASCII encoding of
   the value, although the value of this AVP is binary encoded when the
   B bit is set in the Bearer Type AVP [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 Sub-Address.

5.1.2.6.  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 Calling
   Sub-Address encodings MAY be defined to be interpreted in the context



Pignataro               Expires January 11, 2009               [Page 18]


Internet-Draft               PPP over L2TPv3                   July 2008


   of the Bearer Type in use for the specific call.  An example of
   alternate encoding is defined in [RFC3301].  Newly defined alternate
   encodings qualified by the Bearer Type SHOULD use ASCII encoding of
   the value, although the value of this AVP is binary encoded when the
   B bit is set in the Bearer Type AVP [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 Sub-Address.

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

5.1.2.8.  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 January 11, 2009               [Page 19]


Internet-Draft               PPP over L2TPv3                   July 2008


   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 an ASCII string.  Contact between the
   administrator of the LAC and the LNS may be necessary to coordinate
   interpretation of the value of this AVP.

   The LNS MAY treat the PPP session as well as network traffic through
   this session in a special manner determined by the Private Group ID
   value.  The Private Group ID defines the particular characteristics
   of the selected group.  For example, the LNS could interpret this AVP
   to route traffic from this session to a particular interface or
   private network.

   A LAC MAY determine the Private Group ID from an AAA (Authentication,
   Authorization and Accounting) protocol response 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.

5.1.2.9.  Offset Size (ICRQ, ICRP, ORCQ, OCRP)

   The Offset Size AVP, Attribute Type AVP-TBD-2, 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), and is conditioned to the value received in the
   Offset Capability AVP.







Pignataro               Expires January 11, 2009               [Page 20]


Internet-Draft               PPP over L2TPv3                   July 2008


   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 the value that the peer LCCE advertised in the
   Offset Capability AVP during control connection establishment.  If
   this AVP is absent, the peer MUST assume a value of zero.

   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
   the received Offset Capability AVP for the control connection), the
   receiving LCCE MUST include an Offset Padding of the requested size
   in its outgoing data messages.

   If the LCCE receiving this AVP has not advertised an Offset
   Capability AVP, if the requested size is greater than the value
   advertised in the Offset Capability AVP, or if the LCCE receiving
   this AVP is not capable, configured or willing to include an Offset
   Padding field of the requested size, the LCCE MUST reject the session
   via a CDN message 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.

5.1.2.10.  Tx Minimum Speed (OCRQ)

   The Tx Minimum Speed AVP, Attribute Type AVP-TBD-3, 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).










Pignataro               Expires January 11, 2009               [Page 21]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.  When the optional Rx
   Minimum Speed AVP is NOT present, then symmetric transmission is
   implied, with both minimum receive and transmit bit-rates equal to
   the Tx Minimum Speed BPS.

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

   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.

5.1.2.11.  Tx Maximum Speed (OCRQ)

   The Tx Maximum Speed AVP, Attribute Type AVP-TBD-4, 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.  When the optional Rx
   Maximum Speed AVP is NOT present, then symmetric transmission is
   implied, with both maximum receive and transmit bit-rates equal to
   the Tx Maximum Speed BPS.

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



Pignataro               Expires January 11, 2009               [Page 22]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

5.1.2.12.  Rx Minimum Speed (OCRQ)

   The Rx Minimum Speed AVP, Attribute Type AVP-TBD-5, 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.

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

   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.2.13.  Rx Maximum Speed (OCRQ)

   The Rx Maximum Speed AVP, Attribute Type AVP-TBD-6, 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.













Pignataro               Expires January 11, 2009               [Page 23]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

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

   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.

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










Pignataro               Expires January 11, 2009               [Page 24]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

5.1.3.2.  Last Sent LCP CONFREQ (ICCN)

   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.

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










Pignataro               Expires January 11, 2009               [Page 25]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

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

       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



Pignataro               Expires January 11, 2009               [Page 26]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

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

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












Pignataro               Expires January 11, 2009               [Page 27]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

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

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



Pignataro               Expires January 11, 2009               [Page 28]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.  Session Status AVPs

5.1.4.1.  PPP Circuit Errors (WEN)

   The PPP Circuit Errors AVP, Attribute Type AVP-TBD-7, conveys PPP
   specific circuit error information to the peer, and complements the
   Circuit Errors AVP, Attribute Type 34.

   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            |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                           CRC Errors                          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Framing Errors                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The following fields are defined:

      Reserved:
      Two octets of Reserved data is present (providing longword
      alignment within the AVP of the following values).  Reserved data
      MUST be zero on sending and ignored upon receipt.




Pignataro               Expires January 11, 2009               [Page 29]


Internet-Draft               PPP over L2TPv3                   July 2008


      CRC Errors:
      Number of PPP frames received with CRC errors since the session
      was established.

      Framing Errors:
      Number of improperly framed PPP packets received.

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

5.1.4.2.  ACCM (SLI)

   The ACCM AVP, Attribute Type 35, is used by the LNS to inform the 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                           |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                          Receive ACCM                         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   The Send ACCM and Receive ACCM fields are 4-octet values preceded by
   a 2-octet reserved quantity.  The Reserved field provides longword
   alignment within the AVP of the Send and Receive ACCM values, and
   MUST be zero on sending and ignored upon receipt.  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 January 11, 2009               [Page 30]


Internet-Draft               PPP over L2TPv3                   July 2008


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

5.2.1.  Session Management AVPs

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

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

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



Pignataro               Expires January 11, 2009               [Page 31]


Internet-Draft               PPP over L2TPv3                   July 2008


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

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

   The Tx Connect Speed 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.

   When the optional Rx Connect Speed AVP is present, the value in this
   AVP represents the transmit connect speed from the perspective of the
   LAC (i.e., data flowing from the LAC to the remote system).  When the
   optional Rx Connect Speed AVP is NOT present, the connection speed
   between the remote system and LAC is assumed to be symmetric and is
   represented by the single value in this AVP.

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

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

   The Rx Connect Speed AVP, Attribute Type 75, represents the receive
   connect 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, Rx 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.




Pignataro               Expires January 11, 2009               [Page 32]


Internet-Draft               PPP over L2TPv3                   July 2008


   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 BPS AVP, Attribute Type 38, MUST NOT be used in
   PPP over L2TPv3 signaling.


6.  Data Channel Sequencing

   The general procedures for sequencing data packets are defined in
   Section 4.6.1 of the base L2TPv3 specification [RFC3931].
   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.1.1.  Mechanisms to advertise this
   information during session negotiation are provided (see Data



Pignataro               Expires January 11, 2009               [Page 33]


Internet-Draft               PPP over L2TPv3                   July 2008


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





Pignataro               Expires January 11, 2009               [Page 34]


Internet-Draft               PPP over L2TPv3                   July 2008


7.  Acknowledgements

   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:

      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.

      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.

      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.

   Bill Storer, Madhvi Verma, Skip Booth and Maria Alice Dos Santos
   provided thorough reviews, most helpful input and many valuable
   comments and suggestions for the newer versions of the document.

   Later, Mahesh Kelkar provided a healthy review of this document.  Y
   Prasad provided input and comments on the handling of the offset
   padding.  Alfred Hoenes provided many editorial suggestions that
   improved the text.


8.  IANA Considerations

   This document defines "magic" numbers to be maintained by the IANA.
   The Layer Two Tunneling Protocol "L2TP" Name Spaces are reachable
   from [IANA.l2tp-parameters].

   Section 8.1 through Section 8.6 are registrations of new L2TP values



Pignataro               Expires January 11, 2009               [Page 35]


Internet-Draft               PPP over L2TPv3                   July 2008


   for registries already managed by IANA, and in some cases,
   description of the assignment policy for those registries.

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

   A summary of the new AVPs follows:

   Control Message Attribute Value Pairs

         Attribute
         Type        Description
         ---------   ------------------
         AVP-TBD-1   Offset Capability AVP
         AVP-TBD-2   Offset Size AVP
         AVP-TBD-3   Tx Minimum Speed AVP
         AVP-TBD-4   Tx Maximum Speed AVP
         AVP-TBD-5   Rx Minimum Speed AVP
         AVP-TBD-6   Rx Maximum Speed AVP
         AVP-TBD-7   PPP Circuit Errors

   Additionally, IANA is requested to rename the Sub-Address AVP,
   Attribute Type 23, to "Called Sub-Address AVP".

8.2.  Pseudowire Type

   The signaling mechanisms defined in this document rely upon the
   allocation of the following Pseudowire Type (see Pseudowire
   Capabilities List as defined in Section 5.4.3 of [RFC3931], and
   L2TPv3 Pseudowire Types in Section 10.6 of [RFC3931]) by the IANA.
   The number space is already created as part of the publication of
   [RFC3931].  The PPP Pseudowire Type is defined in Section 3.1 of this
   specification:


      L2TPv3 Pseudowire Types
      -----------------------

      0x0007  PPP Pseudowire Type







Pignataro               Expires January 11, 2009               [Page 36]


Internet-Draft               PPP over L2TPv3                   July 2008


8.3.  Result Code AVP Values

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


      Result Code AVP (Attribute Type 1) Values
      -----------------------------------------

         Defined Result Code values for the CDN message are:



            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.2 and Section 5.1.2.1 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 assigned via Standards Action
   [RFC5226].

8.5.  Framing Capabilities and Framing Type

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

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


9.  Security Considerations

   PPP over L2TPv3 is subject to the security considerations defined in



Pignataro               Expires January 11, 2009               [Page 37]


Internet-Draft               PPP over L2TPv3                   July 2008


   [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

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.

   [RFC2661]  Townsley, W., Valencia, A., Rubens, A., Pall, G., Zorn,



Pignataro               Expires January 11, 2009               [Page 38]


Internet-Draft               PPP over L2TPv3                   July 2008


              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.

   [RFC3437]  Palter, W. and W. Townsley, "Layer-Two Tunneling Protocol
              Extensions for PPP Link Control Protocol Negotiation",
              RFC 3437, December 2002.

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

   [RFC5226]  Narten, T. and H. Alvestrand, "Guidelines for Writing an
              IANA Considerations Section in RFCs", BCP 26, RFC 5226,
              May 2008.

10.2.  Informative References

   [IANA.l2tp-parameters]
              Internet Assigned Numbers Authority, "Layer Two Tunneling
              Protocol "L2TP"", April 2007,
              <http://www.iana.org/assignments/l2tp-parameters>.

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

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







Pignataro               Expires January 11, 2009               [Page 39]


Internet-Draft               PPP over L2TPv3                   July 2008


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 between -07 and -08:

   o  Added section elements to all the AVPs in Section 5, and include
      them in the TOC.  Updated citations to all these subsections.

   o  Multiple editorial fixes and enhancements from Alfred Hoenes.

   o  Miscelaneous updates in the Called/Calling Number/Sub-Address and
      Private Group ID from Ignacio Goyret.

   o  IANA instructions to rename the Sub-Address AVP to "Called Sub-
      Address AVP".

   o  Updated reference from RFC2434 to [RFC5226].

   Changes between -06 and -07:

   o  Refresh document about to expire, no content changes.

   Changes between -05 and -06:

   o  Added an Offset Capability AVP at tunnel establishment, to allow
      an LCCE advertise the maximum Offset Padding size that it is
      willing to insert if requested.  This is described in Section 4.2
      and Section 5.1.1.3.

   o  Small clarifications regarding the Offset Size on Section 4 and
      Section 5.1.2.9.

   o  Clarified handing of the ACF in Section 4.3, which resulted in
      normatively referencing [RFC3437].

   o  Added reference and corresponding citation to IANA's l2tp-
      parameters.

   Changes between -04 and -05:

   o  Refresh revision, only rev++, date and boiler changes from new
      xml2rfc.tcl version.

   Changes between -03 and -04:




Pignataro               Expires January 11, 2009               [Page 40]


Internet-Draft               PPP over L2TPv3                   July 2008


   o  Fixed assorted editorial and typographical errors.

   o  Moved Section 1.2 and Section 1.3, new acronym in Section 1.1.

   o  Added a final sentence in Section 2.

   o  Added clarification regarding the presence of the Rx Minimum|
      Maximum|Connect Speed AVPs.

   o  Change in Section 8.2 and Section 8.2 to match IANA's page format.

   o  Source changes for strict XML.

   Changes between -02 and -03:

   o  Fixed PPP acronym in the Abstract.

   o  Added PPP Circuit Errors AVP in Section 5.1.4.1 with the two PPP-
      specific fields removed from the Circuit Errors AVP 34 in
      [RFC3931].

   o  Redraw ACCM AVP figure in Section 5.1.4.2 and added Reserved field
      explanation.

   Changes between -01 and -02:

   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.2 and Bearer Type
      AVP in Section 5.1.2.1 with the existing bit B (broadband access)



Pignataro               Expires January 11, 2009               [Page 41]


Internet-Draft               PPP over L2TPv3                   July 2008


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

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

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

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

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

   o  Added new Offset Size AVP in Section 5.1.2.9.

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

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

   o  Added short reference in Section 5.2.1.3 and Section 5.2.1.4 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.



Pignataro               Expires January 11, 2009               [Page 42]


Internet-Draft               PPP over L2TPv3                   July 2008


   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.

   o  Updated References and split them into Normative and Informative.


Author's Address

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

   Email: cpignata@cisco.com





























Pignataro               Expires January 11, 2009               [Page 43]


Internet-Draft               PPP over L2TPv3                   July 2008


Full Copyright Statement

   Copyright (C) The IETF Trust (2008).

   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.

   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, THE IETF TRUST 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.


Intellectual Property

   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.











Pignataro               Expires January 11, 2009               [Page 44]


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