idnits 2.17.1 draft-ietf-l2tpext-l2tphc-04.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 8 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 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 109: '...each side intending to use L2TPHC MUST...' RFC 2119 keyword, line 143: '... All AVP's MUST always be sent with ...' RFC 2119 keyword, line 147: '... Vendor ID 0 MUST be assigned if thi...' RFC 2119 keyword, line 163: '... section 4) MUST be set to zero. ...' RFC 2119 keyword, line 165: '...on ID field. The I bit MUST be set to...' (6 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 335 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 (October 2001) is 8228 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. -------------------------------------------------------------------------------- 2 Network Working Group Andrew J. Valencia 3 Request for Comments: DRAFT 4 Category: Internet Draft 5 Title: draft-ietf-l2tpext-l2tphc-04.txt 6 Date: October 2001 8 L2TP Header Compression (``L2TPHC'') 10 Status of this Memo 12 This document is an Internet-Draft and is in full conformance with 13 all provisions of Section 10 of RFC2026. Internet-Drafts are working 14 documents of the Internet Engineering Task Force (IETF), its areas, 15 and its working groups. Note that other groups may also distribute 16 working documents as Internet-Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 Abstract 31 The Layer 2 Tunneling Protocol (``L2TP'') [RFC2661] defines a 32 mechanism for tunneling PPP sessions over arbitrary media. There 33 exists a class of specific media applications for which protocol 34 overhead may be optimized, and where such reduction results in 35 improved operation. This document describes the solution space 36 addressed, its underlying motivations, and the protocol modifications 37 required. The enhancement to the L2TP protocol is called L2TP Header 38 Compression, or ``L2TPHC''. 40 1. Introduction 42 L2TP [RFC2661] defines a general purpose mechanism for tunneling PPP 43 over various media. In most cases, the header overhead of the L2TP 44 tunnel is negligible. However, when L2TP operates over bandwidth 45 constrained networks such as dialup links or some classes of WAN 46 backhauls, any savings of bytes transmitted results in a substantial 47 efficiency gain. This effect is further amplified when streams of 48 small IP packets dominate the traffic (thus increasing the header- 49 to-payload ratio), as is common with multimedia and other types of 50 real-time data traffic. 52 2. Simplifying Assumptions 54 If several simplifying assumptions may be met, it is possible to 55 reduce the size of the L2TP encapsulation: 57 - The tunnel will not operate through a NAT interface 58 - The tunnel uses a single IP address for the life of the tunnel 59 - The tunnel's host uses only one public IP network interface 60 - There will be only one tunnel between the LAC and the LNS 61 - There might be only one session within a tunnel 62 - There might be only one protocol active on that session 63 - Alignment is not required 64 - Packet length is preserved by the IP header 66 Each of these simplifying assumptions directly relates to an L2TP 67 protocol header field's function. Because NAT functionality is not 68 needed, the UDP header is not required. Because the endpoints will 69 not change their source IP addresses (due to either changing IP 70 addresses, moving among IP egress points, or switching to a distinct 71 backup IP interface), the identity of the peer may be determined by 72 its source IP address, rather than the Tunnel ID. If there is only 73 one tunnel, it is trivial to determine the Tunnel ID. Because each 74 byte is a measurable component of overhead, it is better to send 75 fields on unaligned boundaries rather than ever pad. Because IP will 76 preserve the packet length end-to-end, there is no need to 77 communicate this in the header itself. 79 In addition, several operational considerations permit further 80 simplification: 82 - There is no need to optimize control packet overhead 83 - Version compatibility may be determined by control packets 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. 90 Thus, by choosing very reasonable simplifying assumptions, it is 91 possible to minimize the L2TP fields in the header of a payload 92 packet. The resulting protocol is a "header" which may be as short 93 as 0 bytes (i.e., the header is absent) or as long as 3 bytes. This 94 would then be followed by a PPP frame (whose PPP encapsulation is 95 also made optional), all encapsulated within a raw IP protocol 96 header. These packets are exchanged in parallel with the regular 97 UDP-based L2TP tunnel which provides all management and related 98 functions. 100 3. Tunnel Establishment 102 3.1 Negotiation 104 L2TPHC is negotiated by an optional AVP ``L2TPHC-Assigned- 105 Session-ID'' which is placed in the ICRQ/ICRP and OCRQ/OCRP 106 session establishment messages. The effect of this AVP will never 107 occur until L2TP reaches a state where the session within the 108 tunnel is fully established (i.e., success indicated in the 109 ICCN/OCCN). Additionally, each side intending to use L2TPHC MUST 110 NOT do so unless it both sends and receives this AVP. Thus, 111 unless both sides support L2TPHC, the optional AVP (in the ICRQ or 112 OCRQ message) will be ignored by one side, and not sent (in the 113 corresponding ICRP or OCRP) to the other side, and L2TP will 114 operate in its regular mode. 116 As L2TPHC does not provide a Tunnel ID, there can be only a single 117 tunnel using L2TPHC between any two IP peers (with multiple 118 sessions within, if needed). 120 Since all control messages are passed over the parallel L2TP 121 tunnel corresponding to the L2TPHC one, tunnel shutdown of the 122 L2TP session is always achieved by explicitly closing the L2TP 123 session; the associated L2TPHC session is implicitly terminated. 125 An optional AVP, ``L2TPHC-No-Header'', may be sent immediately 126 following the ``L2TPHC-Assigned-Session-ID'' AVP. It may only be 127 sent where the session ID length is 0, indicating a single 128 implicit session value of 0. If this AVP is both sent and 129 received, then payload is sent with no L2TPHC header at all--the 130 PPP payload is carried directly within the IP packet. 132 Another optional AVP, ``L2TPHC-PPP-Protocol'', may be sent 133 immediately following the ``L2TPHC-No-Header''. If both sent and 134 received, its Value field indicates the PPP protocol number which 135 will be the single value carried in the payload of all PPP 136 packets, and the payload transmitted through L2TPHC will omit PPP 137 HDLC flags and control, as well as the one or two byte protocol 138 field. The receiving side would then have to recreate a suitable 139 PPP header and insert it onto received payload. 141 3.2 AVP Formats 143 All AVP's MUST always be sent with the M, H, and "rsvd" bits all set 144 to 0. All Attribute fields are 16-bit quantities in network byte 145 order. The Vendor ID of each is 9, reflecting Cisco Systems, the 146 initial developer of this extension. New Attribute values under 147 Vendor ID 0 MUST be assigned if this document advances on the 148 standards track. 150 0 1 2 3 151 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 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |M|H| rsvd | (6, 7, or 8) | 9 | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | 1 | Session ID1 | Session ID2 | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 L2TPHC-Assigned-Session-ID's Attribute is value 1. The Value 159 field is set based on how session ID's will be used for this 160 L2TPHC client. If the Length field of the AVP is 6, the Value 161 field is not present, and the session ID value 0 is implicitly 162 used. The I and J bits of the payload packet (if present; see 163 section 4) MUST be set to zero. If the Length field is 7, then a 164 one-byte session ID is present in the AVP, and this is the value 165 to use in the L2TPHC session ID field. The I bit MUST be set to 166 one in the L2TPHC payload, and the J bit MUST be to zero. 167 Finally, the Length field may be 8, and a two-byte session ID is 168 contained in the Value field. L2TPHC payload MUST be sent with 169 both the I and J bits set to one. The two-byte Value is encoded 170 in network byte order. 172 Note that the Session ID value used in the L2TPHC session is 173 distinct from the value used in the corresponding L2TP session. 174 Also, a single session ID namespace applies to all sizes of this 175 AVP. Thus, the 6- byte variant (implying 0), the 7-byte variant 176 with Session ID1 set to 0, and the 8-byte variant with both 177 Session ID1 and ID2 set to 0 would all refer to the same session 178 ID. 180 0 1 2 3 181 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 182 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 183 |M|H| rsvd | 6 | 9 | 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | 2 | 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 188 L2TPHC-No-Header's Attribute is value 2. There is no Value field. 189 This AVP may only immediately follow the L2TPHC-Assigned-Session- 190 ID AVP, and only when L2TPHC-Assigned-Session-ID has specified a 191 Length of 6, indicating a session ID of 0. When L2TPHC-No-Header 192 is both sent and received, L2TPHC will directly encapsulate the 193 PPP payload without any L2TPHC header byte. Otherwise L2TPHC 194 payload will have a one-, two-, or three-byte encapsulation (see 195 section 4). 197 0 1 2 3 198 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 199 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 200 |M|H| rsvd | 8 | 9 | 201 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 202 | 3 | PPP Protocol | 203 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 204 L2TPHC-PPP-Protocol's Attribute is value 3. The Value field is 205 any legal PPP value for an NCP protocol. Note that all PPP 206 protocol values which can be sent in 8-bit format always have a 207 corresponding 16-bit format, and this 16-bit format is always the 208 one used in this AVP. This AVP can only follow an L2TPHC-No- 209 Header AVP, and indicates that PPP traffic carried over L2TPHC 210 will not only have no L2TPHC header, but will also have no PPP 211 address, control, or protocol fields. These fields will be 212 reconstructed on the receiving L2TPHC peer side, with the protocol 213 value being always set to the Value indicated by this AVP. 215 4. Payload Exchange 217 If the L2TPHC-Assigned-Session-ID AVP is sent to and received from 218 the peer, PPP payload packets may be sent to the peer's IP address as 219 raw IP packets, with the IP protocol number set to TBD (RFC editor: 220 please fill in an appropriate IANA-assigned value). Such payload may 221 be sent any time it would have been legal to send such payload over 222 the regular UDP-based L2TP tunnel. Similarly, payload over the UDP 223 tunnel MUST always be accepted, even after payload has flowed using 224 the header compressed raw IP packet format. The payload so exchanged 225 is always associated with the tunnel on which the AVP was received, 226 and with the session within that tunnel. 228 An L2TPHC packet is encoded in a variety of formats, with all fields 229 being optional. The maximal L2TPHC payload packet is encoded as: 231 0 1 2 3 232 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 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 |P|I|J|x|x|x|x|x| Session ID... | PPP packet... | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 The first byte is absent if the L2TPHC-No-Header AVP has been sent 238 and received. In this case, P, I, and J are all implicitly 0. 240 Otherwise, the P bit is the Priority bit, and serves the same 241 function as the bit of the same name in an L2TP packet. Priority 242 packets MUST enjoy priority over traffic queued on both the UDP 243 tunnel as well as the corresponding L2TPHC raw IP tunnel. The I and 244 J bits are set based on the Length of the Value portion of the 245 L2TPHC-Assigned-Session-ID AVP: 247 I J Session ID Length 248 0 0 0 249 1 0 1 250 1 1 2 252 x bits indicate reserved bit fields and MUST be set to 0. A packet 253 received with a reserved bit set to 1 MUST be silently discarded, 254 unless the bit is defined for an extension that is known to the 255 implementation. 257 Therefore, when L2TPHC's packets have this header (i.e., the L2TPHC- 258 No-Header AVP has not been sent and received), the L2TPHC header con- 259 sists of an initial octet, and optionally one or two additional 260 octets based on the setting of the I and J bits. Following this 261 header would be the PPP frame. 263 The PPP frame will consist of the usual PPP-over-HDLC address, con- 264 trol, and protocol fields. However, if the L2TPHC-PPP-Protocol AVP 265 has been sent and received, these fields are not present in the PPP 266 payload, and must be re-inserted by the receiving side, using the 267 protocol value indicated in the Value field of the L2TPHC-PPP- 268 Protocol AVP. 270 5. Efficiency Considerations 272 Some rough calculations will illustrate the environments in which 273 L2TPHC may be beneficial. Overhead as a percentage of the carried 274 traffic will be calculated for a typical packet size involved in bulk 275 data transfer (700 bytes), and the canonical 64-byte ``small IP 276 packet''. Percentages will be rounded to the nearest whole number. 277 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 278 bytes, an L2TP header of 8 bytes, and a PPP encapsulation of 4 bytes. 280 The worst case is a 64-byte packet carried within a UDP L2TP header. 281 The 64 bytes of payload is carried by an overall header of 40 bytes, 282 resulting in an overhead of 63%. With the larger payload size of 700 283 bytes, the header is amortized over many more bytes, reducing the 284 overhead to 6%. 286 With L2TPHC, the UDP header is absent, the L2TPHC header is 0 bytes 287 for the most compact case, and the 4 bytes of PPP encapsulation have 288 been deleted. Overall size is thus 20 bytes of IP header. The small 289 packet now suffers an overhead of only 31%, and the larger packet 3%. 291 Percentage overhead does not represent all the considerations 292 involved in reducing overhead. Consider a modem connection operating 293 at 14,400 bits per second, which translates to a per-byte real-time 294 cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing 295 characters are not included in the modem-to-modem data transfer). A 296 savings of 16 bytes per packet can also be viewed as a reduction of 297 almost 10 milliseconds of latency per packet. While this latency is 298 short enough to be unnoticeable by a human, it may impact real-time 299 protocols such as streaming audio or video. 301 Thus, L2TP Header Compression provides most of its benefits when car- 302 rying streams of small packets. In environments such as downloading 303 of graphic files, or where human interaction is intermingled with the 304 short packets, the benefits of L2TP Header Compression will probably 305 be undetectable. 307 6. Security Considerations 309 Because L2TPHC has no security facilities, it is critical that its 310 operation be reconciled with the security policy of its environment. 311 Since L2TPHC may have no protocol header at all, it is trivial to 312 spoof a source IP address and inject malicious packets into an ongo- 313 ing session. There are several suitable techniques for controlling 314 this exposure. 316 In the simplest case, L2TPHC operates across a private network. For 317 instance, a remote user may dial into a private NAS located on this 318 network, and use L2TP (with or without L2TPHC) to cross an IP-only 319 portion of this network to establish a multi-protocol session con- 320 nected at a convenient point in the network. In this environment, no 321 additional security may be required, and L2TPHC would operate trust- 322 ing to the integrity of this private network. 324 If the weak protection of a difficult-to-guess protocol header is 325 deemed sufficient, expanded protocol overhead has clearly been deter- 326 mined to be acceptable, and L2TP over UDP can be used without L2TPHC. 328 If PPP encryption under ECP [RFC1968] is active, malicious PPP pack- 329 ets are trivially detected and discarded as they are received on the 330 raw IP port number. Similarly, if an IPsec session is protecting the 331 IP packets themselves, malicious packets will also be discarded. 332 Note that in both cases, an expanded header is implicit in these 333 security facilities, which will greatly reduce the overhead efficien- 334 cies gained by L2TPHC. For instance, an MD5 AH IPsec header will add 335 32 bytes to the packet. The 20 bytes saved by L2TPHC quickly 336 approaches statistical insignificance. 338 7. Acknowledgments 340 Thanks to Gurdeep Singh Pall of Microsoft for identifying and 341 describing scenarios in which L2TP header size become a concern, and 342 for help in designing the L2TPHC header. 344 Thanks to Bill Palter of Redback Networks and W. Mark Townsley of 345 Cisco Systems for help in reviewing this draft. 347 8. Contacts 349 Andrew J. Valencia 350 P.O. Box 2928 351 Vashon, WA 98070 352 vandys@zendo.com 354 9. References 356 [RFC2661] M. Townsley, ``Layer 2 Tunnel Protocol (L2TP)'', RFC 2661, 357 August 1999 359 [RFC1968] G. Meyer, ``PPP Encryption Control Protocol (ECP)'', RFC 1968, 360 June 1996