idnits 2.17.1 draft-ietf-l2tpext-l2tphc-06.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == No 'Intended status' indicated for this document; assuming Proposed Standard == The page length should not exceed 58 lines per page, but there was 1 longer page, the longest (page 1) being 339 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 1 character 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 118: '...ion establishment, L2TP MUST fall back...' RFC 2119 keyword, line 123: '...he L2TPHC-No-Header AVP, this AVP MUST...' RFC 2119 keyword, line 134: '...control packets, MUST be sent over the...' RFC 2119 keyword, line 140: '... All AVP's MUST always be sent with ...' Miscellaneous warnings: ---------------------------------------------------------------------------- -- 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 2003) is 7614 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: 4 errors (**), 0 flaws (~~), 2 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 L2TPEXT Working Group Andrew J. Valencia 3 Internet Draft Tmima Koren 4 November 2, 2002 Cisco Systems 5 Expires June 2003 6 draft-ietf-l2tpext-l2tphc-06.txt 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") defined in RFC 2661 defines a 32 mechanism for tunneling PPP sessions over IP. 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 are met, it is possible to 55 reduce the size of the L2TP encapsulation over IP: 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 determine the presence 86 of further, optional, fields. It also contains a Version field, used 87 to detect compatible version operation. 89 In the presence of the simplying assumptions listed above, it is 90 possible to systematically minimize or eliminate the L2TP fields in 91 the header of an L2TP data message. For example, if one assumes that 92 there is no more than a single session between two L2TP peers, then 93 the session ID in the L2TP header becomes irrelevant and may be 94 eliminated. Further, if there is only one version of L2TP running on 95 a pair of L2TP nodes (or, specifically, IP addresses on two L2TP 96 nodes), then there is no need for a version field in each data 97 packet. 99 Each assumption translates to a piece of information that may be left 100 out of the header. This document describes the most extreme case 101 where the entire L2TP header and/or the entire PPP header is 102 eliminated, resulting in a zero-byte "header" for each of these. Data 103 packets which meet the simplifying assumptions are then sent and 104 received over what is effectively a parallel data channel for packets 105 with the ultra-compressed L2TP and PPP header. The uncompressed data 106 channel still exists over UDP/IP as defined in RFC 2661, and any 107 packets not meeting the simplifying assumptions may still be sent 108 over this channel. 110 3. Tunnel Establishment 112 3.1 Negotiation 114 In order for two L2TP peers to send and receive data packets with the 115 compressed L2TP header of zero octets, the "L2TPHC-No-Header" AVP 116 MUST be sent and received in the ICRQ/ICRP or OCRQ/OCRP exchange 117 during session setup. If either side did not send, or did not 118 receive, this AVP during session establishment, L2TP MUST fall back 119 to utilization of an uncompressed header format for its data. 121 A second AVP, "L2TPHC-PPP-Protocol," may also be included in the 122 ICRQ/ICRP and OCRQ/OCRP message exchange to allow compression of the 123 PPP framing fields. As with the L2TPHC-No-Header AVP, this AVP MUST 124 be sent and received by both L2TP endpoints in order to enable PPP 125 framing compression. 127 The Value of the L2TPHC-PPP-Protocol AVP contains a two octet PPP 128 protocol number which will be assumed to be the single protocol type 129 carried in the payload of all PPP packets carried by L2TPHC. This AVP 130 indicates that the payload transmitted through L2TPHC will also omit 131 PPP HDLC flags and control fields, in addition to the one or two byte 132 protocol field indicated by the value in the L2TPHC-PPP-Protocol AVP. 133 Any PPP packets with a protocol ID other than that indicated in this 134 AVP, including any LCP or NCP control packets, MUST be sent over the 135 uncompressed data channel with the entire L2TP over UDP/IP header 136 intact. 138 3.2 AVP Formats 140 All AVP's MUST always be sent with the M, H, and "rsvd" bits all set 141 to 0. All Attribute fields are 16-bit quantities in network byte 142 order. 144 0 1 2 3 145 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 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 |M|H| rsvd | 6 | 0 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 | TBD1 | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 L2TPHC-No-Header's Attribute is value TBD1. 153 There is no Value field. When L2TPHC-No-Header 154 is both sent and received, L2TPHC will directly encapsulate the 155 PPP payload without any L2TPHC header byte. 157 0 1 2 3 158 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 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 |M|H| rsvd | 8 | 0 | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 | TBD2 | PPP Protocol | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 L2TPHC-PPP-Protocol's Attribute is value TBD2. The Value field is any 166 legal PPP value for an NCP protocol. PPP allows some protocol types 167 to be expressed in a compressed, 8 bit, form. The value included in 168 this AVP is always the 16-bit form. This AVP indicates that PPP 169 traffic carried over L2TPHC will not only have no L2TPHC header, but 170 will also have no PPP address, control, or protocol fields. If 171 necessary, these fields will be reconstructed on the receiving L2TPHC 172 peer side, with the protocol value being always set to the Value 173 indicated by this AVP. 175 4. Payload Exchange 177 After the L2TPHC-No-Header AVP is sent to and received from the peer, 178 two data channels exist between the peers, one for compressed 179 packets, the other for non-compressed packets. PPP payload packets 180 may be sent to the peer's IP address over each of these two data 181 channels. The compressed packets are sent as raw IP packets, with the 182 IP protocol number set to 115 (the IANA-assigned value for L2TP). At 183 the same time non-compressed packets may be sent over the non- 184 compressed data channel as UDP-based L2TP packets. The payload so 185 exchanged is always associated with the tunnel on which the AVP was 186 received, and with the single session within that tunnel. 188 Note that the active L2TP control channel and associated Hello 189 messages are sent as non-compressed packets and hence indicate tunnel 190 endpoint reachability only for the non-compressed channel. 192 An L2TPHC packet is encoded as: 194 0 1 195 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 ... 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...+ 197 | PPP packet... ...| 198 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...+ 200 The PPP frame will consist of the usual PPP-over-HDLC address, con- 201 trol, and protocol fields. However, if the L2TPHC-PPP-Protocol AVP 202 has been sent and received, these fields are not present in the PPP 203 payload, and must be re-inserted by the receiving side, using the 204 protocol value indicated in the Value field of the 205 L2TPHC-PPP-Protocol AVP. 207 5. Efficiency Considerations 209 Some rough calculations will illustrate the environments in which 210 L2TPHC may be beneficial. Overhead as a percentage of the carried 211 traffic will be calculated for a typical packet size involved in bulk 212 data transfer (700 bytes), and the canonical 64-byte "small IP 213 packet". Percentages will be rounded to the nearest whole number. 214 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 215 bytes, an L2TP header of 8 bytes, and a PPP encapsulation of 4 bytes. 217 The worst case is a 64-byte packet carried within a UDP L2TP header. 218 The 64 bytes of payload is carried by an overall header of 40 bytes, 219 resulting in an overhead of 63%. With the larger payload size of 700 220 bytes, the header is amortized over many more bytes, reducing the 221 overhead to 6%. 223 With L2TPHC, the UDP and L2TP headers are absent, and the 4 bytes of 224 PPP encapsulation have been deleted. Overall size is thus 20 bytes 225 of IP header. The small packet now suffers an overhead of only 31%, 226 and the larger packet 3%. 228 Percentage overhead does not represent all the considerations 229 involved in reducing overhead. Consider a modem connection operating 230 at 14,400 bits per second, which translates to a per-byte real-time 231 cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing 232 characters are not included in the modem-to-modem data transfer). A 233 savings of 16 bytes per packet can also be viewed as a reduction of 234 almost 10 milliseconds of latency per packet. While this latency is 235 short enough to be unnoticeable by a human, it may impact real-time 236 protocols such as streaming audio or video. 238 Thus, L2TP Header Compression provides most of its benefits when car- 239 rying streams of small packets. In environments such as downloading 240 of graphic files, or where human interaction is intermingled with the 241 short packets, the benefits of L2TP Header Compression will probably 242 be undetectable. 244 6. Security Considerations 246 Because L2TPHC has no security facilities, it is critical that its 247 operation be reconciled with the security policy of its environment. 248 Since L2TPHC may have no protocol header at all, it is trivial to 249 spoof a source IP address and inject malicious packets into an ongo- 250 ing session. There are several suitable techniques for controlling 251 this exposure. 253 In the simplest case, L2TPHC operates across a private network. For 254 instance, a remote user may dial into a private NAS located on this 255 network, and use L2TP (with or without L2TPHC) to cross an IP-only 256 portion of this network to establish a multi-protocol session con- 257 nected at a convenient point in the network. In this environment, no 258 additional security may be required, and L2TPHC would operate trust- 259 ing to the integrity of this private network. 261 If the weak protection of a difficult-to-guess protocol header is 262 deemed sufficient, expanded protocol overhead has clearly been deter- 263 mined to be acceptable, and L2TP over UDP can be used without L2TPHC. 265 If PPP encryption under ECP [RFC1968] is active, malicious PPP pack- 266 ets are trivially detected and discarded as they are received on the 267 raw IP port number. Similarly, if an IPsec session is protecting the 268 IP packets themselves, malicious packets will also be discarded. 269 Note that in both cases, an expanded header is implicit in these 270 security facilities, which will greatly reduce the overhead 271 efficiencies gained by L2TPHC. 273 7. IANA Considerations 275 This protocol defines two new Control Message Attribute Value Pairs 276 (AVP's) in the IANA Layer Two Tunneling Protocol registry. As 277 defined in [RFC2661] section 10.1, assignment of new AVP's is through 278 IETF consensus. This document is intended to satisfy that 279 requirement. 281 The two new AVP's are: 283 TBD1 L2TPHC-No-Header 284 TBD2 L2TPHC-PPP-Protocol 286 No registry of values is required for either AVP. Since these are 287 IETF-adopted (not private) AVP's, the vendor ID field of the AVP 288 should be set to zero. 290 [Note to RFC Editor: Please replace all instances of TBD1 and TBD2 291 here and in Section 3.2 with the IANA-assigned values.] 293 8. References 295 Normative References 297 [RFC2661] M. Townsley, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, 298 August 1999 300 Informative References 302 [RFC1968] G. Meyer, "PPP Encryption Control Protocol (ECP)", 303 RFC 1968, June 1996 305 9. Acknowledgments 307 Many thanks to W. Mark Townsley of Cisco Systems for his 308 contributions in both the review and content of this document. 309 Thanks to Gurdeep Singh Pall of Microsoft for identifying and 310 describing scenarios in which L2TP header size become a concern. 311 Thanks to Stephen Casner of Packet Design and to Bill Palter of 312 Redback Networks for help in reviewing this document. 314 10. Authors' Addresses 316 Andrew J. Valencia 317 P.O. Box 2928 318 Vashon, WA 98070 320 Email: vandys@zendo.com 322 Tmima Koren 323 Cisco Systems, Inc. 324 170 West Tasman Drive 325 San Jose, CA 95134-1706 326 United States 328 EMail: tmima@cisco.com