idnits 2.17.1 draft-ietf-l2tpext-l2tphc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing document type: Expected "INTERNET-DRAFT" in the upper left hand corner of the first page ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == The page length should not exceed 58 lines per page, but there was 6 longer pages, the longest (page 2) being 66 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 7 pages Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 3 instances of too long lines in the document, the longest one being 3 characters in excess of 72. ** The abstract seems to contain references ([RFC2661]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 105: '... side intending to use L2TPHC MUST NOT...' RFC 2119 keyword, line 111: '...an L2TPHC tunnel MUST NOT be initiated...' RFC 2119 keyword, line 130: '...ification, and it SHOULD be changed to...' RFC 2119 keyword, line 136: '... MUST all be set to 0....' RFC 2119 keyword, line 146: '...ed-Tunnel-ID AVP MUST also be sent wit...' (15 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 289 has weird spacing: '...2 bytes to th...' == Unrecognized Status in 'Category: Internet Draft', assuming Proposed Standard (Expected one of 'Standards Track', 'Full Standard', 'Draft Standard', 'Proposed Standard', 'Best Current Practice', 'Informational', 'Experimental', 'Informational', 'Historic'.) -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 2000) is 8771 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Andrew J. Valencia 2 Request for Comments: DRAFT 3 Category: Internet Draft 4 Title: draft-ietf-l2tpext-l2tphc-01.txt 5 Date: April 2000 7 L2TP Header Compression (``L2TPHC'') 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. Internet-Drafts are working 13 documents of the Internet Engineering Task Force (IETF), its areas, 14 and its working groups. Note that other groups may also distribute 15 working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference mate- 20 rial or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 Abstract 30 The Layer 2 Tunneling Protocol (``L2TP'') [RFC2661] defines a mecha- 31 nism for tunneling PPP sessions over arbitrary media. There exists a 32 class of specific media and applications for which protocol overhead 33 may be optimized, and where such reduction results in improved opera- 34 tion. This document describes the solution space addressed, its 35 underlying motivations, and the protocol modifications required. The 36 enhancement to the L2TP protocol is called L2TP Header Compression, 37 or ``L2TPHC''. 39 1. Introduction 41 L2TP [RFC2661] defines a general purpose mechanism for tunneling PPP 42 over various media. By design, it insulates L2TP operation from the 43 details of the media over which it operates. A significant applica- 44 tion of L2TP has emerged, known as ``voluntary tunneling'' [1]. In 45 this environment, the L2TP tunnel runs from the dial-up client 46 itself, through a public IP infrastructure, and then terminating at 47 the target LNS. Because this mode of operation results in the L2TP 48 header traversing the slow, high-latency dial-up link, each byte of 49 tunnel overhead can have a measurable impact on the operation of the 50 carried protocols. 52 2. Simplifying Assumptions 54 Fortunately, several simplifying assumptions may be made in the vol- 55 untary tunneling environment: 57 - The client will not operate through a NAT interface 58 - The client uses a single IP address for the life of the tunnel 59 - The client has only one public IP network interface 60 - There may be only one tunnel between the client and its LNS 61 - There will be only one session within a tunnel 62 - Alignment is not required 63 - Packet length is preserved by the IP header 65 Each of these simplifying assumptions directly relates to an L2TP 66 protocol header field's function. Because NAT functionality is not 67 needed, the UDP header is not required. Because the client will not 68 change its source IP address (due to either changing its IP address 69 as it moves among IP egress points, or switching to a distinct backup 70 IP interface), the identity of the client may be determined by its 71 source IP address, rather than the Tunnel ID. Because there is only 72 one session within the tunnel, it is trivial to determine the Session 73 ID. Because each byte is a measurable component of overhead, it is 74 better to send fields on unaligned boundaries rather than ever pad. 75 Because IP will preserve the packet length end-to-end, there is no 76 need to communicate this in the header itself. 78 In addition, several operational considerations permit further sim- 79 plification: 81 - There is no need to optimize control packet overhead 82 - Version compatibility may be determined by control packets 84 The first two bytes of an L2TP payload header determined the presence 85 of further, optional, fields. It also contains a Version field, used 86 to detect compatible version operation. Realistically, these may all 87 be determined in advance of payload exchange. 89 Thus, by choosing very reasonable simplifying assumptions, it is pos- 90 sible to minimize the L2TP fields from the header of a payload 91 packet. The resulting protocol is a one octet mandatory header, pos- 92 sibly followed by an additional octet, followed by PPP frames, all 93 encapsulated within a raw IP protocol header. These packets are 94 exchanged in parallel with the regular UDP-based L2TP tunnel which 95 provides all management and related functions. 97 3. Tunnel Establishment 99 3.1 Negotiation 101 L2TPHC is negotiated by an optional AVP ``L2TPHC-Protocol'' which 102 is placed in the SCCRQ/SCCRP tunnel establishment messages. The 103 effect of this AVP will never occur until L2TP reaches a state 104 where payload data may be forwarded within the session in the 105 tunnel. Additionally, each side intending to use L2TPHC MUST NOT 106 do so until it both sends and receives this AVP. Thus, unless 107 both sides support L2TPHC, the optional AVP will be ignored by one 108 side, and not sent to the other side, and L2TP will operate in its 109 regular mode. 111 Further sessions within an L2TPHC tunnel MUST NOT be initiated. 112 However, L2TPHC permits multiple tunnels if a second AVP, indicat- 113 ing a special Tunnel ID, is included immediately following L2TPHC- 114 Protocol AVP in the SCCRQ/SCCRP exchange. This optional AVP, 115 ``L2TPHC-Assigned-Tunnel-ID'', is ignored unless it is both sent 116 and received. In this case, the Value indicates the octet value 117 which will be included as the Tunnel ID within the L2TPHC header. 118 Note that this ID is used only in the L2TPHC header, and is a dis- 119 tinct value from the tunnel ID used in L2TP headers. 121 Since all control passes over the parallel L2TP tunnel correspond- 122 ing to the L2TPHC one, the L2TP tunnel is always the one explic- 123 itly terminated, and the associated L2TPHC tunnel is implicitly 124 terminated. 126 3.2 AVP Format 128 The AVP L2TPHC-Protocol is encoded as Vendor ID 9, Attribute is 129 the 16-bit quantity 1 (the ID 9 reflects Cisco Systems, the ini- 130 tial developer of this specification, and it SHOULD be changed to 131 0 and an official Attribute value chosen if this specification 132 advances on a standards track). The Value is a single octet, 133 encoding the IP protocol number to use for the exchange of pay- 134 load. The overall length of this AVP is thus 7. The IANA- 135 allocated L2TP protocol number is 115. The M, H, and "rsvd" bits 136 MUST all be set to 0. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |M|H| rsvd | 7 | 9 | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | 1 | 115 | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 146 The L2TPHC-Assigned-Tunnel-ID AVP MUST also be sent with the M, H, 147 and "rsvd" bits all set to 0. It MUST NOT be present except when 148 immediately following an L2TPHC-Protocol AVP. The Attribute is 149 the 16-bit value 2, encoded in network byte order. The single 150 octet Value is a Tunnel ID to be used in the L2TPHC encapsulation. 151 The overall length of this AVP is thus 7. If this AVP is both 152 sent and received, up to 256 parallel tunnels may be supported 153 between the peers, and all L2TPHC packets MUST include the I bit 154 (see below), and the Tunnel ID specified by the peer MUST be used 155 as the Tunnel ID in all packets sent to that peer for a given tun- 156 nel. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |M|H| rsvd | 7 | 9 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | 2 | Tunnel ID | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 4. Payload Exchange 168 If the L2TPHC AVP is sent to and received from the peer, PPP payload 169 packets may be sent to the peer's IP address as raw IP packets, with 170 the IP protocol number set as indicated from the peer. Note that it 171 is legal for each peer to have specified a different protocol number; 172 traffic is always sent to the number indicated in the peer's AVP. 173 Such payload may be sent any time it would have been legal to send 174 such payload over the regular UDP-based L2TP tunnel. Similarly, pay- 175 load over the UDP tunnel MUST always be accepted, even after payload 176 has flowed using the header compressed raw IP packet format. The 177 payload so exchanged is always associated with the tunnel on which 178 the AVP was received, and with the single session within that tunnel. 180 Each L2TPHC payload packet is encoded as: 182 0 1 2 3 183 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 |T|L|x|x|S|I|O|P| Tunnel ID | PPP packet... | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 x bits indicate reserved bit fields and MUST be set to 0. A packet 189 received with a reserved bit set to 1 MUST be silently discarded, 190 unless the bit is defined for an extension that is known to the 191 implementation. 193 The T bit MUST be set to 0, indicating payload. Control messages are 194 never sent over L2TPHC. 196 The L bit MUST be set to 0, indicating no length field. No length 197 field is ever present in L2TPHC. 199 The S bit MUST be set to 0, indicating no Nr/Ns fields. Control 200 packets are not passed via L2TPHC. If sequencing of data packets is 201 required, L2TPHC MUST NOT be used for those data packets. However, 202 it is legal for data traffic to be mixed, with order-sensitive pack- 203 ets using L2TP/UDP, and other data packets using L2TPHC. In this 204 situation, data packets passed using L2TPHC have no impact on L2TP 205 sequence numbers. 207 The I bit MUST be set to 1, and the Tunnel ID MUST be present, if the 208 L2TPHC-Assigned-Tunnel-ID AVP was both sent and received during tun- 209 nel setup. Otherwise I MUST be set to 0, and the Tunnel ID octet 210 MUST be omitted from the packet. 212 The O bit MUST be set to 0, indicating no offset field. Offsets are 213 never used in L2TPHC. 215 The P bit is the Priority bit, and serves the same function as the 216 bit of the same name in an L2TP packet. Priority packets MUST enjoy 217 priority over traffic queued on both the UDP tunnel as well as the 218 corresponding L2TPHC raw IP tunnel. 220 Therefore, an L2TPHC packet will have an L2TPHC header of at least 221 one octet, and optionally one additional octet if the I bit is set to 222 1. 224 5. Efficiency Considerations 226 Some rough calculations will illustrate the environments in which 227 L2TPHC may be beneficial. Overhead as a percentage of the carried 228 traffic will be calculated for a typical packet size involved in bulk 229 data transfer (700 bytes), and the canonical 64-byte ``small IP 230 packet''. Percentages will be rounded to the nearest whole number. 231 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 232 bytes, and an L2TP header of 8 bytes. 234 The worst case is a 64-byte packet carried within a UDP L2TP header. 235 The 64 bytes of payload is carried by an overall header of 36 bytes, 236 resulting in an overhead of 56%. With the larger payload size of 700 237 bytes, the header is amortized over many more bytes, reducing the 238 overhead to 5%. 240 With L2TPHC, the UDP header is absent and the L2TPHC header is 1 byte 241 for the most compact case. Overall size is thus one byte of L2TPHC 242 and 20 bytes of IP header. The small packet now suffers an overhead 243 of only 32%, and the larger packet 3%. 245 Percentage overhead does not represent all the considerations 246 involved in reducing overhead. The average modem connection is still 247 only 14,400 bits per second, which translates to a per-byte real-time 248 cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing 249 characters are not included in the modem-to-modem data transfer). 250 Thus, a savings of 16 bytes per packet can also be viewed as a reduc- 251 tion of almost 10 milliseconds of latency per packet. While this 252 latency is short enough to be unnoticeable by a human, it may impact 253 real-time protocols such as streaming audio or video. 255 Thus, L2TP Header Compression provides most of its benefits when car- 256 rying streams of small packets. In environments such as downloading 257 of graphic files, or where human interaction is intermingled with the 258 short packets, the benefits of L2TP Header Compression will probably 259 be undetectable. 261 6. Security Considerations 263 Because L2TPHC has no security facilities, it is critical that its 264 operation be reconciled with the security policy of its environment. 265 Since L2TPHC has no protocol header at all, it is trivial to spoof a 266 source IP address and inject malicious packets into an ongoing ses- 267 sion. There are several suitable techniques for controlling this 268 exposure. 270 In the simplest case, L2TPHC operates across a private network. For 271 instance, a remote user may dial into a private NAS located on this 272 network, and use L2TP (with or without L2TPHC) to cross an IP-only 273 portion of this network to establish a multi-protocol session con- 274 nected at a convenient point in the network. In this environment, no 275 additional security may be required, and L2TPHC would operate trust- 276 ing to the integrity of this private network. 278 If the weak protection of a difficult-to-guess protocol header is 279 deemed sufficient, expanded protocol overhead has clearly been deter- 280 mined to be acceptable, and L2TP over UDP can be used without L2TPHC. 282 If PPP encryption under ECP [RFC1968] is active, malicious PPP pack- 283 ets are trivially detected and discarded as they are received on the 284 raw IP port number. Similarly, if an IPsec session is protecting the 285 IP packets themselves, malicious packets will also be discarded. 286 Note that in both cases, an expanded header is implicit in these 287 security facilities, which will greatly reduce the overhead efficien- 288 cies gained by L2TPHC. For instance, an MD5 AH IPsec header will add 289 32 bytes to the packet. The 16 bytes saved by L2TPHC quickly 290 approaches statistical insignificance. 292 7. Acknowledgments 294 Thanks to Gurdeep Singh Pall of Microsoft for identifying and 295 describing scenarios in which L2TP header size become a concern, and 296 for help in designing the L2TPHC header. 298 Thanks to Bill Palter of Redback Networks and W. Mark Townsley of 299 Cisco Systems for help in reviewing this draft. 301 8. Contacts 303 Andrew J. Valencia 304 P.O. Box 2928 305 Vashon, WA 98070 306 vandys@zendo.com 308 9. References 310 [RFC2661] M. Townsley, ``Layer 2 Tunnel Protocol (L2TP)'', RFC 2661, 311 August 1999 313 [1] G. Zorn, ``RADIUS Attributes for Tunnel Protocol Support'', Internet 314 draft, August 1999 316 [RFC1968] G. Meyer, ``PPP Encryption Control Protocol (ECP)'', RFC 1968, 317 June 1996