idnits 2.17.1 draft-ietf-l2tpext-l2tphc-05.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 Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 4 instances of too long lines in the document, the longest one being 5 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 107: '...each side intending to use L2TPHC MUST...' RFC 2119 keyword, line 116: '...ividual PPP session MUST be identified...' RFC 2119 keyword, line 135: '... All AVP's MUST always be sent with ...' RFC 2119 keyword, line 139: '... Vendor ID 0 MUST be assigned when t...' RFC 2119 keyword, line 182: '... tunnel MUST always be accepted, eve...' 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 (January 2003) is 7773 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: 6 errors (**), 0 flaws (~~), 1 warning (==), 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 June 30, 2002 5 Expires January 2003 6 draft-ietf-l2tpext-l2tphc-05.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") [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 are 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. 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 0-byte "header" (i.e., 92 the header is absent). This would then be followed by a PPP frame 93 (whose PPP encapsulation is also made optional), all encapsulated 94 within a raw IP protocol header. These packets are exchanged in 95 parallel with the regular UDP-based L2TP tunnel which provides all 96 management and related functions. 98 3. Tunnel Establishment 100 3.1 Negotiation 102 L2TPHC is negotiated by an optional AVP "L2TPHC-No-Header" 103 which is placed in the ICRQ/ICRP and OCRQ/OCRP session 104 establishment messages. The effect of this AVP will never 105 occur until L2TP reaches a state where the session within the 106 tunnel is fully established (i.e., success indicated in the 107 ICCN/OCCN). Additionally, each side intending to use L2TPHC MUST 108 NOT do so unless it both sends and receives this AVP. Thus, 109 unless both sides support L2TPHC, the optional AVP (in the ICRQ or 110 OCRQ message) will be ignored by one side, and not sent (in the 111 corresponding ICRP or OCRP) to the other side, and L2TP will 112 operate in its regular mode. If this AVP is both sent and 113 received, then payload is sent with no L2TPHC header at all--the 114 PPP payload is carried directly within the IP packet. There can 115 be only a single tunnel and a single session using L2TPHC between 116 any two IP peers. Each individual PPP session MUST be identified 117 by its IP source/destination pair. 119 Another AVP, "L2TPHC-PPP-Protocol", may also be included 120 in the control message. If both sent and received, 121 its Value field indicates the PPP protocol number which 122 will be the single value carried in the payload of all PPP 123 packets, and the payload transmitted through L2TPHC will omit PPP 124 HDLC flags and control, as well as the one or two byte protocol 125 field. The receiving side would then have to recreate a suitable 126 PPP header and insert it onto received payload. 128 When L2TPHC is negotiated, all control messages are sent over 129 the L2TP tunnel with an L2TP header. If a default PPP protocol 130 number was also negotiated, all PPP packets with protocols 131 different than the default must also be sent with an L2TP header. 133 3.2 AVP Formats 135 All AVP's MUST always be sent with the M, H, and "rsvd" bits all set 136 to 0. All Attribute fields are 16-bit quantities in network byte 137 order. The Vendor ID of each is 9, reflecting Cisco Systems, the 138 initial developer of this extension. New Attribute values under 139 Vendor ID 0 MUST be assigned when this document advances on the 140 standards track. 142 0 1 2 3 143 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 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 |M|H| rsvd | 6 | 9 | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 | 1 | 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 L2TPHC-No-Header's Attribute is value 1. 151 There is no Value field. When L2TPHC-No-Header 152 is both sent and received, L2TPHC will directly encapsulate the 153 PPP payload without any L2TPHC header byte. 155 0 1 2 3 156 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 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 |M|H| rsvd | 8 | 9 | 159 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 | 2 | PPP Protocol | 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 L2TPHC-PPP-Protocol's Attribute is value 2. The Value field is 164 any legal PPP value for an NCP protocol. Note that all PPP 165 protocol values which can be sent in 8-bit format always have a 166 corresponding 16-bit format, and this 16-bit format is always the 167 one used in this AVP. This AVP can only follow an L2TPHC-No- 168 Header AVP, and indicates that PPP traffic carried over L2TPHC 169 will not only have no L2TPHC header, but will also have no PPP 170 address, control, or protocol fields. If necessary, these fields 171 will be reconstructed on the receiving L2TPHC peer side, with the 172 protocol value being always set to the Value indicated by this AVP. 174 4. Payload Exchange 176 If the L2TPHC-No-Header AVP is sent to and received from 177 the peer, PPP payload packets may be sent to the peer's IP address 178 as raw IP packets, with the IP protocol number set to 115 (the 179 IANA-assigned value for L2TP). Such payload may be sent any 180 time it would have been legal to send such payload over the 181 regular UDP-based L2TP tunnel. Similarly, payload over the UDP 182 tunnel MUST always be accepted, even after payload has flowed using 183 the header compressed raw IP packet format. The payload so exchanged 184 is always associated with the tunnel on which the AVP was received, 185 and with the single session within that tunnel. 187 An L2TPHC packet is encoded as: 189 0 1 190 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 ... 191 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...+ 192 | PPP packet... ...| 193 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+- ...+ 195 The PPP frame will consist of the usual PPP-over-HDLC address, con- 196 trol, and protocol fields. However, if the L2TPHC-PPP-Protocol AVP 197 has been sent and received, these fields are not present in the PPP 198 payload, and must be re-inserted by the receiving side, using the 199 protocol value indicated in the Value field of the 200 L2TPHC-PPP-Protocol AVP. 202 5. Efficiency Considerations 204 Some rough calculations will illustrate the environments in which 205 L2TPHC may be beneficial. Overhead as a percentage of the carried 206 traffic will be calculated for a typical packet size involved in bulk 207 data transfer (700 bytes), and the canonical 64-byte "small IP 208 packet". Percentages will be rounded to the nearest whole number. 209 Overhead is tallied for an IP header of 20 bytes, a UDP header of 8 210 bytes, an L2TP header of 8 bytes, and a PPP encapsulation of 4 bytes. 212 The worst case is a 64-byte packet carried within a UDP L2TP header. 213 The 64 bytes of payload is carried by an overall header of 40 bytes, 214 resulting in an overhead of 63%. With the larger payload size of 700 215 bytes, the header is amortized over many more bytes, reducing the 216 overhead to 6%. 218 With L2TPHC, the UDP and L2TP headers are absent, and the 4 bytes of 219 PPP encapsulation have been deleted. Overall size is thus 20 bytes 220 of IP header. The small packet now suffers an overhead of only 31%, 221 and the larger packet 3%. 223 Percentage overhead does not represent all the considerations 224 involved in reducing overhead. Consider a modem connection operating 225 at 14,400 bits per second, which translates to a per-byte real-time 226 cost of 0.6 milliseconds (14400 divided by 8 bits, as async framing 227 characters are not included in the modem-to-modem data transfer). A 228 savings of 16 bytes per packet can also be viewed as a reduction of 229 almost 10 milliseconds of latency per packet. While this latency is 230 short enough to be unnoticeable by a human, it may impact real-time 231 protocols such as streaming audio or video. 233 Thus, L2TP Header Compression provides most of its benefits when car- 234 rying streams of small packets. In environments such as downloading 235 of graphic files, or where human interaction is intermingled with the 236 short packets, the benefits of L2TP Header Compression will probably 237 be undetectable. 239 6. Security Considerations 241 Because L2TPHC has no security facilities, it is critical that its 242 operation be reconciled with the security policy of its environment. 243 Since L2TPHC may have no protocol header at all, it is trivial to 244 spoof a source IP address and inject malicious packets into an ongo- 245 ing session. There are several suitable techniques for controlling 246 this exposure. 248 In the simplest case, L2TPHC operates across a private network. For 249 instance, a remote user may dial into a private NAS located on this 250 network, and use L2TP (with or without L2TPHC) to cross an IP-only 251 portion of this network to establish a multi-protocol session con- 252 nected at a convenient point in the network. In this environment, no 253 additional security may be required, and L2TPHC would operate trust- 254 ing to the integrity of this private network. 256 If the weak protection of a difficult-to-guess protocol header is 257 deemed sufficient, expanded protocol overhead has clearly been deter- 258 mined to be acceptable, and L2TP over UDP can be used without L2TPHC. 260 If PPP encryption under ECP [RFC1968] is active, malicious PPP pack- 261 ets are trivially detected and discarded as they are received on the 262 raw IP port number. Similarly, if an IPsec session is protecting the 263 IP packets themselves, malicious packets will also be discarded. 264 Note that in both cases, an expanded header is implicit in these 265 security facilities, which will greatly reduce the overhead 266 efficiencies gained by L2TPHC. 268 7. IANA Considerations 270 Two new AVP's are defined in this paper: L2TPHC-No-Header and 271 L2TPHC-PPP-Protocol. The vendor ID of there AVP's should be 0. 272 An Attribute needs to be assigned to each of the two new AVP's 273 through IETF Consensus, as defined in [RFC2661] section 10.1 275 8. References 277 [RFC2661] M. Townsley, "Layer 2 Tunnel Protocol (L2TP)", RFC 2661, 278 August 1999 280 [RFC1968] G. Meyer, "PPP Encryption Control Protocol (ECP)", 281 RFC 1968, June 1996 283 9. Acknowledgments 285 Thanks to Gurdeep Singh Pall of Microsoft for identifying and 286 describing scenarios in which L2TP header size become a concern. 288 Thanks to Bill Palter of Redback Networks and W. Mark Townsley of 289 Cisco Systems for help in reviewing this draft. 291 10. Authors' Addresses 293 Andrew J. Valencia 294 P.O. Box 2928 295 Vashon, WA 98070 297 Email: vandys@zendo.com 299 Tmima Koren 300 Cisco Systems, Inc. 301 170 West Tasman Drive 302 San Jose, CA 95134-1706 303 United States 305 EMail: tmima@cisco.com