idnits 2.17.1 draft-ietf-l2tpext-l2tphc-02.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 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: '...each side intending to use L2TPHC MUST...' RFC 2119 keyword, line 130: '...d-Session-ID AVP MUST always be sent w...' RFC 2119 keyword, line 134: '...ribute value under Vendor ID 0 MUST be...' RFC 2119 keyword, line 139: '...he payload packet (see section 4) MUST...' RFC 2119 keyword, line 142: '...ield. The I bit MUST be set to one in...' (11 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 (June 2000) is 8709 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) == Unused Reference: '1' is defined on line 313, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. '1' Summary: 9 errors (**), 0 flaws (~~), 5 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-02.txt 5 Date: June 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 20 material 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 31 mechanism for tunneling PPP sessions over arbitrary media. There 32 exists a class of specific media applications for which protocol 33 overhead may be optimized, and where such reduction results in 34 improved operation. This document describes the solution space 35 addressed, its underlying motivations, and the protocol modifications 36 required. The enhancement to the L2TP protocol is called L2TP Header 37 Compression, or ``L2TPHC''. 39 1. Introduction 41 L2TP [RFC2661] defines a general purpose mechanism for tunneling PPP 42 over various media. In most cases, the header overhead of the L2TP 43 tunnel is negligible. However, when L2TP operates over bandwidth 44 constrained networks such as dialup links or some classes of WAN 45 backhauls, any savings of bytes transmitted results in a substantial 46 efficiency gain. This effect is further amplified when streams of 47 small IP packets dominate the traffic (thus increasing the header- 48 to-payload ratio), as is common with multimedia and other types of 49 real-time data traffic. 51 2. Simplifying Assumptions 53 If several simplifying assumptions may be met, it is possible to 54 reduce the size of the L2TP encapsulation: 56 - The tunnel will not operate through a NAT interface 57 - The tunnel uses a single IP address for the life of the tunnel 58 - The tunnel's host uses only one public IP network interface 59 - There will be only one tunnel between the LAC and the LNS 60 - There might be only one session within a tunnel 61 - Alignment is not required 62 - Packet length is preserved by the IP header 64 Each of these simplifying assumptions directly relates to an L2TP 65 protocol header field's function. Because NAT functionality is not 66 needed, the UDP header is not required. Because the endpoints will 67 not change their source IP addresses (due to either changing IP 68 addresses, moving among IP egress points, or switching to a distinct 69 backup IP interface), the identity of the peer may be determined by 70 its source IP address, rather than the Tunnel ID. If there is only 71 one session within the tunnel, it is trivial to determine the Session 72 ID. Because each byte is a measurable component of overhead, it is 73 better to send fields on unaligned boundaries rather than ever pad. 74 Because IP will preserve the packet length end-to-end, there is no 75 need to communicate this in the header itself. 77 In addition, several operational considerations permit further 78 simplification: 80 - There is no need to optimize control packet overhead 81 - Version compatibility may be determined by control packets 83 The first two bytes of an L2TP payload header determined the presence 84 of further, optional, fields. It also contains a Version field, used 85 to detect compatible version operation. Realistically, these may all 86 be determined in advance of payload exchange. 88 Thus, by choosing very reasonable simplifying assumptions, it is 89 possible to minimize the L2TP fields in the header of a payload 90 packet. The resulting protocol is a one octet mandatory header, 91 possibly followed by one or two additional octets, followed by a PPP 92 frame, all encapsulated within a raw IP protocol header. These 93 packets are exchanged in parallel with the regular UDP-based L2TP 94 tunnel which provides all management and related functions. 96 3. Tunnel Establishment 98 3.1 Negotiation 100 L2TPHC is negotiated by an optional AVP ``L2TPHC-Assigned- 101 Session-ID'' which is placed in the ICRQ/ICRP and OCRQ/OCRP 102 session establishment messages. The effect of this AVP will never 103 occur until L2TP reaches a state where the session within the 104 tunnel is fully established (i.e., success indicated in the 105 ICCN/OCCN). Additionally, each side intending to use L2TPHC MUST 106 NOT do so unless it both sends and receives this AVP. Thus, 107 unless both sides support L2TPHC, the optional AVP (in the ICRQ or 108 OCRQ message) will be ignored by one side, and not sent (in the 109 corresponding ICRP or OCRP) to the other side, and L2TP will 110 operate in its regular mode. 112 As L2TPHC does not provide a Tunnel ID, there can be only a single 113 tunnel using L2TPHC between any two IP peers (with multiple 114 sessions within, if needed). 116 Since all control messages are passed over the parallel L2TP 117 tunnel corresponding to the L2TPHC one, tunnel shutdown of the 118 L2TP session is always achieved by explicitly closing the L2TP 119 session; the associated L2TPHC session is implicitly terminated. 121 3.2 AVP Format 122 0 1 2 3 123 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 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 |M|H| rsvd | (6, 7, or 8) | 9 | 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 | 1 | Session ID1 | Session ID2 | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 The L2TPHC-Assigned-Session-ID AVP MUST always be sent with the M, 131 H, and "rsvd" bits all set to 0. The Attribute is the 16-bit 132 value 1, encoded in network byte order. The Vendor ID is 9, 133 reflecting Cisco Systems, the initial developer of this 134 extension--a new Attribute value under Vendor ID 0 MUST be 135 assigned if this document advances on the standards track. The 136 Value field is set based on how session ID's will be used for this 137 L2TPHC client. If the Length field of the AVP is 6, the Value 138 field is not present, and the session ID value 0 is implicitly 139 used. The I and J bits of the payload packet (see section 4) MUST 140 be set to zero. If the Length field is 7, then a one-byte session 141 ID is present in the AVP, and this is the value to use in the 142 L2TPHC session ID field. The I bit MUST be set to one in the 143 L2TPHC payload, and the J bit MUST be to zero. Finally, the 144 Length field may be 8, and a two-byte session ID is contained in 145 the Value field. L2TPHC payload MUST be sent with both the I and 146 J bits set to one. The two-byte Value is encoded in network byte 147 order. 149 Note that the Session ID value used in the L2TPHC session is 150 distinct from the value used in the corresponding L2TP session. 151 Also, a single session ID namespace applies to all sizes of this 152 AVP. Thus, the 6- byte variant (implying 0), the 7-byte variant 153 with Session ID1 set to 0, and the 8-byte variant with both 154 Session ID1 and ID2 set to 0 all refer to the same session ID. 156 4. Payload Exchange 158 If the L2TPHC-Assigned-Session-ID AVP is sent to and received from 159 the peer, PPP payload packets may be sent to the peer's IP address as 160 raw IP packets, with the IP protocol number set to 115. Such payload 161 may be sent any time it would have been legal to send such payload 162 over the regular UDP-based L2TP tunnel. Similarly, payload over the 163 UDP tunnel MUST always be accepted, even after payload has flowed 164 using the header compressed raw IP packet format. The payload so 165 exchanged is always associated with the tunnel on which the AVP was 166 received, and with the session within that tunnel. 168 Each L2TPHC payload packet is encoded as: 170 0 1 2 3 171 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 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 |T|L|J|x|S|I|O|P| Session ID... | PPP packet... | 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 176 x bits indicate reserved bit fields and MUST be set to 0. A packet 177 received with a reserved bit set to 1 MUST be silently discarded, 178 unless the bit is defined for an extension that is known to the 179 implementation. 181 The T bit MUST be set to 0, indicating payload. Control messages are 182 never sent over L2TPHC. 184 The L bit MUST be set to 0, indicating no length field. No length 185 field is ever present in L2TPHC. 187 The S bit MUST be set to 0, indicating no Nr/Ns fields. Control 188 packets are not passed via L2TPHC. If sequencing of data packets is 189 required, L2TPHC MUST NOT be used for those data packets. However, 190 it is legal for data traffic to be mixed, with order-sensitive 191 packets using a sequenced data extension of L2TP/UDP, and other data 192 packets using L2TPHC. In this situation, data packets passed using 193 L2TPHC would have no impact on L2TP sequence numbers. 195 The I and J bits are set based on the Length of the Value portion of 196 the L2TPHC-Assigned-Session-ID AVP. For a Length of 6, neither I nor 197 J is set, and a Session ID of 0 is implicit. For a Length of 7, I is 198 set and J is not, and the one-byte Session ID is inserted between the 199 header bits and the PPP packet. For a Length of 8, both I and J are 200 set, and the two-byte Session ID is inserted between the header bits 201 and the PPP packet. 203 The O bit MUST be set to 0, indicating no offset field. Offsets are 204 never used in L2TPHC. 206 The P bit is the Priority bit, and serves the same function as the 207 bit of the same name in an L2TP packet. Priority packets MUST enjoy 208 priority over traffic queued on both the UDP tunnel as well as the 209 corresponding L2TPHC raw IP tunnel. 211 Therefore, an L2TPHC packet will have an L2TPHC header of at least 212 one octet, and optionally one or two additional octets based on the 213 setting of the I and J bits: 215 I J Header size (in bytes) 216 --- --- --- 217 0 0 1 218 1 0 2 219 1 1 3 221 Following this header would be the PPP frame. 223 5. Efficiency Considerations 225 Some rough calculations will illustrate the environments in which 226 L2TPHC may be beneficial. Overhead as a percentage of the carried 227 traffic will be calculated for a typical packet size involved in bulk 228 data transfer (700 bytes), and the canonical 64-byte ``small IP 229 packet''. Percentages will be rounded to the nearest whole number. 230 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 231 bytes, and an L2TP header of 8 bytes. 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 header is absent and the L2TPHC header is 1 byte 240 for the most compact case. Overall size is thus one byte of L2TPHC 241 and 20 bytes of IP header. The small packet now suffers an overhead 242 of only 32%, and the larger packet 3%. 244 Percentage overhead does not represent all the considerations 245 involved in reducing overhead. Consider a modem connection operating 246 at 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). A 249 savings of 16 bytes per packet can also be viewed as a reduction of 250 almost 10 milliseconds of latency per packet. While this latency is 251 short enough to be unnoticeable by a human, it may impact real-time 252 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 [RFC1968] is active, malicious PPP 283 packets are trivially detected and discarded as they are received on 284 the raw IP port number. Similarly, if an IPsec session is protecting 285 the 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 288 efficiencies gained by L2TPHC. For instance, an MD5 AH IPsec header 289 will add 32 bytes to the packet. The 16 bytes saved by L2TPHC 290 quickly 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