One document matched: draft-ietf-l2tpext-l2tphc-02.txt
Differences from draft-ietf-l2tpext-l2tphc-01.txt
Network Working Group Andrew J. Valencia
Request for Comments: DRAFT
Category: Internet Draft
Title: draft-ietf-l2tpext-l2tphc-02.txt
Date: June 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
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.
Abstract
The Layer 2 Tunneling Protocol (``L2TP'') [RFC2661] defines a
mechanism for tunneling PPP sessions over arbitrary media. There
exists a class of specific media 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 [RFC2661] defines a general purpose mechanism for tunneling PPP
over various media. In most cases, the header overhead of the L2TP
tunnel is negligible. However, when L2TP operates over bandwidth
constrained networks such as dialup links or some classes of WAN
backhauls, any savings of bytes transmitted results in a substantial
efficiency gain. This effect is further amplified when streams of
small IP packets dominate the traffic (thus increasing the header-
to-payload ratio), as is common with multimedia and other types of
real-time data traffic.
Valencia expires December 2000 [Page 1]
INTERNET DRAFT June 2000
2. Simplifying Assumptions
If several simplifying assumptions may be met, it is possible to
reduce the size of the L2TP encapsulation:
- The tunnel will not operate through a NAT interface
- The tunnel uses a single IP address for the life of the tunnel
- The tunnel's host uses only one public IP network interface
- There will be only one tunnel between the LAC and the LNS
- There might 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 endpoints will
not change their source IP addresses (due to either changing IP
addresses, moving among IP egress points, or switching to a distinct
backup IP interface), the identity of the peer may be determined by
its source IP address, rather than the Tunnel ID. If 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
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
possible to minimize the L2TP fields in the header of a payload
packet. The resulting protocol is a one octet mandatory header,
possibly followed by one or two additional octets, followed by a PPP
frame, 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-Assigned-
Session-ID'' which is placed in the ICRQ/ICRP and OCRQ/OCRP
session establishment messages. The effect of this AVP will never
occur until L2TP reaches a state where the session within the
Valencia expires December 2000 [Page 2]
INTERNET DRAFT June 2000
tunnel is fully established (i.e., success indicated in the
ICCN/OCCN). Additionally, each side intending to use L2TPHC MUST
NOT do so unless it both sends and receives this AVP. Thus,
unless both sides support L2TPHC, the optional AVP (in the ICRQ or
OCRQ message) will be ignored by one side, and not sent (in the
corresponding ICRP or OCRP) to the other side, and L2TP will
operate in its regular mode.
As L2TPHC does not provide a Tunnel ID, there can be only a single
tunnel using L2TPHC between any two IP peers (with multiple
sessions within, if needed).
Since all control messages are passed over the parallel L2TP
tunnel corresponding to the L2TPHC one, tunnel shutdown of the
L2TP session is always achieved by explicitly closing the L2TP
session; the associated L2TPHC session is implicitly terminated.
3.2 AVP 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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|M|H| rsvd | (6, 7, or 8) | 9 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| 1 | Session ID1 | Session ID2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The L2TPHC-Assigned-Session-ID AVP MUST always be sent with the M,
H, and "rsvd" bits all set to 0. The Attribute is the 16-bit
value 1, encoded in network byte order. The Vendor ID is 9,
reflecting Cisco Systems, the initial developer of this
extension--a new Attribute value under Vendor ID 0 MUST be
assigned if this document advances on the standards track. The
Value field is set based on how session ID's will be used for this
L2TPHC client. If the Length field of the AVP is 6, the Value
field is not present, and the session ID value 0 is implicitly
used. The I and J bits of the payload packet (see section 4) MUST
be set to zero. If the Length field is 7, then a one-byte session
ID is present in the AVP, and this is the value to use in the
L2TPHC session ID field. The I bit MUST be set to one in the
L2TPHC payload, and the J bit MUST be to zero. Finally, the
Length field may be 8, and a two-byte session ID is contained in
the Value field. L2TPHC payload MUST be sent with both the I and
J bits set to one. The two-byte Value is encoded in network byte
order.
Note that the Session ID value used in the L2TPHC session is
distinct from the value used in the corresponding L2TP session.
Also, a single session ID namespace applies to all sizes of this
AVP. Thus, the 6- byte variant (implying 0), the 7-byte variant
with Session ID1 set to 0, and the 8-byte variant with both
Session ID1 and ID2 set to 0 all refer to the same session ID.
Valencia expires December 2000 [Page 3]
INTERNET DRAFT June 2000
4. Payload Exchange
If the L2TPHC-Assigned-Session-ID 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 to 115. 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 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 2
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|T|L|J|x|S|I|O|P| Session 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
packets using a sequenced data extension of L2TP/UDP, and other data
packets using L2TPHC. In this situation, data packets passed using
L2TPHC would have no impact on L2TP sequence numbers.
The I and J bits are set based on the Length of the Value portion of
the L2TPHC-Assigned-Session-ID AVP. For a Length of 6, neither I nor
J is set, and a Session ID of 0 is implicit. For a Length of 7, I is
set and J is not, and the one-byte Session ID is inserted between the
header bits and the PPP packet. For a Length of 8, both I and J are
set, and the two-byte Session ID is inserted between the header bits
and the PPP packet.
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.
Valencia expires December 2000 [Page 4]
INTERNET DRAFT June 2000
Therefore, an L2TPHC packet will have an L2TPHC header of at least
one octet, and optionally one or two additional octets based on the
setting of the I and J bits:
I J Header size (in bytes)
--- --- ---
0 0 1
1 0 2
1 1 3
Following this header would be the PPP frame.
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. Consider a modem connection operating
at 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). 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.
Valencia expires December 2000 [Page 5]
INTERNET DRAFT June 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
session. 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
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 [RFC1968] 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 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 December 2000 [Page 6]
INTERNET DRAFT June 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 December 2000 [Page 7]
| PAFTECH AB 2003-2026 | 2026-04-22 15:17:20 |