[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05 06                                          
Network Working Group                                  Andrew J. Valencia
Request for Comments: DRAFT
Category: Internet Draft
Title: draft-ietf-l2tpext-l2tphc-01.txt
Date: April 2000


                  L2TP Header Compression (``L2TPHC'')


Status of this Memo

   This document is an Internet-Draft and is in full conformance with
   all provisions of Section 10 of RFC2026.  Internet-Drafts are working
   documents of the Internet Engineering Task Force (IETF), its areas,
   and its working groups.  Note that other groups may also distribute
   working documents as Internet-Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference mate-
   rial 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.

Abstract

   The Layer 2 Tunneling Protocol (``L2TP'') [RFC2661] defines a mecha-
   nism for tunneling PPP sessions over arbitrary media.  There exists a
   class of specific media and applications for which protocol overhead
   may be optimized, and where such reduction results in improved opera-
   tion.  This document describes the solution space addressed, its
   underlying motivations, and the protocol modifications required.  The
   enhancement to the L2TP protocol is called L2TP Header Compression,
   or ``L2TPHC''.

1. Introduction

   L2TP [RFC2661] 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.  A significant applica-
   tion of L2TP has emerged, known as ``voluntary tunneling'' [1].  In
   this environment, the L2TP tunnel runs from the dial-up client
   itself, through a public IP infrastructure, and then terminating at
   the target LNS.  Because this mode of operation results in the L2TP
   header traversing the slow, high-latency dial-up link, each byte of
   tunnel overhead can have a measurable impact on the operation of the
   carried protocols.





Valencia                  expires October 2000                   [Page 1]


INTERNET DRAFT                                                April 2000


2. Simplifying Assumptions


   Fortunately, several simplifying assumptions may be made in the vol-
   untary tunneling environment:

      - The client will not operate through a NAT interface
      - The client uses a single IP address for the life of the tunnel
      - The client has only one public IP network interface
      - There may be only one tunnel between the client and its LNS
      - There will be only one session within a tunnel
      - Alignment is not required
      - Packet length is preserved by the IP header

   Each of these simplifying assumptions directly relates to an L2TP
   protocol header field's function.  Because NAT functionality is not
   needed, the UDP header is not required.  Because the client will not
   change its source IP address (due to either changing its IP address
   as it moves among IP egress points, or switching to a distinct backup
   IP interface), the identity of the client may be determined by its
   source IP address, rather than the Tunnel ID.  Because there is only
   one session within the tunnel, it is trivial to determine the Session
   ID.  Because each byte is a measurable component of overhead, it is
   better to send fields on unaligned boundaries rather than ever pad.
   Because IP will preserve the packet length end-to-end, there is no
   need to communicate this in the header itself.

   In addition, several operational considerations permit further sim-
   plification:

      - There is no need to optimize control packet overhead
      - Version compatibility may be determined by control packets

   The first two bytes of an L2TP payload header determined the presence
   of further, optional, fields.  It also contains a Version field, used
   to detect compatible version operation.  Realistically, these may all
   be determined in advance of payload exchange.

   Thus, by choosing very reasonable simplifying assumptions, it is pos-
   sible to minimize the L2TP fields from the header of a payload
   packet.  The resulting protocol is a one octet mandatory header, pos-
   sibly followed by an additional octet, followed by PPP frames, all
   encapsulated within a raw IP protocol header.  These packets are
   exchanged in parallel with the regular UDP-based L2TP tunnel which
   provides all management and related functions.

3. Tunnel Establishment

   3.1 Negotiation

      L2TPHC is negotiated by an optional AVP ``L2TPHC-Protocol'' which
      is placed in the SCCRQ/SCCRP tunnel establishment messages.  The
      effect of this AVP will never occur until L2TP reaches a state
      where payload data may be forwarded within the session in the



Valencia                  expires October 2000                   [Page 2]


INTERNET DRAFT                                                April 2000


      tunnel.  Additionally, each side intending to use L2TPHC MUST NOT
      do so until it both sends and receives this AVP.  Thus, unless
      both sides support L2TPHC, the optional AVP will be ignored by one
      side, and not sent to the other side, and L2TP will operate in its
      regular mode.

      Further sessions within an L2TPHC tunnel MUST NOT be initiated.
      However, L2TPHC permits multiple tunnels if a second AVP, indicat-
      ing a special Tunnel ID, is included immediately following L2TPHC-
      Protocol AVP in the SCCRQ/SCCRP exchange.  This optional AVP,
      ``L2TPHC-Assigned-Tunnel-ID'', is ignored unless it is both sent
      and received.  In this case, the Value indicates the octet value
      which will be included as the Tunnel ID within the L2TPHC header.
      Note that this ID is used only in the L2TPHC header, and is a dis-
      tinct value from the tunnel ID used in L2TP headers.

      Since all control passes over the parallel L2TP tunnel correspond-
      ing to the L2TPHC one, the L2TP tunnel is always the one explic-
      itly terminated, and the associated L2TPHC tunnel is implicitly
      terminated.

   3.2 AVP Format

      The AVP L2TPHC-Protocol is encoded as Vendor ID 9, Attribute is
      the 16-bit quantity 1 (the ID 9 reflects Cisco Systems, the ini-
      tial 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 a single octet,
      encoding the IP protocol number to use for the exchange of pay-
      load.  The overall length of this AVP is thus 7.  The IANA-
      allocated L2TP protocol number is 115.  The M, H, and "rsvd" bits
      MUST all be set to 0.

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H| rsvd  |        7          |               9               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               1               |       115     |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

      The L2TPHC-Assigned-Tunnel-ID AVP MUST also be sent with the M, H,
      and "rsvd" bits all set to 0.  It MUST NOT be present except when
      immediately following an L2TPHC-Protocol AVP.  The Attribute is
      the 16-bit value 2, encoded in network byte order.  The single
      octet Value is a Tunnel ID to be used in the L2TPHC encapsulation.
      The overall length of this AVP is thus 7.  If this AVP is both
      sent and received, up to 256 parallel tunnels may be supported
      between the peers, and all L2TPHC packets MUST include the I bit
      (see below), and the Tunnel ID specified by the peer MUST be used
      as the Tunnel ID in all packets sent to that peer for a given tun-
      nel.





Valencia                  expires October 2000                   [Page 3]


INTERNET DRAFT                                                April 2000


       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |M|H| rsvd  |        7          |               9               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |               2               |  Tunnel ID    |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

4. Payload Exchange

   If the L2TPHC AVP is sent to and received from the peer, PPP payload
   packets may be sent to the peer's IP address as raw IP packets, with
   the IP protocol number set as indicated from the peer.  Note that it
   is legal for each peer to have specified a different protocol number;
   traffic is always sent to the number indicated in the peer's AVP.
   Such payload may be sent any time it would have been legal to send
   such payload over the regular UDP-based L2TP tunnel.  Similarly, pay-
   load over the UDP tunnel MUST always be accepted, even after payload
   has flowed using the header compressed raw IP packet format.  The
   payload so exchanged is always associated with the tunnel on which
   the AVP was received, and with the single session within that tunnel.

   Each L2TPHC payload packet is encoded as:

       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
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |T|L|x|x|S|I|O|P|   Tunnel ID   | PPP packet... |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   x bits indicate reserved bit fields and MUST be set to 0. A packet
   received with a reserved bit set to 1 MUST be silently discarded,
   unless the bit is defined for an extension that is known to the
   implementation.

   The T bit MUST be set to 0, indicating payload.  Control messages are
   never sent over L2TPHC.

   The L bit MUST be set to 0, indicating no length field.  No length
   field is ever present in L2TPHC.

   The S bit MUST be set to 0, indicating no Nr/Ns fields.  Control
   packets are not passed via L2TPHC.  If sequencing of data packets is
   required, L2TPHC MUST NOT be used for those data packets.  However,
   it is legal for data traffic to be mixed, with order-sensitive pack-
   ets using L2TP/UDP, and other data packets using L2TPHC.  In this
   situation, data packets passed using L2TPHC have no impact on L2TP
   sequence numbers.

   The I bit MUST be set to 1, and the Tunnel ID MUST be present, if the
   L2TPHC-Assigned-Tunnel-ID AVP was both sent and received during tun-
   nel setup.  Otherwise I MUST be set to 0, and the Tunnel ID octet
   MUST be omitted from the packet.




Valencia                  expires October 2000                   [Page 4]


INTERNET DRAFT                                                April 2000


   The O bit MUST be set to 0, indicating no offset field.  Offsets are
   never used in L2TPHC.

   The P bit is the Priority bit, and serves the same function as the
   bit of the same name in an L2TP packet.  Priority packets MUST enjoy
   priority over traffic queued on both the UDP tunnel as well as the
   corresponding L2TPHC raw IP tunnel.

   Therefore, an L2TPHC packet will have an L2TPHC header of at least
   one octet, and optionally one additional octet if the I bit is set to
   1.

5. Efficiency Considerations

   Some rough calculations will illustrate the environments in which
   L2TPHC may be beneficial.  Overhead as a percentage of the carried
   traffic will be calculated for a typical packet size involved in bulk
   data transfer (700 bytes), and the canonical 64-byte ``small IP
   packet''.  Percentages will be rounded to the nearest whole number.
   Overhead is tallied for an IP header of 20 bytes, a UDP header of 8
   bytes, and an L2TP header of 8 bytes.

   The worst case is a 64-byte packet carried within a UDP L2TP header.
   The 64 bytes of payload is carried by an overall header of 36 bytes,
   resulting in an overhead of 56%.  With the larger payload size of 700
   bytes, the header is amortized over many more bytes, reducing the
   overhead to 5%.

   With L2TPHC, the UDP header is absent and the L2TPHC header is 1 byte
   for the most compact case.  Overall size is thus one byte of L2TPHC
   and 20 bytes of IP header.  The small packet now suffers an overhead
   of only 32%, and the larger packet 3%.

   Percentage overhead does not represent all the considerations
   involved in reducing overhead.  The average modem connection is still
   only 14,400 bits per second, which translates to a per-byte real-time
   cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing
   characters are not included in the modem-to-modem data transfer).
   Thus, a savings of 16 bytes per packet can also be viewed as a reduc-
   tion of almost 10 milliseconds of latency per packet.  While this
   latency is short enough to be unnoticeable by a human, it may impact
   real-time protocols such as streaming audio or video.

   Thus, L2TP Header Compression provides most of its benefits when car-
   rying streams of small packets.  In environments such as downloading
   of graphic files, or where human interaction is intermingled with the
   short packets, the benefits of L2TP Header Compression will probably
   be undetectable.









Valencia                  expires October 2000                   [Page 5]


INTERNET DRAFT                                                April 2000


6. Security Considerations

   Because L2TPHC has no security facilities, it is critical that its
   operation be reconciled with the security policy of its environment.
   Since L2TPHC has no protocol header at all, it is trivial to spoof a
   source IP address and inject malicious packets into an ongoing ses-
   sion.  There are several suitable techniques for controlling this
   exposure.

   In the simplest case, L2TPHC operates across a private network.  For
   instance, a remote user may dial into a private NAS located on this
   network, and use L2TP (with or without L2TPHC) to cross an IP-only
   portion of this network to establish a multi-protocol session con-
   nected at a convenient point in the network.  In this environment, no
   additional security may be required, and L2TPHC would operate trust-
   ing to the integrity of this private network.

   If the weak protection of a difficult-to-guess protocol header is
   deemed sufficient, expanded protocol overhead has clearly been deter-
   mined to be acceptable, and L2TP over UDP can be used without L2TPHC.

   If PPP encryption under ECP [RFC1968] is active, malicious PPP pack-
   ets are trivially detected and discarded as they are received on the
   raw IP port number.  Similarly, if an IPsec session is protecting the
   IP packets themselves, malicious packets will also be discarded.
   Note that in both cases, an expanded header is implicit in these
   security facilities, which will greatly reduce the overhead efficien-
   cies gained by L2TPHC.  For instance, an MD5 AH IPsec header will add
   32 bytes  to the packet.  The 16 bytes saved by L2TPHC quickly
   approaches statistical insignificance.

7. Acknowledgments

   Thanks to Gurdeep Singh Pall of Microsoft for identifying and
   describing scenarios in which L2TP header size become a concern, and
   for help in designing the L2TPHC header.

   Thanks to Bill Palter of Redback Networks and W. Mark Townsley of
   Cisco Systems for help in reviewing this draft.

8. Contacts

   Andrew J. Valencia
   P.O. Box 2928
   Vashon, WA  98070
   vandys@zendo.com











Valencia                  expires October 2000                   [Page 6]


INTERNET DRAFT                                                April 2000


9. References


   [RFC2661]  M. Townsley, ``Layer 2 Tunnel Protocol (L2TP)'', RFC 2661,
   August 1999

   [1] G. Zorn, ``RADIUS Attributes for Tunnel Protocol Support'', Internet
   draft, August 1999

   [RFC1968] G. Meyer, ``PPP Encryption Control Protocol (ECP)'', RFC 1968,
   June 1996














































Valencia                  expires October 2000                   [Page 7]