idnits 2.17.1 draft-ietf-l2tpext-l2tphc-03.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 ** 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 page length should not exceed 58 lines per page, but there was 2 longer pages, the longest (page 4) being 59 lines == It seems as if not all pages are separated by form feeds - found 0 form feeds but 8 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 2 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 108: '...each side intending to use L2TPHC MUST...' RFC 2119 keyword, line 142: '... All AVP's MUST always be sent with ...' RFC 2119 keyword, line 146: '... Vendor ID 0 MUST be assigned if thi...' RFC 2119 keyword, line 162: '... section 4) MUST be set to zero. ...' RFC 2119 keyword, line 164: '...on ID field. The I bit MUST be set to...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 333 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 (November 2000) is 8563 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) No issues found here. Summary: 10 errors (**), 0 flaws (~~), 4 warnings (==), 2 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-03.txt 5 Date: November 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 - There might be only one protocol active on that session 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 endpoints will 68 not change their source IP addresses (due to either changing IP 69 addresses, moving among IP egress points, or switching to a distinct 70 backup IP interface), the identity of the peer may be determined by 71 its source IP address, rather than the Tunnel ID. If there is only 72 one tunnel, it is trivial to determine the Tunnel ID. Because each 73 byte is a measurable component of overhead, it is better to send 74 fields on unaligned boundaries rather than ever pad. Because IP will 75 preserve the packet length end-to-end, there is no need to 76 communicate this in the header 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 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 90 possible to minimize the L2TP fields in the header of a payload 91 packet. The resulting protocol is a "header" which may be as short 92 as 0 bytes (i.e., the header is absent) or as long as 3 bytes. This 93 would then be followed by a PPP frame (whose PPP encapsulation is 94 also made optional), all encapsulated within a raw IP protocol 95 header. These packets are exchanged in parallel with the regular 96 UDP-based L2TP tunnel which provides all management and related 97 functions. 99 3. Tunnel Establishment 101 3.1 Negotiation 103 L2TPHC is negotiated by an optional AVP ``L2TPHC-Assigned- 104 Session-ID'' which is placed in the ICRQ/ICRP and OCRQ/OCRP 105 session establishment messages. The effect of this AVP will never 106 occur until L2TP reaches a state where the session within the 107 tunnel is fully established (i.e., success indicated in the 108 ICCN/OCCN). Additionally, each side intending to use L2TPHC MUST 109 NOT do so unless it both sends and receives this AVP. Thus, 110 unless both sides support L2TPHC, the optional AVP (in the ICRQ or 111 OCRQ message) will be ignored by one side, and not sent (in the 112 corresponding ICRP or OCRP) to the other side, and L2TP will 113 operate in its regular mode. 115 As L2TPHC does not provide a Tunnel ID, there can be only a single 116 tunnel using L2TPHC between any two IP peers (with multiple 117 sessions within, if needed). 119 Since all control messages are passed over the parallel L2TP 120 tunnel corresponding to the L2TPHC one, tunnel shutdown of the 121 L2TP session is always achieved by explicitly closing the L2TP 122 session; the associated L2TPHC session is implicitly terminated. 124 An optional AVP, ``L2TPHC-No-Header'', may be sent immediately 125 following the ``L2TPHC-Assigned-Session-ID'' AVP. It may only be 126 sent where the session ID length is 0, indicating a single 127 implicit session value of 0. If this AVP is both sent and 128 received, then payload is sent with no L2TPHC header at all--the 129 PPP payload is carried directly within the IP packet. 131 Another optional AVP, ``L2TPHC-PPP-Protocol'', may be sent 132 immediately following the ``L2TPHC-No-Header''. If both sent and 133 received, its Value field indicates the PPP protocol number which 134 will be the single value carried in the payload of all PPP 135 packets, and the payload transmitted through L2TPHC will omit PPP 136 HDLC flags and control, as well as the one or two byte protocol 137 field. The receiving side would then have to recreate a suitable 138 PPP header and insert it onto received payload. 140 3.2 AVP Formats 142 All AVP's MUST always be sent with the M, H, and "rsvd" bits all set 143 to 0. All Attribute fields are 16-bit quantities in network byte 144 order. The Vendor ID of each is 9, reflecting Cisco Systems, the 145 initial developer of this extension. New Attribute values under 146 Vendor ID 0 MUST be assigned if this document advances on the 147 standards track. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |M|H| rsvd | (6, 7, or 8) | 9 | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | 1 | Session ID1 | Session ID2 | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 157 L2TPHC-Assigned-Session-ID's Attribute is value 1. The Value 158 field is set based on how session ID's will be used for this 159 L2TPHC client. If the Length field of the AVP is 6, the Value 160 field is not present, and the session ID value 0 is implicitly 161 used. The I and J bits of the payload packet (if present; see 162 section 4) MUST be set to zero. If the Length field is 7, then a 163 one-byte session ID is present in the AVP, and this is the value 164 to use in the L2TPHC session ID field. The I bit MUST be set to 165 one in the L2TPHC payload, and the J bit MUST be to zero. 166 Finally, the Length field may be 8, and a two-byte session ID is 167 contained in the Value field. L2TPHC payload MUST be sent with 168 both the I and J bits set to one. The two-byte Value is encoded 169 in network byte order. 171 Note that the Session ID value used in the L2TPHC session is 172 distinct from the value used in the corresponding L2TP session. 173 Also, a single session ID namespace applies to all sizes of this 174 AVP. Thus, the 6- byte variant (implying 0), the 7-byte variant 175 with Session ID1 set to 0, and the 8-byte variant with both 176 Session ID1 and ID2 set to 0 would all refer to the same session 177 ID. 179 0 1 2 3 180 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 181 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 182 |M|H| rsvd | 6 | 9 | 183 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 184 | 2 | 185 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 L2TPHC-No-Header's Attribute is value 2. There is no Value field. 188 This AVP may only immediately follow the L2TPHC-Assigned-Session- 189 ID AVP, and only when L2TPHC-Assigned-Session-ID has specified a 190 Length of 6, indicating a session ID of 0. When L2TPHC-No-Header 191 is both sent and received, L2TPHC will directly encapsulate the 192 PPP payload without any L2TPHC header byte. Otherwise L2TPHC 193 payload will have a one-, two-, or three-byte encapsulation (see 194 section 4). 196 0 1 2 3 197 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 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 199 |M|H| rsvd | 8 | 9 | 200 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 201 | 3 | PPP Protocol | 202 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 203 L2TPHC-PPP-Protocol's Attribute is value 3. The Value field is 204 any legal PPP value for an NCP protocol. Note that all PPP 205 protocol values which can be sent in 8-bit format always have a 206 corresponding 16-bit format, and this 16-bit format is always the 207 one used in this AVP. This AVP can only follow an L2TPHC-No- 208 Header AVP, and indicates that PPP traffic carried over L2TPHC 209 will not only have no L2TPHC header, but will also have no PPP 210 address, control, or protocol fields. These fields will be 211 reconstructed on the receiving L2TPHC peer side, with the protocol 212 value being always set to the Value indicated by this AVP. 214 4. Payload Exchange 216 If the L2TPHC-Assigned-Session-ID AVP is sent to and received from 217 the peer, PPP payload packets may be sent to the peer's IP address as 218 raw IP packets, with the IP protocol number set to 115. Such payload 219 may be sent any time it would have been legal to send such payload 220 over the regular UDP-based L2TP tunnel. Similarly, payload over the 221 UDP tunnel MUST always be accepted, even after payload has flowed 222 using the header compressed raw IP packet format. The payload so 223 exchanged is always associated with the tunnel on which the AVP was 224 received, and with the session within that tunnel. 226 An L2TPHC packet is encoded in a variety of formats, with all fields 227 being optional. The maximal L2TPHC payload packet is encoded as: 229 0 1 2 3 230 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 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 |P|I|J|x|x|x|x|x| Session ID... | PPP packet... | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 The first byte is absent if the L2TPHC-No-Header AVP has been sent 236 and received. In this case, P, I, and J are all implicitly 0. 238 Otherwise, the P bit is the Priority bit, and serves the same 239 function as the bit of the same name in an L2TP packet. Priority 240 packets MUST enjoy priority over traffic queued on both the UDP 241 tunnel as well as the corresponding L2TPHC raw IP tunnel. The I and 242 J bits are set based on the Length of the Value portion of the 243 L2TPHC-Assigned-Session-ID AVP: 245 I J Session ID Length 246 0 0 0 247 1 0 1 248 1 1 2 250 x bits indicate reserved bit fields and MUST be set to 0. A packet 251 received with a reserved bit set to 1 MUST be silently discarded, 252 unless the bit is defined for an extension that is known to the 253 implementation. 255 Therefore, when L2TPHC's packets have this header (i.e., the L2TPHC- 256 No-Header AVP has not been sent and received), the L2TPHC header 257 consists of an initial octet, and optionally one or two additional 258 octets based on the setting of the I and J bits. Following this 259 header would be the PPP frame. 261 The PPP frame will consist of the usual PPP-over-HDLC address, con- 262 trol, and protocol fields. However, if the L2TPHC-PPP-Protocol AVP 263 has been sent and received, these fields are not present in the PPP 264 payload, and must be re-inserted by the receiving side, using the 265 protocol value indicated in the Value field of the L2TPHC-PPP- 266 Protocol AVP. 268 5. Efficiency Considerations 270 Some rough calculations will illustrate the environments in which 271 L2TPHC may be beneficial. Overhead as a percentage of the carried 272 traffic will be calculated for a typical packet size involved in bulk 273 data transfer (700 bytes), and the canonical 64-byte ``small IP 274 packet''. Percentages will be rounded to the nearest whole number. 275 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 276 bytes, an L2TP header of 8 bytes, and a PPP encapsulation of 4 bytes. 278 The worst case is a 64-byte packet carried within a UDP L2TP header. 279 The 64 bytes of payload is carried by an overall header of 40 bytes, 280 resulting in an overhead of 63%. With the larger payload size of 700 281 bytes, the header is amortized over many more bytes, reducing the 282 overhead to 6%. 284 With L2TPHC, the UDP header is absent, the L2TPHC header is 0 bytes 285 for the most compact case, and the 4 bytes of PPP encapsulation have 286 been deleted. Overall size is thus 20 bytes of IP header. The small 287 packet now suffers an overhead of only 31%, and the larger packet 3%. 289 Percentage overhead does not represent all the considerations 290 involved in reducing overhead. Consider a modem connection operating 291 at 14,400 bits per second, which translates to a per-byte real-time 292 cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing 293 characters are not included in the modem-to-modem data transfer). A 294 savings of 16 bytes per packet can also be viewed as a reduction of 295 almost 10 milliseconds of latency per packet. While this latency is 296 short enough to be unnoticeable by a human, it may impact real-time 297 protocols such as streaming audio or video. 299 Thus, L2TP Header Compression provides most of its benefits when car- 300 rying streams of small packets. In environments such as downloading 301 of graphic files, or where human interaction is intermingled with the 302 short packets, the benefits of L2TP Header Compression will probably 303 be undetectable. 305 6. Security Considerations 307 Because L2TPHC has no security facilities, it is critical that its 308 operation be reconciled with the security policy of its environment. 309 Since L2TPHC may have no protocol header at all, it is trivial to 310 spoof a source IP address and inject malicious packets into an ongo- 311 ing session. There are several suitable techniques for controlling 312 this exposure. 314 In the simplest case, L2TPHC operates across a private network. For 315 instance, a remote user may dial into a private NAS located on this 316 network, and use L2TP (with or without L2TPHC) to cross an IP-only 317 portion of this network to establish a multi-protocol session con- 318 nected at a convenient point in the network. In this environment, no 319 additional security may be required, and L2TPHC would operate trust- 320 ing to the integrity of this private network. 322 If the weak protection of a difficult-to-guess protocol header is 323 deemed sufficient, expanded protocol overhead has clearly been deter- 324 mined to be acceptable, and L2TP over UDP can be used without L2TPHC. 326 If PPP encryption under ECP [RFC1968] is active, malicious PPP pack- 327 ets are trivially detected and discarded as they are received on the 328 raw IP port number. Similarly, if an IPsec session is protecting the 329 IP packets themselves, malicious packets will also be discarded. 330 Note that in both cases, an expanded header is implicit in these 331 security facilities, which will greatly reduce the overhead efficien- 332 cies gained by L2TPHC. For instance, an MD5 AH IPsec header will add 333 32 bytes to the packet. The 20 bytes saved by L2TPHC quickly 334 approaches statistical insignificance. 336 7. Acknowledgments 338 Thanks to Gurdeep Singh Pall of Microsoft for identifying and 339 describing scenarios in which L2TP header size become a concern, and 340 for help in designing the L2TPHC header. 342 Thanks to Bill Palter of Redback Networks and W. Mark Townsley of 343 Cisco Systems for help in reviewing this draft. 345 8. Contacts 347 Andrew J. Valencia 348 P.O. Box 2928 349 Vashon, WA 98070 350 vandys@zendo.com 352 9. References 354 [RFC2661] M. Townsley, ``Layer 2 Tunnel Protocol (L2TP)'', RFC 2661, 355 August 1999 357 [RFC1968] G. Meyer, ``PPP Encryption Control Protocol (ECP)'', RFC 1968, 358 June 1996