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

Versions: 00 01                                                         
PPP Working Group                                      Andrew J. Valencia
Request for Comments: DRAFT                                 Cisco Systems
Category: Internet Draft
Title: draft-ietf-pppext-l2tphc-00.txt
Date: November 1997

                   L2TP Header Compression (''L2TPHC'')

Status of this Memo

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

   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


   The Layer 2 Tunneling Protocol (''L2TP'') defines a mechanism 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 operation.
   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 [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.  A significant
   application of L2TP has emerged, known as "voluntary tunneling" [2].
   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 June 1998                    [Page 1]

INTERNET DRAFT                                             November 1997

2. Simplifying Assumptions

   Fortunately, several simplifying assumptions may be made in the
   voluntary tunneling environment:

      - The client will not operate through a NAT interface
      - The client will not roam (i.e., change its IP address)
      - The client has only one public IP network interface
      - There will be only one tunnel between the client and its LNS
      - There will be only one session within this 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 roaming 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

   In addition, several operational considerations permit further

      - There is no need to optimize control packet overhead
      - Version compatibility may be determined by control packets
      - Rate pacing may be determined outside the main payload exchange
      - Priority packets do not need to be optimized
      - If there are no protocol fields, a protocol header is not required

   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.  Similarly, the
   optional rate pacing of L2TP can be determined outside of the core
   payload packet path.

   If rate pacing is not used, Priority flagged packets will probably be
   present to guarantee the timely exchange of PPP keepalives, routing
   adjacency packets, and so forth.  However, by their nature, these
   packets are a statistically insignificant fraction of the overall
   packet flow, and do not need to be optimized.

   Thus, by choosing very reasonable simplifying assumptions, it is
   possible to entirely remove all L2TP fields from the header of a
   payload packet.  The resulting protocol is simply PPP frames
   encapsulated inside a raw IP protocol header, running in parallel
   with the regular UDP-based L2TP tunnel which provides all management

Valencia                    expires June 1998                    [Page 2]

INTERNET DRAFT                                             November 1997

   and related functions.

3. Tunnel Establishment

   3.1 Negotiation

      L2TPHC is negotiated by an optional AVP 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 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.
      By default, further tunnels may be established, but the operation
      of these tunnels will be using standard UDP-based L2TP tunneling,
      and such payload MUST NOT be forwarded over the header compression

      A single exception is that a peer MAY initiate L2TPHC on further
      tunnels if its L2TPHC AVP specifies a distinct IP protocol number.
      If an SCCRQ holds the L2TPHC AVP from a peer with which L2TPHC is
      already active, an implementation by default MUST disregard the
      AVP and bring up a standard UDP L2TP tunnel.  The implementation
      MAY recognize that the AVP specifies a new IP protocol number, and
      choose a new IP protocol number on its side, and bring up further
      L2TPHC tunnels, with the Tunnel ID being determined by the
      distinct IP protocol numbers of the payload packets.  It is
      recommended that protocol numbers so used start at one greater
      than the default L2TPHC protocol number (see section 3.2), and
      count upwards, using the first number determined to be available
      on a given implementation.

      Once the tunnel associated with a given L2TPHC context has been
      terminated, the L2TPHC context is considered free, and may be used
      in future L2TP connections.

   3.2 AVP Format

      The AVP is encoded as Vendor ID 9, Attribute is the 16-bit
      quantity 0 (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 a single octet, encoding the IP
      protocol number to use for the exchange of payload.  Unless and
      until an official protocol number is allocated, the value 251 is
      recommended.  The AVP is marked optional, permitting
      interoperability with peers not implementing L2TPHC.

Valencia                    expires June 1998                    [Page 3]

INTERNET DRAFT                                             November 1997

       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|           7           |               9               |
      |               0               |       251     |

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 sent is always 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,
   payload 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

   When a packet with the Priority bit is to be sent, it is sent via the
   regular UDP-based tunnel.  Priority packets MUST enjoy priority over
   traffic queued on both the UDP tunnel as well as the corresponding
   raw IP tunnel.

   Since packet flow over this raw IP tunnel is distinct from the UDP
   based tunnel, it is possible that an asymmetry in the path (for
   instance, the unintentional presence of a NAT device) may disrupt one
   but not the other.  It is recommended that at least during the time
   immediately following establishment of the session, that LCP echoes
   be used in tandem with the L2TP keepalive function so that
   connectivity of both paths may be verified.

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 (4 bytes of rate pacing with the
   Nr/Ns fields will probably be avoided in favor of the more compact
   though less comprehensive Priority header bit).

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

Valencia                    expires June 1998                    [Page 4]

INTERNET DRAFT                                             November 1997

   With L2TPHC, the UDP and L2TP headers are absent, leaving only the 20
   bytes of IP header.  The small packet now suffers an overhead of only
   31%, and the larger packet a little short of 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
   reduction 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
   carrying 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.

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
   session.  There are several suitable techniques for controlling this

   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
   connected at a convenient point in the network.  In this environment,
   no additional security may be required, and L2TPHC would operate
   trusting 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
   determined to be acceptable, and L2TP over UDP can be used without

   If PPP encryption under ECP [3] is active, malicious PPP packets 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 efficiencies
   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.

Valencia                    expires June 1998                    [Page 5]

INTERNET DRAFT                                             November 1997

7. Acknowledgments

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

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

8. Contacts

   Andrew J. Valencia
   Cisco Systems
   170 West Tasman Drive
   San Jose CA 95134-1706

9. References

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

   [2] G. Zorn, "RADIUS Attributes for Tunnel Protocol Support", Internet
      draft, July 1997

   [3] G. Meyer, "PPP Encryption Control Protocol (ECP)", RFC 1968

Valencia                    expires June 1998                    [Page 6]