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

Versions: 00

PPP Working Group                                          William Palter
Request for Comments: DRAFT                                RedBack Networks
Category: Internet Draft
Title: draft-ietf-l2tpext-adc-00.txt
Date: October 1999

                 L2TP Alternate Data Channel (``ADC'')

Status of this Memo

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

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

   Internet-Drafts are draft documents valid for a maximum of six
   months.  Internet-Drafts may be updated, replaced, or obsoleted by
   other documents at any time.  It is not appropriate to use Internet-
   Drafts as reference material or to cite them other than as a
   ``working draft'' or ``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.

   To learn the current status of any Internet-Draft, please check the
   1id-abstracts.txt listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or
   munnari.oz.au.

Abstract

   The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for
   tunneling PPP sessions over arbitrary media.  There exists a class of
   services for which different types of data packets should be
   segregated from each other, over the lower layer transport.  This
   document describes the solution space addressed, its underlying
   motivations, and the protocol modifications required.  This
   enhancement to the L2TP protocol is called L2TP Alternate Data
   Channel, or ``L2TPADC''.

1. Introduction

   L2TP [1] defines a general purpose mechanism for tunneling PPP over
   various media.  By design, it insulates L2TP operation from the
   details of the media over which it operates.  There are conditions
   where it may be desirable to send the data portion or some subset of
   the data portion of an L2TP tunnel over a different media, or using
   different options of the lower layer medium than is used for the
   control portion of the tunnel.

Palter                     expires March 2000                    [Page 1]


INTERNET DRAFT                                              October 1999

2. Tunnel Establishment

   2.1 Negotiation

      L2TPADC is negotiated by an optional AVP ``L2TPADC'' which is
      placed in the SCCRQ/SCCRP tunnel establishment messages. The
      effect of this AVP on a given session will never occur until L2TP
      reaches a state where payload data may be forwarded for a session
      in the tunnel.  Additionally, each side intending to use L2TPADC
      MUST NOT do so until it both sends and receives this AVP. Unless
      an L2TPADC AVP exists in both the SCCRQ and SCCRP packets, L2TP
      will operate in its regular mode

   2.2 AVP Format

      The AVP L2TPADC is encoded as Vendor ID 9, Attribute is the 16-bit
      quantity 2 (the ID 9 reflects Cisco Systems, the initial developer
      of this specification, and it SHOULD be changed to 0 and an
      official Attribute value chosen if this specification advances on
      a standards track). The Value is divided into two fields one
      indicating the channel type and usage of this alternate data
      channel and one for media specific information about the channel.
      This AVP itself is optional.  The only type that is currently
      defined is the Degraded IPSEC Channel (see section 2.3.1).

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |0|0|0|0|    8 + data length    |               9               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               2               |         Channel Type          |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      | Media Specific Data .....
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   2.3 Channel Types

      2.3.1 Degraded IPSEC Channel

         The Degraded IPSEC Channel, Channel Type 0, is for use when the
         data flow on a tunnel may require strong security on some
         sessions (or packets within a session) and less secure security
         for other data packets and/or sessions. The control channel
         (which is also the primary data channel) should be setup with
         the highest level of security that is required. The media
         specific data should be set to a 16 bit value indicating
         another UDP port to which data packets can be sent that have
         less security associated with them. For example, a tunnel is
         created with IPSEC encryption on the control channel, and a
         client establishes a PPP session over the tunnel in which ECP
         is also enabled and doing encryption. In this case the ECP PPP
         frames can be sent over the Degraded IPSEC Channel, and non ECP
         protected frames can be sent over the primary data channel. The
         policy for which packets can be sent over the degraded channel

Palter                     expires March 2000                    [Page 2]


INTERNET DRAFT                                              October 1999

         is beyond the scope of this document.  An implementation MUST
         send traffic over the strongest channel, unless it has specific
         policies permitting it to send a packet over the degraded
         channel.

   2.4 Data Packet Flow

      When data packets for a single session are sent over more than
      one, data channel the sequence number space is shared among both
      flows, L2TP SHOULD process all packets for a tunnel without regard
      for which channel the packet is received upon.

   2.5 Control Packet Flow

      Control packets MUST be sent over the  primary channel. If a
      control packet is received on the alternate channel, it MUST be
      discarded.

3. Security Considerations

   Security can be compromised by using this option. It is assumed that
   implementation policies with regard to determining which packets can
   go over a degraded channel will be sufficient to protect security. In
   addition since the security policies may not be symmetrical, an
   implementation should have the ability to be configured not to allow
   this option to be used.

4. Acknowledgments

   Thanks to Andrew J. Valencia, W. Mark Townsley, and Robert Adams of
   Cisco Systems for help in creating, and reviewing this draft.

5. Contacts

   William Palter
   RedBack Networks
   1389 Moffett Park Drive
   Sunnyvale, CA 94089
   palter.ietf@zev.net

6. References

   [1] A. Valencia, ``Layer 2 Tunnel Protocol (L2TP)'', Internet Draft,
      October 1997

Palter                     expires March 2000                    [Page 3]


INTERNET DRAFT                                              October 1999

Palter                     expires March 2000                    [Page 4]


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