One document matched: draft-ietf-pppext-l2tphc-01.txt
Differences from draft-ietf-pppext-l2tphc-00.txt
PPP Working Group Andrew J. Valencia
Request for Comments: DRAFT Cisco Systems
Category: Internet Draft
Title: draft-ietf-pppext-l2tphc-01.txt
Date: December 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
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
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 December 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
itself.
In addition, several operational considerations permit further
simplification:
- 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
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 could determined outside of the core
payload packet path, or the Priority bit facility could be used
instead.
Thus, by choosing very reasonable simplifying assumptions, it is
possible to minimize the L2TP fields from the header of a payload
packet. The resulting protocol is a one octet mandatory header,
followed by 0, 1, or 2 additional octets, 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
Valencia expires June 1998 [Page 2]
INTERNET DRAFT December 1997
L2TPHC is negotiated by an optional AVP ``L2TPHC-Proto'' 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.
However, L2TPHC permits multiple tunnels if a second AVP,
indicating a special Tunnel ID, is included immediately following
L2TPHC-Proto AVP in the SCCRQ/SCCRP exchange. This optional AVP,
``L2TPHC-Tunnel'', 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.
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. Because all control passes over the
parallel L2TP session corresponding to the L2TPHC one, the L2TP
tunnel terminates, and the L2TPHC tunnel is implicitly terminated.
3.2 AVP Format
The AVP L2TPHC-Proto 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.
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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TPHC-Tunnel AVP is also marked optional. It MUST NOT be
present except when immediately following an L2TPHC-Proto AVP.
The Attribute is the 16-bit value 1, encoded in network byte
order. The single octet Value is a Tunnel ID to be used in the
L2TPHC encapsulation. 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 T bit, 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 tunnel.
Valencia expires June 1998 [Page 3]
INTERNET DRAFT December 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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | 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 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
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 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|F|I|P|0|0|0|0|0| Nr | Ns | Tunnel ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PPP packet... |
+-+-+-+-+-+-+-+-+
The Nr/Ns fields MUST be present if the F bit is 1, otherwise they
MUST be omitted. Their use is identical to that of the fields of the
same name in L2TP payload packets, except that their numerical range
is only 8 bits, rather than 16 in L2TP. A regular L2TP tunnel MUST
be used in any situation where the speed of a link and the latency of
the path result in more packets outstanding than can be accounted
with a byte numbering space.
The I bit MUST be set, and the Tunnel ID MUST be present, if the
L2TPHC-Tunnel AVP was both sent and received during tunnel setup.
Otherwise I must be sent 0, and the Tunnel ID octet omitted from the
packet.
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, with up to three more octets as indicated by the flags in
this first octet.
Valencia expires June 1998 [Page 4]
INTERNET DRAFT December 1997
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%.
With L2TPHC, the UDP 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
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
Valencia expires June 1998 [Page 5]
INTERNET DRAFT December 1997
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
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
L2TPHC.
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.
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 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
vandys@cisco.com
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]
| PAFTECH AB 2003-2026 | 2026-04-22 14:56:03 |