idnits 2.17.1 draft-ietf-pppext-l2tphc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-25) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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 ** Missing expiration date. The document expiration date should appear on the first and last 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 document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 6 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 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 108: '... side intending to use L2TPHC MUST NOT...' RFC 2119 keyword, line 114: '...an L2TPHC tunnel MUST NOT be initiated...' RFC 2119 keyword, line 132: '...fication, and it SHOULD be changed to ...' RFC 2119 keyword, line 148: '... also marked optional. It MUST NOT be...' RFC 2119 keyword, line 154: '...l L2TPHC packets MUST include the T bi...' (7 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 289 has weird spacing: '... 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 (December 1997) is 9628 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' -- Possible downref: Non-RFC (?) normative reference: ref. '2' Summary: 12 errors (**), 0 flaws (~~), 4 warnings (==), 4 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Andrew J. Valencia 3 Request for Comments: DRAFT Cisco Systems 4 Category: Internet Draft 5 Title: draft-ietf-pppext-l2tphc-01.txt 6 Date: December 1997 8 L2TP Header Compression (``L2TPHC'') 10 Status of this Memo 12 This document is an Internet-Draft. 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 18 months. Internet-Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 26 munnari.oz.au. 28 Abstract 30 The Layer 2 Tunneling Protocol (``L2TP'') defines a mechanism for 31 tunneling PPP sessions over arbitrary media. There exists a class of 32 specific media and applications for which protocol overhead may be 33 optimized, and where such reduction results in improved operation. 34 This document describes the solution space addressed, its underlying 35 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 [1] defines a general purpose mechanism for tunneling PPP over 42 various media. By design, it insulates L2TP operation from the 43 details of the media over which it operates. A significant 44 application of L2TP has emerged, known as ``voluntary tunneling'' 45 [2]. In this environment, the L2TP tunnel runs from the dial-up 46 client itself, through a public IP infrastructure, and then 47 terminating at the target LNS. Because this mode of operation 48 results in the L2TP header traversing the slow, high-latency dial-up 49 link, each byte of tunnel overhead can have a measurable impact on 50 the operation of the carried protocols. 52 2. Simplifying Assumptions 54 Fortunately, several simplifying assumptions may be made in the 55 voluntary tunneling environment: 57 - The client will not operate through a NAT interface 58 - The client will not roam (i.e., change its IP address) 59 - The client has only one public IP network interface 60 - There will be only one tunnel between the client and its LNS 61 - There will be only one session within this 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 roaming or switching to a 69 distinct backup IP interface), the identity of the client may be 70 determined by its source IP address, rather than the Tunnel ID. 71 Because there is only one session within the tunnel, it is trivial to 72 determine the Session ID. Because each byte is a measurable 73 component of overhead, it is better to send fields on unaligned 74 boundaries rather than ever pad. Because IP will preserve the packet 75 length end-to-end, there is no need to communicate this in the header 76 itself. 78 In addition, several operational considerations permit further 79 simplification: 81 - There is no need to optimize control packet overhead 82 - Version compatibility may be determined by control packets 83 - Rate pacing may be determined outside the main payload exchange 85 The first two bytes of an L2TP payload header determined the presence 86 of further, optional, fields. It also contains a Version field, used 87 to detect compatible version operation. Realistically, these may all 88 be determined in advance of payload exchange. Similarly, the 89 optional rate pacing of L2TP could determined outside of the core 90 payload packet path, or the Priority bit facility could be used 91 instead. 93 Thus, by choosing very reasonable simplifying assumptions, it is 94 possible to minimize the L2TP fields from the header of a payload 95 packet. The resulting protocol is a one octet mandatory header, 96 followed by 0, 1, or 2 additional octets, followed by PPP frames, all 97 encapsulated within a raw IP protocol header. These packets are 98 exchanged in parallel with the regular UDP-based L2TP tunnel which 99 provides all management and related functions. 101 3. Tunnel Establishment 103 3.1 Negotiation 104 L2TPHC is negotiated by an optional AVP ``L2TPHC-Proto'' which is 105 placed in the SCCRQ/SCCRP tunnel establishment messages. The 106 effect of this AVP will never occur until L2TP reaches a state 107 where payload data may be forwarded within the session in the 108 tunnel. Additionally, each side intending to use L2TPHC MUST NOT 109 do so until it both sends and receives this AVP. Thus, unless 110 both sides support L2TPHC, the optional AVP will be ignored by one 111 side, and not sent to the other side, and L2TP will operate in its 112 regular mode. 114 Further sessions within an L2TPHC tunnel MUST NOT be initiated. 115 However, L2TPHC permits multiple tunnels if a second AVP, 116 indicating a special Tunnel ID, is included immediately following 117 L2TPHC-Proto AVP in the SCCRQ/SCCRP exchange. This optional AVP, 118 ``L2TPHC-Tunnel'', is ignored unless it is both sent and received. 119 In this case, the Value indicates the octet value which will be 120 included as the Tunnel ID within the L2TPHC header. 122 Once the tunnel associated with a given L2TPHC context has been 123 terminated, the L2TPHC context is considered free, and may be used 124 in future L2TP connections. Because all control passes over the 125 parallel L2TP session corresponding to the L2TPHC one, the L2TP 126 tunnel terminates, and the L2TPHC tunnel is implicitly terminated. 128 3.2 AVP Format 130 The AVP L2TPHC-Proto is encoded as Vendor ID 9, Attribute is the 131 16-bit quantity 0 (the ID 9 reflects Cisco Systems, the initial 132 developer of this specification, and it SHOULD be changed to 0 and 133 an official Attribute value chosen if this specification advances 134 on a standards track). The Value is a single octet, encoding the 135 IP protocol number to use for the exchange of payload. Unless and 136 until an official protocol number is allocated, the value 251 is 137 recommended. The AVP is marked optional, permitting 138 interoperability with peers not implementing L2TPHC. 140 0 1 2 3 141 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 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 |0|0|0|0| 7 | 9 | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | 0 | 251 | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 The L2TPHC-Tunnel AVP is also marked optional. It MUST NOT be 149 present except when immediately following an L2TPHC-Proto AVP. 150 The Attribute is the 16-bit value 1, encoded in network byte 151 order. The single octet Value is a Tunnel ID to be used in the 152 L2TPHC encapsulation. If this AVP is both sent and received, up 153 to 256 parallel tunnels may be supported between the peers, and 154 all L2TPHC packets MUST include the T bit, and the Tunnel ID 155 specified by the peer MUST be used as the Tunnel ID in all packets 156 sent to that peer for a given tunnel. 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 |0|0|0|0| 7 | 9 | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | 1 | 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 sent is always 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, 175 payload over the UDP tunnel MUST always be accepted, even after 176 payload has flowed using the header compressed raw IP packet format. 177 The payload so exchanged is always associated with the tunnel on 178 which the AVP was received, and with the single session within that 179 tunnel. 181 Each L2TPHC payload packet is encoded as: 183 0 1 2 3 184 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 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 186 |F|I|P|0|0|0|0|0| Nr | Ns | Tunnel ID | 187 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 | PPP packet... | 189 +-+-+-+-+-+-+-+-+ 191 The Nr/Ns fields MUST be present if the F bit is 1, otherwise they 192 MUST be omitted. Their use is identical to that of the fields of the 193 same name in L2TP payload packets, except that their numerical range 194 is only 8 bits, rather than 16 in L2TP. A regular L2TP tunnel MUST 195 be used in any situation where the speed of a link and the latency of 196 the path result in more packets outstanding than can be accounted 197 with a byte numbering space. 199 The I bit MUST be set, and the Tunnel ID MUST be present, if the 200 L2TPHC-Tunnel AVP was both sent and received during tunnel setup. 201 Otherwise I must be sent 0, and the Tunnel ID octet omitted from the 202 packet. 204 The P bit is the Priority bit, and serves the same function as the 205 bit of the same name in an L2TP packet. Priority packets MUST enjoy 206 priority over traffic queued on both the UDP tunnel as well as the 207 corresponding L2TPHC raw IP tunnel. 209 Therefore, an L2TPHC packet will have an L2TPHC header of at least 210 one octet, with up to three more octets as indicated by the flags in 211 this first octet. 213 Since packet flow over this raw IP tunnel is distinct from the UDP 214 based tunnel, it is possible that an asymmetry in the path (for 215 instance, the unintentional presence of a NAT device) may disrupt one 216 but not the other. It is recommended that at least during the time 217 immediately following establishment of the session, that LCP echoes 218 be used in tandem with the L2TP keepalive function so that 219 connectivity of both paths may be verified. 221 5. Efficiency Considerations 223 Some rough calculations will illustrate the environments in which 224 L2TPHC may be beneficial. Overhead as a percentage of the carried 225 traffic will be calculated for a typical packet size involved in bulk 226 data transfer (700 bytes), and the canonical 64-byte ``small IP 227 packet''. Percentages will be rounded to the nearest whole number. 228 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 229 bytes, and an L2TP header of 8 bytes (4 bytes of rate pacing with the 230 Nr/Ns fields will probably be avoided in favor of the more compact 231 though less comprehensive Priority header bit). 233 The worst case is a 64-byte packet carried within a UDP L2TP header. 234 The 64 bytes of payload is carried by an overall header of 36 bytes, 235 resulting in an overhead of 56%. With the larger payload size of 700 236 bytes, the header is amortized over many more bytes, reducing the 237 overhead to 5%. 239 With L2TPHC, the UDP is absent and the L2TPHC header is 1 byte for 240 the most compact case. Overall size is thus one byte of L2TPHC and 241 20 bytes of IP header. The small packet now suffers an overhead of 242 only 32%, and the larger packet 3%. 244 Percentage overhead does not represent all the considerations 245 involved in reducing overhead. The average modem connection is still 246 only 14,400 bits per second, which translates to a per-byte real-time 247 cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing 248 characters are not included in the modem-to-modem data transfer). 249 Thus, a savings of 16 bytes per packet can also be viewed as a 250 reduction of almost 10 milliseconds of latency per packet. While 251 this latency is short enough to be unnoticeable by a human, it may 252 impact real-time protocols such as streaming audio or video. 254 Thus, L2TP Header Compression provides most of its benefits when 255 carrying streams of small packets. In environments such as 256 downloading of graphic files, or where human interaction is 257 intermingled with the short packets, the benefits of L2TP Header 258 Compression will probably be undetectable. 260 6. Security Considerations 262 Because L2TPHC has no security facilities, it is critical that its 263 operation be reconciled with the security policy of its environment. 264 Since L2TPHC has no protocol header at all, it is trivial to spoof a 265 source IP address and inject malicious packets into an ongoing 266 session. There are several suitable techniques for controlling this 267 exposure. 269 In the simplest case, L2TPHC operates across a private network. For 270 instance, a remote user may dial into a private NAS located on this 271 network, and use L2TP (with or without L2TPHC) to cross an IP-only 272 portion of this network to establish a multi-protocol session 273 connected at a convenient point in the network. In this environment, 274 no additional security may be required, and L2TPHC would operate 275 trusting to the integrity of this private network. 277 If the weak protection of a difficult-to-guess protocol header is 278 deemed sufficient, expanded protocol overhead has clearly been 279 determined to be acceptable, and L2TP over UDP can be used without 280 L2TPHC. 282 If PPP encryption under ECP [3] is active, malicious PPP packets are 283 trivially detected and discarded as they are received on the raw IP 284 port number. Similarly, if an IPsec session is protecting the IP 285 packets themselves, malicious packets will also be discarded. Note 286 that in both cases, an expanded header is implicit in these security 287 facilities, which will greatly reduce the overhead efficiencies 288 gained by L2TPHC. For instance, an MD5 AH IPsec header will add 32 289 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 and W. Mark Townsley of Cisco Systems for help 299 in reviewing this draft. 301 8. Contacts 303 Andrew J. Valencia 304 Cisco Systems 305 170 West Tasman Drive 306 San Jose CA 95134-1706 307 vandys@cisco.com 309 9. References 311 [1] A. Valencia, ``Layer 2 Tunnel Protocol (L2TP)'', Internet Draft, 312 October 1997 314 [2] G. Zorn, ``RADIUS Attributes for Tunnel Protocol Support'', Internet 315 draft, July 1997 317 [3] G. Meyer, ``PPP Encryption Control Protocol (ECP)'', RFC 1968