idnits 2.17.1 draft-ietf-pppext-l2tpmtu-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** 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 document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. 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 separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** 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 113: '... o MUST, SHALL, or MANDATORY --...' RFC 2119 keyword, line 116: '... o SHOULD or RECOMMEND -- This ...' RFC 2119 keyword, line 119: '... o MAY or OPTIONAL -- This item...' RFC 2119 keyword, line 370: '...the L2TP control MUST tear down a tunn...' RFC 2119 keyword, line 399: '... messages MUST only be sent if both ...' (107 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If both L2TP endpoint did not both previously advertise support for the L2TP PMTU Discovery Channel, the LSPMTU-Explore-Request MUST not be sent, and the LSPMTU-Explore-Reply MUST not be sent. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An L2TP endpoint that previously advertised support for the L2TP Discovery Channel MUST reply to each LSPMTUExRQ received by sending an LSPMTUExRP. Over IPv4 the LSPMTUExRP MUST not be sent with the DF bit set in the encapsulating IPv4 header. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The Assigned Call ID encodes the ID being assigned to the L2TP PMTU Discovery channel used solely for the exchange of LRPMTUExRQ and LRPMTUExRP messages. A value of 0 indicates that the L2TP peer will not support the LRPMTUExRQ and LRPMTUExRP messages. This call ID MUST be used for the L2TP PMTU Discovery Channel if both L2TP peers send the MTUCAP AVP with nonzero Assigned Call ID values. LRPMTUExRQ (and hence LRPMTURxRP) messages MUST not be sent on any advertised Call ID unless both peers have sent nonzero Assigned Call ID values in their most recently send MTUCAP AVPs. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: The SCCCN MTUCAP AVP MUST not differ from the SCCRQ MTUCAP AVP previously sent, except for the Assigned Call ID and SPMTU values. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If running L2TP-over-IPv6, the PMTU Discovery channel MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If both tunnel endpoints had values of one (1) for both IPv4 TS and IPv6 TS the PMTU Discovery Channel MUST not be used. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any IPv4 datagram which is equal to 68 bytes in length MUST not be checked against the LSPMTU for the L2TP tunnel. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the IPv4 datagram header DF bit is set, the LSPMTU for the tunnel is checked. If the check is done before any stateful compression or encryption and the IPv4 datagram is larger than the LSPMTU then the IPv4 datagram MUST be dropped. If the check is done after any stateful compression or encryption and the IPv4 datagram after any compression is larger than the LSPMTU then the IPv4 datagram SHOULD not be dropped. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For L2TP-over-IPv4 when the size of the IPv4 packet being encapsulated is equal to 68 (minimum IPv4 MTU as specified in [6]), the DF bit in the encapsulating IPv4 header MUST not be set. For L2TP-over-IPv4 when the size of the IPv4 packet being encapsulated is greater than 68 and the DF bit is set, the DF bit MUST be set in the encapsulating IPv4 header as well. When the DF bit is not set in the IPv4 packet being encapsulated, the DF bit MUST not be set in the IPv4 packet encapsulating the L2TP payload. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Any IPv6 datagram which is equal to 576 bytes in length MUST not be checked against the LSPMTU for the L2TP tunnel. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: If the IPv6 datagram size is larger than the LSPMTU and the check is done before any stateful compression or encryption then the IPv6 datagram MUST be dropped. If the check is done after any stateful compression or encryption and the IPv6 datagram after any compression is larger than the LSPMTU then the IPv6 datagram SHOULD not be dropped. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: For L2TP-over-IPv4 when the size of the IPv6 packet being encapsulated is equal to 576 (minimum IPv6 MTU as specified in [5]), the DF bit in the encapsulating IPv4 header MUST not be set. For L2TP-over-IPv4 when the size of the IPv6 packet being encapsulated is greater than 576 the DF bit MUST be set in the encapsulating IPv4 header as well. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An implementation capable of being an IPv4 Transparent Receiver MUST not perform the actions put forth in this section if an MTUCAP AVP was received with the IPv4 TS set to one (1). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An implementation capable of being an IPv6 Transparent Receiver MUST not perform the actions put forth in this section if an MTUCAP AVP was received with the IPv6 TS set to one (1). == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an L2TP endpoint discovers that it does not have an accurate value for LRPMTU it enters LRPMTU discovery mode (if not already in LRPMTU discovery mode). Entering LRPMTU discovery mode prompts the sending of an LRPMTUExRQ to the peer. LRPMTUExRQ messages MUST not be sent to the peer if an LRPMTUExRQ was sent and no LRPMTUExRP was received. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: An L2TP endpoint MUST not update its SPMTU (and hence its LSPMTU) value based on ICMP Datagram Too Big messages received containing a PMTU value larger than the current SPMTU. This will prevent the possibility of the second attack above where a malicious party sends these messages with a PMTU which is larger than the true PMTU for the path. == 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 (January 1998) is 9591 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) -- Possible downref: Non-RFC (?) normative reference: ref. '2' == Outdated reference: A later version (-16) exists of draft-ietf-pppext-l2tp-08 ** Obsolete normative reference: RFC 1885 (ref. '4') (Obsoleted by RFC 2463) ** Obsolete normative reference: RFC 1883 (ref. '5') (Obsoleted by RFC 2460) Summary: 11 errors (**), 0 flaws (~~), 18 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PPP Working Group Richard Shea 3 INTERNET DRAFT New Oak Communications 4 Category: Internet Draft 5 Title: draft-ietf-pppext-l2tpmtu-00.txt 6 Date: January 1998 8 L2TP-over-IP Path MTU Discovery (''L2TPMTU'') 10 Status of this Memo 12 This document is an Internet-Draft. 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 18 months. Internet-Drafts may be updated, replaced, or obsoleted by 19 other documents at any time. It is not appropriate to use Internet- 20 Drafts as reference material or to cite them other than as a 21 ``working draft'' or ``work in progress.'' 23 To learn the current status of any Internet-Draft, please check the 24 1id-abstracts.txt listing contained in the Internet-Drafts Shadow 25 Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or 26 munnari.oz.au. 28 Abstract 30 The Layer Two Tunneling Protocol (L2TP) defines a mechanism for 31 tunneling PPP over arbitrary media. When IPv4 or IPv6 over PPP is 32 tunneled over L2TP, it is desirable to avoid fragmentation of the 33 L2TP data channel packets when L2TP is run over IP. This document 34 describes a mechanism for L2TP-over-IP to avoid fragmentation of 35 tunneled IPv4 and IPv6 datagrams by leveraging IPv4 and IPv6 path 36 MTU discovery mechanisms. 38 Table of Contents 40 1. Introduction 41 1.1 Conventions 42 1.2 Terminology 43 2. Protocol Overview 44 2.1 Transparent Tunnel Sender 45 2.1.1 L2TP-over-IPv4 46 2.1.2 L2TP-over-IPv6 47 2.2 Transparent Tunnel Receiver 48 2.2.1 L2TP-over-IPv4 49 2.2.2 L2TP-over-IPv6 50 2.3 Opaque Tunnel Sender 51 2.4 Opaque Tunnel Receiver 52 2.5 PMTU Discovery Channel 53 3. Protocol Additions 54 3.1 Control Channel Messages 55 3.1.1 LRPMTU-Request (LRPMTURQ) 56 3.1.2 LRMPTU-Reply (LRPMTURP) 57 3.2 L2TP PMTU Discovery Channel Messages 58 3.2.1 LSPMTU-Explore-Request (LSPMTUExRQ) 59 3.2.2 LSPMTU-Explore-Reply (LSPMTUExRP) 60 3.3 L2TP PMTU Discovery Capabilities AVP (MTUCAP) 61 4. Protocol Operation 62 4.1 Tunnel Establishment 63 4.1.1 SCCRQ Sender 64 4.1.2 SCCRP Sender 65 4.1.3 SCCCN Sender 66 4.1.4 PMTU Discovery Channel Requirements 67 4.2 Packet Handling 68 4.2.1 Transparent Sender Actions 69 4.2.1.1 IPv4 Transparent Sender 70 4.2.1.2 IPv6 Transparent Sender 71 4.2.2 Transparent Receiver Actions 72 4.2.2.1 IPv4 Transparent Receiver 73 4.2.2.2 IPv6 Transparent Receiver 74 4.2.2.3 LRPMTU Discovery 75 4.3 SPMTU Discovery 76 4.3.1 SPMTU Discovery over IPv4 77 4.3.2 SPMTU Discovery over IPv6 78 5. Security Considerations 79 References 80 Author's Address 82 1. Introduction 84 Both version 4 of the Internet Protocol (IPv4) and version 6 of the 85 Internet Protocol (IPv6) define mechanisms for path MTU discovery 86 in order to avoid fragmentation of IP datagrams. Document [1] 87 describes a mechanism for avoiding fragmentation of IPv4 datagrams 88 by using the IPv4 header "Don't Fragment" (DF) bit. The IPv6 89 protocol itself defines a similar (mandatory) mechanism for path 90 MTU discovery in IPv6 networks. The reasons for avoiding 91 fragmentation have been explored in [2]. 93 When L2TP is run over IP, fragmentation of the tunneled IP 94 datagrams may occur due to the Path MTU between the L2TP peers and 95 especially given the fact that extra byte overhead has been added 96 to the original IP-in-PPP datagram so that it may be tunneled. In 97 this case, any IP flows being tunneled with fragmentation happening 98 to the L2TP data packets inherit the bad qualities of IP 99 fragmentation as if the fragmentation were happening to the IP flow 100 directly. 102 In order to avoid IP fragmentation of IP flows being tunneled by 103 L2TP, a mechanism is needed so that Path MTU discovery between L2TP 104 tunnel endpoints is done, and the adjusted path MTU for tunneled IP 105 flows is communicated to the IP hosts whose traffic is being 106 tunneled. 108 1.1 Conventions 110 The following language conventions are used in the items of 111 specification in this document: 113 o MUST, SHALL, or MANDATORY -- This item is an absolute 114 requirement of the specification. 116 o SHOULD or RECOMMEND -- This item should generally be followed 117 for all but exceptional circumstances. 119 o MAY or OPTIONAL -- This item is truly optional and may be 120 followed or ignored according to the needs of the implementor. 122 1.2 Terminology 124 This draft currently assumes the reader is knowledgable about terms 125 found in [3]. In addition, the following terms are used 126 in this document: 128 MTU 130 The maximum size of an IP datagram such that it will not need to 131 be fragmented. The term MTU is meant to mean the first-hop MTU, 132 while Path MTU is used to mean the MTU along all hops along an 133 IP path. 135 PMTU 137 Path MTU (Maximum Transmission Unit). The maximum size of an IP 138 datagram between two IP hosts (i.e. along a path) that will not 139 result in IP fragmentation. This value is necessarily equal to 140 the smallest single-hop MTU along the path. 142 SPMTU 144 Send Path MTU. From the point of view of an IP host, the 145 maximum size of an IP datagram to another IP host that will not 146 result in IP fragmentation along the path to the peer IP host. 148 RPMTU 150 Receive Path MTU. From the point of view of an IP host, the 151 maximum size of an IP datagram that another IP host can send to 152 it which will not be received having been fragmented. 154 LSPMTU 156 L2TP SPMTU. The SPMTU as seen by IP flows being tunneled with 157 L2TP, from the point of view of the L2TP endpoint sending the 158 traffic. This value is essentially the SPMTU between two L2TP 159 tunnel endpoints subtracted by the maximum tunneling overhead 160 possible in the sending direction. The LSPMTU of one L2TP peer 161 is equal to the LRPMTU of the other peer. 163 LRPMTU 165 L2TP RPMTU. The RPMTU as seen by IP flows being tunneled with 166 L2TP, from the point of view of the L2TP endpoint receiving the 167 traffic. This value is essentially the RPMTU between two L2TP 168 tunnel endpoints subtracted by the maximum tunneling overhead 169 possible in the receiving direction. The LRPMTU of one L2TP 170 peer is equal to the LSPMTU of the other peer. 172 PMTU Discovery Channel 174 An optional L2TP channel used to send messages between peers in 175 order to discover PMTUs between an LAC and an LNS. 177 Opaque Tunnel Receiver 179 An L2TP tunnel endpoint that cannot access the IP-in-PPP packets 180 which its peer L2TP endpoint is sending to it. This is most 181 common for an LAC, where the PPP endpoint is not typically 182 co-located in the same software system. In this case the PPP 183 packets may be compressed or encrypted, making it impossible (or 184 infeasible) to recover the original IP datagram. Since PPP 185 options are uni-directional, it is possible to be an Opaque 186 Tunnel Receiver, but a Transparent Tunnel Sender. 188 Transparent Tunnel Receiver 190 An L2TP tunnel endpoint that can access the IP-in-PPP packets 191 which its peer L2TP endpoint is sending to it. This is most 192 common for an LNS where the PPP endpoint is co-located in the 193 same software system as the L2TP endpoint. A LAC may also be a 194 transparent receiver for one or more sessions it is tunneling, 195 if the PPP endpoint did not negotiate compression or encryption 196 receive options. Since PPP options are uni-directional, it is 197 possible to be a Transparent Tunnel Receiver but an Opaque 198 Tunnel Sender. 200 Opaque Tunnel Sender 202 An L2TP tunnel endpoint that cannot access the IP-in-PPP packets 203 which it is tunneling to its peer L2TP endpoint. This is most 204 common for an LAC, where the PPP endpoint is not typically 205 co-located in the same software system. In this case, the PPP 206 packets may be compressed or encrypted, making it impossible (or 207 infeasible) to recover the original IP datagram. Since PPP 208 options are uni-directional, it is possible to be an Opaque 209 Tunnel Sender but a Transparent Tunnel Receiver. 211 Transparent Tunnel Sender 213 An L2TP tunnel endpoint that can access the IP-in-PPP packets 214 which it is tunneling to its peer L2TP endpoint. This is most 215 common for an LNS, where the PPP endpoint is co-located in the 216 same software system. A LAC may also be a transparent sender 217 for one or more sessions it is tunneling, if the local PPP 218 endpoint did not negotiate compression or encryption send 219 options. Since PPP options are uni-directional, it is possible 220 to be a Transparent Tunnel Sender but an Opaque Tunnel Receiver. 222 2. Protocol overview 224 The current practice for L2TP-over-IP is to make no special effort 225 to prevent fragmentation of tunneled IP datagrams. This document 226 endeavors only to define the mechanisms by which fragmentation can 227 be avoided when the DF bit is set in the IPv4 datagram header for a 228 packet being tunneled, or when the packet being tunneled is an IPv6 229 datagram. 231 This document describes the additions necessary to the operation 232 and protocol of L2TP so that IPv4 and IPv6 path MTU discovery 233 mechanisms can be used between L2TP peers, and this information 234 communicated to the IP hosts whose traffic is being tunneled again 235 utilizing IPv4 and IPv6 path MTU discovery mechanisms. 237 These mechanisms can only be used when either the tunnel sender or 238 the tunnel receiver (or both) for a given flow is Transparent. If 239 one L2TP endpoint is an Opaque Tunnel Sender and the other L2TP 240 endpoint is an Opaque Tunnel Receiver, then path MTU discovery 241 mechanisms cannot be used to prevent fragmentation of the tunneled 242 IP datagrams at the tunnel level. 244 2.1 Transparent Tunnel Sender 246 For a Transparent Tunnel Sender, the mechanism used is to keep 247 track of whether the DF bit is set in tunneled IPv4 datagrams being 248 sent or if there are tunneled IPv6 datagrams being sent. 250 2.1.1 L2TP-over-IPv4 252 If an IPv4 packet is being tunneled with the DF bit set in its 253 header and the sending L2TP endpoint knows that the resulting 254 L2TP-encapsulated packet would be IP fragmented, the L2TP endpoint 255 sends an IPv4 ICMP message to the sending IP host specifying an 256 adjusted SPMTU at which L2TP-encapsulated packets will not be 257 fragmented. 259 If an IPv4 packet is being tunneled with the DF bit set in its 260 header and it does not meet the above condition, the DF bit is set 261 in the L2TP data channel packet. 263 If an IPv6 packet is being tunneled and the L2TP-encapsulated 264 packet exceeds the SPMTU between the L2TP peers, the L2TP endpoint 265 sends an IPv6 ICMP "Packet Too Big" message to the sending IP host 266 specifying an adjusted SPMTU at which L2TP-encapsulated packets 267 will not be fragmented. 269 If an IPv6 packet is being tunneled and does not meet the above 270 condition. the DF bit is set in the L2TP data channel packet. 272 2.1.2 L2TP-over-IPv6 274 If an IPv4 packet is being tunneled with the DF bit set in its 275 header and the L2TP-encapsulated packet exceeds the SPMTU between 276 the L2TP peers, the L2TP endpoint sends an IPv4 ICMP message to the 277 sending IP host specifying an adjusted SPMTU at which 278 L2TP-encapsulated packets will not need to be fragmented. 280 If an IPv6 packet is being tunneled and the L2TP-encapsulated 281 packet exceeds the SPMTU between the L2TP peers, the L2TP endpoint 282 sends an IPv6 ICMP "Packet Too Big" message to the sending IP host 283 specifying an adjusted SPMTU at which L2TP-encapsulated packets 284 will not be fragmented. 286 2.2 Transparent Tunnel Receiver 288 For a Transparent Tunnel Reciever, the mechanism used is to check 289 to see if L2TP packets received which were fragmented were carrying 290 tunneled IP datagrams which were not supposed to have been 291 fragmented. This can happen when the sending L2TP peer is an 292 Opaque Tunnel Sender, or when the sending L2TP peer is a 293 Transparent Tunnel Sender over IPv4 with an inaccurate value for 294 its SPMTU. 296 2.2.1 L2TP-over-IPv4 298 A tunneled IPv4 packet with the DF bit set may be received whose 299 L2TP-encapsulated IP packet was fragmented and the tunneled IPv4 300 packet is larger than the L2TP endpoint's RPMTU. In this case an 301 IPv4 ICMP message is tunneled back to the sending IP host 302 indicating the SPMTU the IP host should use in order that the 303 L2TP-encapsulated packets not be IP fragmented. 305 If a tunneled IPv4 packet with the DF bit set is received whose 306 L2TP-encapsulated IP packet was fragmented and the tunneled IPv4 307 packet is not larger than the L2TP endpoint's RPMTU, the L2TP 308 endpoint must learn a more accurate value for its RPMTU. 310 A tunneled IPv6 packet may be received whose L2TP-encapsulated IPv4 311 packet was fragmented and the tunneled IPv6 packet is larger than 312 the L2TP endpoint's RPMTU. In this case an IPv6 ICMP "Packet Too 313 Big" message is tunneled back to the sending IP host indicating the 314 SPMTU the IP host should use in order that the L2TP-encapsulated 315 packets not be IP fragmented. 317 2.2.2 L2TP-over-IPv6 319 A tunneled IPv4 packet with the DF bit set may be received whose 320 L2TP-encapsulated IPv6 packet was fragmented and the tunneled IPv4 321 packet is larger that the L2TP endpoint's LRPMTU. In this case an 322 IPv4 ICMP message is tunneled back to the sending IP host 323 indicating an MTU equal to the LRPMTU. 325 If a tunneled IPv4 packet with the DF bit set is received whose 326 L2TP-encapsulated IPv6 packet was fragmented and the tunneled IPv4 327 packet is not larger than tha LRPMTU, the L2TP endpoint has to 328 learn a more accurate value for its LRPMTU. 330 A tunneled IPv6 packet may be received whose L2TP-encapsulated IPv6 331 datagram was fragmented and the tunneled IPv6 packet is larger than 332 the L2TP endpoint's LRPTMU. In this case an IPv6 ICMP "Packet Too 333 Big" message is tunneled back to the sending IP host with an MTU 334 equal to the L2TP receiver's LRPMTU. 336 If a tunneled IPv6 packet is received whose L2TP-encapsulated IPv6 337 datagram was fragmented and the tunneled IPv6 packet is not larger 338 than the LRPMTU, the L2TP endpoint has to learn a more accurate 339 value for its LRPMTU. 341 2.3 Opaque Tunnel Sender 343 Since an Opaque Tunnel Sender cannot access the tunneled IP packet 344 it is sending, it does not have the capability to detect the cases 345 where path MTU discovery should be done. 347 It does have the capability to learn its LSPMTU value and 348 communicate this to its L2TP peer, however, so that the L2TP peer 349 can update its LRPMTU value. 351 2.4 Opaque Tunnel Receiver 353 Since an Opaque Tunnel Receiver cannot access the tunneled IP 354 packets it is sending, it does not have the capability to detect 355 the cases where path MTU discovery should be done. 357 An Opaque Tunnel Receiver depends completely on its L2TP peer to 358 perform the necessary path MTU discovery functions for tunneled IP 359 flows it is receiving. 361 2.5 PMTU Discovery Channel 363 The optional use of a PMTU discovery channel can be used as a 364 mechanism for path MTU discovery. This may be necessary in 365 environments where ICMP error packets cannot be reliably received 366 (e.g. due to filtering). 368 The MTU discovery channel is used to perform path MTU discovery on 369 IPv4 and IPv6 networks. The reason a separate channel is specified 370 is because the L2TP control MUST tear down a tunnel if a packet has 371 to be retransmitted a number of times without an acknowledgement, 372 as may happen during the normal operation of path MTU discovery. 374 3. Protocol additions 376 If both L2TP tunnel endpoints are Transparent Tunnel Senders and 377 Transparent Tunnel Receivers, there are no additional L2TP protocol 378 packets or AVPs necessary to support PMTU discovery for IP flows 379 being tunneled between the peers. 381 By including the addition of a new channel, called the L2TP PMTU 382 Discovery Channel, and new control message types and AVPs, it is 383 possible for a Transparent Tunnel Receiver to maintain an accurate 384 LRPMTU and perform path MTU discovery for tunneled IP flows it 385 receives. The situations where this is necessary are: 387 o L2TP peer is an Opaque Tunnel Sender (necessity or policy) 388 o L2TP peer does not support L2TP-over-IP PMTU Discovery 389 o L2TP peer does not support IPv6 and IPv6 is being tunneled 391 This section describes the additional control messages and AVPs 392 necessary for a receiving L2TP peer to support PMTU discovery on 393 tunneled IP flows. 395 3.1 Control Channel Messages 397 Two optional control channel message types are used to trigger PMTU 398 discovery and to report the results of PMTU discovery. These 399 messages MUST only be sent if both peers have indicated their 400 support of the optional L2TP PMTU discovery channel. 402 3.1.1 LRPMTU-Request (LRPMTURQ) 404 Because PMTU discovery indicates to the sender the value of the 405 PMTU, and in some cases the L2TP receiver must take part in PMTU 406 discovery for L2TP, it is necessary for an L2TP endpoint to be able 407 to query its L2TP peer in order to update its LRPMTU. 409 To achieve this, an L2TP endpoint sends an LRPMTU-request on the 410 L2TP control channel to its peer. 412 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 | L2TP Control Message Header | 414 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 415 | LRPMTU-Request | 416 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 417 | LRPMTU | 418 +-+-+-+-+-+-+-+-+-+-+-+-+ 420 LRPMTU-Request 421 0 1 2 3 422 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 423 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 424 |0|0|0|0| 8 | 2505 | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 426 | 0 | 1 | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 The Message Type AVP contains a Vendor ID of 2505, Attribute is 430 the 16-bit quantity 0 (the ID 2505 reflects New Oak 431 Communications, the initial developer of this specification, and 432 it MUST be changed to 0 and an official Attribute value chosen 433 if this specification advances on a standards track). 435 LRPMTU 437 0 1 2 3 438 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 439 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 440 |0|0|0|0| 8 | 2505 | 441 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 442 | 1 | LRPMTU Value | 443 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 445 The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 446 16-bit quantity 1 (the ID 2505 reflects New Oak Communications, 447 the initial developer of this specification, and it SHOULD be 448 changed to 0 and an official Attribute value chosen if this 449 specification advances on a standards track). 451 3.1.2 LRPMTU-Reply (LRPMTURP) 453 An L2TP peer which has previously advertised support of L2TP PMTU 454 Discovery, MUST respond to each received LRPMTURQ with a LRPMTURP. 456 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 457 | L2TP Control Message Header | 458 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 459 | LRPMTU-Reply | 460 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 461 | LRPMTU | 462 +-+-+-+-+-+-+-+-+-+-+-+-+ 464 LRPMTU-Reply 466 0 1 2 3 467 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 468 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 |0|0|0|0| 8 | 2505 | 470 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 471 | 0 | 2 | 472 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 474 The Message Type AVP contains a Vendor ID of 2505, Attribute is 475 the 16-bit quantity 0 (the ID 2505 reflects New Oak 476 Communications, the initial developer of this specification, and 477 it MUST be changed to 0 and an official Attribute value chosen 478 if this specification advances on a standards track). 480 LRPMTU 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 |0|0|0|0| 8 | 2505 | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | 1 | LRPMTU Value | 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 491 16-bit quantity 1 (the ID 2505 reflects New Oak Communications, 492 the initial developer of this specification, and it SHOULD be 493 changed to 0 and an official Attribute value chosen if this 494 specification advances on a standards track). 496 3.2 L2TP PMTU Discovery Channel Messages 498 Transparent Tunnel Senders over IPv4 SHOULD learn their SPMTU by 499 setting the DF bit in the IPv4 headers encapsulating the L2TP 500 packets if the payload is tunneled IPv4 with the DF bit set or if 501 the payload is tunneled IPv6. In this case the SPMTU will be 502 learned through the reception of IPv4 ICMP Type 3 Code 4 packets. 504 Opaque and Transparent Tunnel Senders over IPv6 MUST learn their 505 SPMTU from IPv6 ICMP Type 2 Code 0 packets received while sending 506 L2TP payload packets. 508 Opaque Tunnel Senders over IPv4 SHOULD, and Transparent Tunnel 509 Senders over IPv4 MAY, use the L2TP MTU Discovery Channel to 510 discover the SPMTU to their L2TP peer. 512 If both L2TP endpoint did not both previously advertise support for 513 the L2TP PMTU Discovery Channel, the LSPMTU-Explore-Request MUST 514 not be sent, and the LSPMTU-Explore-Reply MUST not be sent. 516 3.2.1 LSPMTU-Explore-Request (LSPMTUExRQ) 518 To discover the SPMTU to its L2TP peer, an L2TP endpoint 519 (Transparent MAY, Opaque SHOULD) send an LSPMTUExRQ packet to its 520 peer. Over IPv4 the LSPMTUExRQ MUST be sent with the DF bit set in 521 the encapsulating IPv4 header. 523 The LSPMTU AVP MUST immediately follow the LSPMTUExRQ AVP. 525 One or more Padding AVPs MUST immediately follow the LSPMTU AVP, 526 until the L2TP packet size will be equal to the value specified in 527 the LSPMTU AVP plus the maximum L2TP data encapsulation overhead. 529 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 530 | L2TP Control Message Header | 531 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 532 | LSPMTU-Explore-Request | 533 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 534 | LSPMTU | 535 | Padding AVPs | 536 +-+-+-+-+-+-+-+-+-+-+-+-+ 538 LSPMTU-Explore-Request 540 0 1 2 3 541 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 542 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 543 |0|0|0|0| 8 | 2505 | 544 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 545 | 0 | 3 | 546 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 The Message Type AVP contains a Vendor ID of 2505, Attribute is 549 the 16-bit quantity 0 (the ID 2505 reflects New Oak 550 Communications, the initial developer of this specification, and 551 it SHOULD be changed to 0 and an official Attribute value chosen 552 if this specification advances on a standards track). 554 LSPMTU 556 0 1 2 3 557 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 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 |0|0|0|0| 8 | 2505 | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | 2 | LSPMTU Value | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 564 The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 565 16-bit quantity 2 (the ID 2505 reflects New Oak Communications, 566 the initial developer of this specification, and it SHOULD be 567 changed to 0 and an official Attribute value chosen if this 568 specification advances on a standards track). 570 Padding 572 0 1 2 3 573 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 574 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 575 |0|0|0|0| <=1024 | 2505 | 576 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 577 | 3 | Padding bytes.... 578 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 580 The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 581 16-bit quantity 3 (the ID 2505 reflects New Oak Communications, 582 the initial developer of this specification, and it SHOULD be 583 changed to 0 and an official Attribute value chosen if this 584 specification advances on a standards track). 586 3.2.2 LSPMTU-Explore-Reply (LSPMTUExRP) 588 An L2TP endpoint that previously advertised support for the L2TP 589 Discovery Channel MUST reply to each LSPMTUExRQ received by sending 590 an LSPMTUExRP. Over IPv4 the LSPMTUExRP MUST not be sent with the 591 DF bit set in the encapsulating IPv4 header. 593 The LSPMTUExRP packet MUST only be sent in reply to a received 594 LSPMTUExRQ packet. 596 The LSPMTU AVP MUST immediately follow the LSPMTUExRP AVP. The 597 value of the LSPMTU AVP in the LSPMTUExRP MUST exactly match the 598 value in the LSPMTU AVP in the corresponding LSPMTUExRQ received. 600 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 601 | L2TP Control Message Header | 602 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 603 | LSPMTU-Explore-Reply | 604 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 605 | LSPMTU | 606 +-+-+-+-+-+-+-+-+-+-+-+-+ 607 LSPMTU-Explore-Reply 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 |0|0|0|0| 8 | 2505 | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 614 | 0 | 4 | 615 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 617 The Message Type AVP contains a Vendor ID of 2505, Attribute is 618 the 16-bit quantity 0 (the ID 2505 reflects New Oak 619 Communications, the initial developer of this specification, and 620 it SHOULD be changed to 0 and an official Attribute value chosen 621 if this specification advances on a standards track). 623 LSPMTU 625 0 1 2 3 626 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 627 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 628 |0|0|0|0| 8 | 2505 | 629 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 630 | 2 | LSPMTU Value | 631 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 633 The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 634 16-bit quantity 2 (the ID 2505 reflects New Oak Communications, 635 the initial developer of this specification, and it SHOULD be 636 changed to 0 and an official Attribute value chosen if this 637 specification advances on a standards track). 639 3.3 L2TP PMTU Discovery Capabilities AVP (MTUCAP) 641 The MTUCAP AVP is an AVP which can be present in SCCRQ, SCCRP, and 642 SCCCN control channel messages. This AVP is used to indicate that 643 the sender supports the use of an additional control channel used 644 for L2TP path MTU discovery. 646 MTUCAP 648 0 1 2 3 649 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 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 |0|0|0|0| 14 | 2505 | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | 4 | IPv4 TS | IPv4 TR | 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | IPv6 TS | IPv6 TR | Assigned Call ID | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | LSPMTU | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 660 The MTUCAP AVP contains the Vendor ID 2505, Attribute is the 661 16-bit quantity 4 (the ID 2505 reflects New Oak Communications, 662 the initial developer of this specification, and it SHOULD be 663 changed to 0 and an official Attribute value chosen if this 664 specification advances on a standards track). 666 IPv4 TS 668 The value of this octet indicates whether the peer sending the 669 MTUCAP AVP is a Transparent Sender of tunneled IPv4 packets in 670 all cases for this tunnel. Defined IPv4 TS values are: 672 0 - Will not perform IPv4 Transparent Sender actions 673 1 - Will perform IPv4 Transparent Sender actions 675 The value 1 MUST only be used for IPv4 TS if the sending L2TP 676 endpoint will perform all Transparent Sender actions for IPv4 677 datagrams specified in this document. 679 IPv4 TR 681 The value of this octet indicates whether the peer sending the 682 MTUCAP AVP is a Transparent Receiver of tunneled IPv4 packets in 683 all cases for this tunnel. Defined IPv4 TR values are: 685 0 - Will not perform IPv4 Transparent Receiver actions 686 1 - Will perform IPv4 Transparent Receiver actions 688 The value 1 MUST only be used for IPv4 TR if the sending L2TP 689 endpoint will perform all Transparent Receiver actions for IPv4 690 datagrams specified in this document. 692 IPv6 TS 694 The value of this octet indicates whether the peer sending the 695 MTUCAP AVP is a Transparent Sender of tunneled IPv6 packets in 696 all cases for this tunnel. Defined IPv6 TS values are: 698 0 - Will not perform IPv6 Transparent Sender actions 699 1 - Will perform IPv6 Transparent Sender actions 701 The value 1 MUST only be used for IPv6 TS if the sending L2TP 702 endpoint will perform all Transparent Sender actions for IPv6 703 datagrams specified in this document. 705 IPv6 TR 707 The value of this octet indicates whether the peer sending the 708 MTUCAP AVP is a Transparent Receiver of tunneled IPv6 packets in 709 all cases for this tunnel. Defined IPv6 TR values are: 711 0 - Will not perform IPv6 Transparent Receiver actions 712 1 - Will perform IPv6 Transparent Receiver actions 714 The value 1 MUST only be used for IPv6 TR is the sending L2TP 715 endpoint will perform all Transparent Receiver actions for IPv6 716 datagrams specified in this document. 718 Assigned Call ID 720 The Assigned Call ID encodes the ID being assigned to the L2TP 721 PMTU Discovery channel used solely for the exchange of 722 LRPMTUExRQ and LRPMTUExRP messages. A value of 0 indicates that 723 the L2TP peer will not support the LRPMTUExRQ and LRPMTUExRP 724 messages. This call ID MUST be used for the L2TP PMTU Discovery 725 Channel if both L2TP peers send the MTUCAP AVP with nonzero 726 Assigned Call ID values. LRPMTUExRQ (and hence LRPMTURxRP) 727 messages MUST not be sent on any advertised Call ID unless both 728 peers have sent nonzero Assigned Call ID values in their most 729 recently send MTUCAP AVPs. 731 LSPMTU 733 The LSPMTU encodes the value that the sender of the MTUCAP AVP 734 believes is its LSPMTU to the peer. This value is used by the 735 peer to initialize its LRPMTU value for the tunnel. 737 4. Protocol Operation 739 This section describes the effects of L2TP PMTU Discovery on the 740 L2TP protocol operation, and the additional requirements for 741 handling tunneled packets to support PMTU Discovery. 743 4.1 Tunnel Establishment 745 During L2TP tunnel establishment, the L2TP peers advertise their 746 PMTU Discovery capabilities via the MTUCAP AVP. Both peers 747 indicate to what extent they can be considered Transparent Senders 748 and Receivers. They also indicate what call ID they wish to assign 749 the L2TP PMTU Discovery channel if they are willing to support this 750 optional channel. 752 4.1.1 SCCRQ Sender 754 The sender of the SCCRQ MUST include the MTUCAP AVP in the SCCRQ 755 message, indicating their capabilities as a Transparent Tunnel 756 Sender and Receiver of IPv4 and IPv6 datagrams, whether they desire 757 support of the PMTU Discovery Channel, and what their value for the 758 SPMTU between is. 760 Sending the MTUCAP AVP, the SCCRQ sender MUST indicate with the 761 IPv4 TS if they are a Transparent Sender of IPv4 tunneled traffic. 762 The SCCRQ sender MUST indicate with the IPv4 TR if they are a 763 Transparent Receiver of IPv4 tunneled traffic. The SCCRQ sender 764 MUST indicate with the IPv6 TS if they are a Transparent Sender of 765 IPv6 tunneled traffic. The SCCRQ sender MUST indicate with the 766 IPv6 TR if they are a Transparent Receiver of IPv4 tunneled 767 traffic. The SCCRQ sender SHOULD also indicate a non-zero value 768 for Assigned Call ID in the MTUCAP AVP that they will assign to the 769 PMTU Discovery Channel if they are willing to support this optional 770 channel. The SCCRQ MTUCAP AVP sender MUST indicate a non-zero 771 value for LSPMTU which is as accurate as possible an estimate of 772 the sending peer's LSPMTU for the tunnel (default to first-hop 773 MTU). 775 4.1.2 SCCRP Sender 777 If the receiver of an SCCRQ containing the MTUCAP AVP is sending an 778 SCCRP, the SCCRP MUST include the MTUCAP AVP. 780 The sender of the SCCRP MUST include in the SCCRP message the 781 MTUCAP AVP with a non-zero value for Assigned Call ID if they wish 782 to support the PMTU Discovery Channel. The sender of the SCCRP 783 MUST include the MTUCAP AVP if they are not both an IPv4 and IPv6 784 Tunnel Sender and if the L2TP peer explicitly indicated (via the 785 MTUCAP AVP) that the peer was not both an IPv4 and IPv6 Tunnel 786 Sender. The sender of SCCRP MUST include the MTUCAP AVP if they 787 are not both an IPv4 and IPv6 Tunnel Sender and if the peer did not 788 include the MTUCAP AVP in the SCCRQ. 790 The SCCRP MTUCAP AVP MUST indicate with the IPv4 TS if the sender 791 is a Transparent Sender of IPv4 tunneled traffic. The SCCRP MTUCAP 792 AVP MUST indicate with the IPv4 TR if the sender is a Transparent 793 Receiver of IPv4 tunneled traffic. The SCCRP MTUCAP AVP MUST 794 indicate with the IPv6 TS if the sender is a Transparent Sender of 795 IPv6 tunneled traffic. The SCCRP MTUCAP AVP MUST indicate with the 796 IPv6 TR if the sender is a Transparent Receiver of tunneled IPv6 797 traffic. If the SCCRP sender will support the PMTU Discovery 798 channel, the SCCRP MTUCAP AVP MUST indicate a non-zero value for 799 Assigned Call ID. The SCCRP MTUCAP AVP MUST indicate a non-zero 800 value for LSPMTU which is as accurate as possible an estimate of 801 the sending peer's LSPMTU for the tunnel (default to first-hop 802 MTU). 804 4.1.3 SCCCN Sender 806 If the receiver of an SCCRP containing the MTUCAP AVP is sending an 807 SCCCN, the SCCCN MAY include the MTUCAP AVP. 809 The SCCCN MTUCAP AVP MUST not differ from the SCCRQ MTUCAP AVP 810 previously sent, except for the Assigned Call ID and SPMTU values. 812 If the SCCCN sender previously sent a non-zero value for the PMTU 813 Discovery channel Assigned Call ID and the SCCRP MTUCAP AVP 814 Assigned Call ID was non-zero, but the capabilities of the two 815 tunnel endpoints is such that the channel is not needed, the SCCCN 816 sender MUST include the MTUCAP AVP in the SCCCN indicating a zero 817 value for Assigned Call ID. 819 If the SCCCN sender previously send a zero value for the PMTU 820 Discovery channel Assigned Call ID, but the capabilities of the two 821 tunnel endpoints is such that the channel is needed, the SCCCN 822 sender SHOULD include the MTUCAP AVP in the SCCCN indicating a 823 non-zero value for Assigned Call ID. 825 If the SCCCN sender has an updated estimate for its LSPMTU since 826 the SCCRQ was sent, the MTUCAP AVP MUST be included in the SCCCN 827 and the SPMTU value of the MTUCAP AVP MUST be updated accordingly. 829 In all cases, the SCCCN MTUCAP AVP sender MUST include the most 830 recent estimate it has for LSPMTU. 832 The SCCCN sender MAY include an MTUCAP AVP which has all identical 833 values as the MTUCAP AVP sent in the SCCRQ. 835 4.1.4 PMTU Discovery Channel Requirements 837 Depending on the capabilities of the two tunnel endpoints, the PMTU 838 Discovery Channel may or may not be necessary or possible. 840 If running L2TP-over-IPv6, the PMTU Discovery channel MUST not be 841 used. 843 If both tunnel endpoints had values of one (1) for both IPv4 TS and 844 IPv6 TS the PMTU Discovery Channel MUST not be used. 846 For L2TP-over-IPv4, it is RECOMMENDED that the PMTU Discovery 847 channel be used in lieu of other PMTU discovery mechanisms 848 (e.g. ICMP Echo Request/Reply). The reason for this is so that 849 PMTU discovery can still be done in cases where other network 850 circumstances (e.g. packet filtering) might preclude the operation 851 of other PMTU discovery mechanisms. 853 If one L2TP endpoint specified IPv4 TS of zero (0) and the other 854 L2TP endpoint specified IPv4 TR of one (1) and the sender of IPv4 855 TS of zero (0) does not have a reliable mechanism for PMTU 856 discovery to the L2TP peer, then the PMTU Discovery Channel MUST be 857 used. 859 If one L2TP endpoint specified IPv6 TS of zero (0) and the other 860 L2TP endpoint specified IPv6 TR of one (1) and the sender of IPv6 861 TS of zero (0) does not have a reliable mechanism for PMTU 862 discovery to the L2TP peer, then the PMTU Discovery Channel MUST be 863 used. 865 4.2 Packet Handling 867 This section describes the actions necessary to perform as a 868 Transparent Tunnel Sender while L2TP-encapsulating IPv4 and IPv6 869 datagrams and the actions necessary to perform as a Transparent 870 Tunnel Receiver while L2TP-decapsulating IPv4 and IPv6 datagrams. 872 4.2.1 Transparent Sender Actions 874 An L2TP endpoint which has sent an IPv4 TS or IPv6 TS of one (1) in 875 the MTUCAP AVP MUST perform the actions described in the relevant 876 section below. 878 An L2TP endpoint which did not send an IPv4 TS or IPv6 TS of one 879 (1) in the MTUCAP AVP but whose implementation can detect tunneled 880 PPP connections for which all of the requirements of the relevant 881 section can be satisfied SHOULD act as an IPv4 or IPv6 Transparent 882 Sender as appropriate for those selected flows. 884 It is beyond the scope of this document to describe what mechanisms 885 an implementations may internally use in order to have the 886 capability of being a Transparent Sender. 888 4.2.1.1 IPv4 Transparent Sender 889 Each IPv4 datagram which is greater than 68 bytes (minimum IPv4 MTU 890 as specified in [6]) in length and is to be encapsulated MUST be 891 checked to see if the DF bit in the IPv4 datagram header is set. 893 Any IPv4 datagram which is equal to 68 bytes in length MUST not be 894 checked against the LSPMTU for the L2TP tunnel. 896 Checking the size of IPv4 datagrams with the DF bit set against the 897 tunnel LSPMTU SHOULD be done prior to any (stateful or 898 non-stateful) compression or encryption. 900 If checking the size of IPv4 datagrams with the DF bit set against 901 the tunnel LSPMTU is done after any compression or encryption, the 902 Internet Header and first 64 bits of the original IPv4 datagram 903 data MUST be stored. 905 If the IPv4 datagram header DF bit is set, the LSPMTU for the 906 tunnel is checked. If the check is done before any stateful 907 compression or encryption and the IPv4 datagram is larger than the 908 LSPMTU then the IPv4 datagram MUST be dropped. If the check is 909 done after any stateful compression or encryption and the IPv4 910 datagram after any compression is larger than the LSPMTU then the 911 IPv4 datagram SHOULD not be dropped. 913 If a precompressed IPv4 datagram or a postcompressed IPv4 datagram 914 is larger than the LSPMTU for the tunnel, an IPv4 ICMP Type 3 Code 915 4 packet is sent to the originating IP host as in [1] and 916 specifying an MTU equal to the the greater of the LSPMTU for the 917 tunnel or 68 (minimum IPv4 MTU as specified in [6]). For 918 implementations checking the IPv4 datagram size against the LSPMTU 919 after any compression or encryption, when sending the IPv4 ICMP 920 Type 3 Code 4 packet the stored Internet Header and first 64 bits 921 of the original IP datagram data MUST be included in the IPv4 ICMP 922 packet. 924 For L2TP-over-IPv4 when the size of the IPv4 packet being 925 encapsulated is equal to 68 (minimum IPv4 MTU as specified in [6]), 926 the DF bit in the encapsulating IPv4 header MUST not be set. For 927 L2TP-over-IPv4 when the size of the IPv4 packet being encapsulated 928 is greater than 68 and the DF bit is set, the DF bit MUST be set in 929 the encapsulating IPv4 header as well. When the DF bit is not set 930 in the IPv4 packet being encapsulated, the DF bit MUST not be set 931 in the IPv4 packet encapsulating the L2TP payload. 933 4.2.1.2 IPv6 Transparent Sender 934 Each IPv6 datagram which is greater than 576 bytes (minimum IPv6 935 MTU as specified in [5]) in length and is to be encapsulated MUST 936 be checked to see if the IPv6 datagram is larger than the LSPMTU 937 for the L2TP tunnel. 939 Any IPv6 datagram which is equal to 576 bytes in length MUST not be 940 checked against the LSPMTU for the L2TP tunnel. 942 Checking the size of the IPv6 datagram against the tunnel LSPMTU 943 SHOULD be done prior to any (stateful or non-stateful) compression 944 or encryption. 946 If checking the size of IPv6 datagrams against the tunnel LSPMTU is 947 done after any compression or encryption, at least the first 528 948 bytes of the original IPv6 datagram MUST be stored (576 as 949 specified in [4] - 40 bytes of IPv6 header - 8 bytes of ICMPv6 950 header = 528 bytes). 952 If the IPv6 datagram size is larger than the LSPMTU and the check 953 is done before any stateful compression or encryption then the IPv6 954 datagram MUST be dropped. If the check is done after any stateful 955 compression or encryption and the IPv6 datagram after any 956 compression is larger than the LSPMTU then the IPv6 datagram SHOULD 957 not be dropped. 959 If a precompressed IPv6 datagram or a postcompressed IPv6 datagram 960 is larger than the LSPMTU for the tunnel, an ICMPv6 Type 2 Code 0 961 packet is sent to the originating IPv6 host as in [4] and 962 specifying an MTU equal to the greater of the LSPMTU for the tunnel 963 or 576 (minimum IPv6 MTU as specified in [5]). For implementations 964 checking the IPv6 datagram size against the LSPMTU after any 965 compression or encryption, when sending the ICMPv6 Type 2 Code 0 966 packet the stored data from the original packet MUST be included in 967 the ICMPv6 packet. 969 For L2TP-over-IPv4 when the size of the IPv6 packet being 970 encapsulated is equal to 576 (minimum IPv6 MTU as specified in 971 [5]), the DF bit in the encapsulating IPv4 header MUST not be set. 972 For L2TP-over-IPv4 when the size of the IPv6 packet being 973 encapsulated is greater than 576 the DF bit MUST be set in the 974 encapsulating IPv4 header as well. 976 For L2TP-over-IPv6 when the size of the IPv6 packet being 977 encapsulated is equal to 576 and the encapsulating packet is larger 978 than the SPMTU, fragmentation MUST be performed locally on the 979 IPv6 packet encapsulating the L2TP payload. 981 4.2.2 Transparent Receiver Actions 983 An L2TP endpoint which has sent an IPv4 TR or IPv6 TR of one (1) in 984 the MTUCAP AVP and whose L2TP peer sent the corresponding IPv4 TS 985 or IPv6 TS as zero (0) MUST perform the actions described in the 986 relevant section below. 988 An L2TP endpoint which did not send an IPv4 or IPv6 TR of one (1) 989 in the MTUCAP AVP and whose L2TP peer sent the corresponding IPv4 990 or IPv6 TS as zero (0) SHOULD perform the actions described in the 991 relevant section below for selected PPP sessions for which they can 992 satisfy all of the requirements in the relevant section below. 994 An IPv4 or IPv6 Transparent Receiver MUST be able to detect when 995 the datagram encapsulating the L2TP packet was received having been 996 IP fragmented. 998 It is beyond the scope of this document to describe what mechanisms 999 an implementations may internally use in order to have the 1000 capability of being a Transparent Receiver. 1002 4.2.2.1 IPv4 Transparent Receiver 1004 An implementation capable of being an IPv4 Transparent Receiver 1005 MUST not perform the actions put forth in this section if an MTUCAP 1006 AVP was received with the IPv4 TS set to one (1). 1008 An IPv4 Transparent Receiver MUST check each received tunneled IPv4 1009 datagram to see if the DF bit is set in the IPv4 datagram header. 1011 If a received tunneled IPv4 datagram has the DF bit set and the 1012 datagram was fragmented while encapsulated the size of the datagram 1013 is checked against the LRPMTU for the tunnel. If the size of the 1014 IPv4 datagram is larger than the the LRPMTU of the tunnel, an IPv4 1015 ICMP Type 3 Code 4 packet MUST be sent tunneled to the originating 1016 IP host as in [1] specifying an MTU equal to the LRPMTU. If the 1017 size of the IPv4 datagram is not larger than the LRPMTU of the 1018 tunnel, this indicates that the L2TP endpoint does not have an 1019 accurate value for its LRPMTU and a better estimate MUST be 1020 obtained (see section 4.2.2.3 below). 1022 Packets for which an IPv4 ICMP Type 3 Code 4 packet was sent MAY 1023 have the DF bit cleared in the IPv4 datagram header (and the 1024 checksum re-computed) of the once-encapsulated packet and in this 1025 case processing of this packet can continue. If the DF bit is not 1026 cleared in the IPv4 datagram header, however, then the packet MUST 1027 be dropped. This is to prevent the possibility of two ICMP Type 3 1028 Code 4 packets from being received by the originating IP host for 1029 the same packet. 1031 4.2.2.2 IPv6 Transparent Receiver 1033 An implementation capable of being an IPv6 Transparent Receiver 1034 MUST not perform the actions put forth in this section if an MTUCAP 1035 AVP was received with the IPv6 TS set to one (1). 1037 An IPv6 Transparent Receiver MUST check each received tunneled IPv6 1038 datagram and check to see if the datagram was fragmented while 1039 encapsulated. Each received tunneled IPv6 packet which was 1040 fragmented while encapsulated has its size checked against the 1041 LRPMTU for the tunnel. If the size of the IPv6 datagram is larger 1042 than the LRPMTU of the tunnel, the datagram MUST be dropped and an 1043 ICMPv6 Type 2 Code 0 packet MUST be sent tunneled to the 1044 originating IP host as in [4] specifying an MTU equal to the 1045 LRPMTU. If the size of the IPv6 datagram is not larger than the 1046 LRPMTU of the tunnel and the packet was fragmented while 1047 encapsulated this indicates that the L2TP endpoint does not have an 1048 accurate value for its LRPMTU and a better estimate MUST be 1049 obtained (see section 4.2.2.3 below). 1051 4.2.2.3 LRPMTU Discovery 1053 If an MTUCAP AVP was received, an L2TP endpoint MUST initialize its 1054 LRPMTU value to the lesser of the value found in the most recently 1055 received MTUCAP AVP for LSPMTU or (if known) the MTU for the whole 1056 or a portion of the path (e.g. the local-hop receive MTU). 1058 If an L2TP endpoint discovers that it does not have an accurate 1059 value for LRPMTU it enters LRPMTU discovery mode (if not already in 1060 LRPMTU discovery mode). Entering LRPMTU discovery mode prompts the 1061 sending of an LRPMTUExRQ to the peer. LRPMTUExRQ messages MUST not 1062 be sent to the peer if an LRPMTUExRQ was sent and no LRPMTUExRP was 1063 received. 1065 If an LRPMTUExRQ was sent to the peer and no LRPMTUExRP was 1066 received from the peer for (XXX - a very long time?) the peer MUST 1067 no longer attempt to use the LRPMTUExRQ to update its LRPMTU value. 1068 It MUST, instead, use the MTU values found in [1] and adjust them 1069 accordingly to obtain an updated LRPMTU value. 1071 4.3 SPMTU Discovery 1073 An accurate value for SPMTU MUST be obtained or ready when an 1074 LRPMTUExRQ is received. An implementation MUST send an LRPMTUExRP 1075 within 10 seconds of receiving an LRPMTUExRQ. 1077 4.3.1 SPMTU Discovery over IPv4 1079 When running L2TP-over-IPv4, the SPMTU discovery is not as 1080 automatic as when running L2TP-over-IPv6. For IPv4 use of the L2TP 1081 PMTU Discovery Channel might be necessary. 1083 When operating some (or all) sessions in a tunnel as a Transparent 1084 Sender a reasonable estimate for the SPMTU, depending on actual 1085 traffic patterns, may be obtained naturally while setting the DF 1086 bit in IPv4 headers encapsulating L2TP packets tunneling IPv4 1087 packets with the DF bit set or tunneling IPv6 packets. 1089 For a fully Opaque Tunnel Sender an initial estimate for the SPMTU 1090 might be the first-hop MTU. If this value proves to be inadequate, 1091 the L2TP PMTU Discovery channel SHOULD be used to do PMTU discovery 1092 as in [1]. 1094 An implementation also MAY choose to estimate the SPMTU by using 1095 Table 7-1 in [1]. 1097 For L2TP-over-IPv4 the minimum possible value for SPMTU is 68 as in 1098 [6]. This may result in an LSPMTU less than 68, although a value 1099 of less than 68 is never advertised to the originating IPv4 hosts 1100 whose traffic is being tunneled, and a value of less than 576 ([5]) 1101 is never advertised to the originating IPv6 hosts whose traffic is 1102 being tunneled. 1104 4.3.2 SPMTU Discovery over IPv6 1106 When running L2TP-over-IPv6, the SPMTU discovery happens naturally 1107 as a consequence of running the IPv6 protocol as specified in 1108 [5] and [4]. 1110 For L2TP-over-IPv6 the minimum possible value for SPMTU is 576 as 1111 in [5]. This may result an LSPMTU less than 576, although a value 1112 of less than 576 is never advertised to the originating IPv6 hosts 1113 whose traffic is being tunneled. 1115 5. Security Considerations 1117 As described in [1], general path MTU discovery enables 1118 denial-of-service attacks based on a malicious party sending a 1119 false IPv4 Datagram Too Big message to an IP host. It is also true 1120 that IPv6 contains no special protection against either of these 1121 attacks and the text of this section applies to both IPv4 and IPv6 1122 equally. 1124 The first attack is to send false messages indicating a PMTU 1125 smaller than the real PMTU. While this does not completely stop 1126 data flow, it can seriously impact performance. 1128 The second attack is to send false messages indicating a PMTU 1129 larger than the real PMTU, which could cause hosts to begin sending 1130 packets that would need to be fragmented and hence will get 1131 dropped. To avoid this in general, hosts should never raise their 1132 estimate of the PMTU based on a Datagram Too Big message, so should 1133 not be vulnerable to this attack. 1135 A more banal denial-of-service attack could be caused by a 1136 malicious party preventing delivery of legitimate Datagram Too Big 1137 messages. This is not a specific concern of this document, 1138 however, since a party that could prevent delivery of ICMP packets 1139 could conceivably prevent delivery of other packets as well 1140 affecting more serious denial-of-service attacks. 1142 The first attack above, based on Datagram Too Big messages with 1143 PMTUs smaller than the real PMTU, is somewhat worse for L2TP. 1144 Since a tunnel may represent several tunneled sessions, a single 1145 attack on the L2TP endpoint affects all of the tunneled sessions 1146 for which the L2TP endpoint is a Transparent Tunnel Sender or the 1147 remote tunnel endpoint is a Transparent Tunnel Receiver. 1149 The L2TP the first attack above is also more effective when running 1150 L2TP-over-IPv4 and tunneling IPv6 datagrams, and where an IPv4 ICMP 1151 Datagram Too Big message is sent specifying a PMTU which is less 1152 than the minimum IPv6 MTU. Note also, that this can also happen 1153 not due to a malicious party but just during normal operation. In 1154 this case, the performance of both L2TP endpoints may be affected 1155 as the sender may spend extra cycles fragmenting and the receiver 1156 may therefore spend extra cycles as well to reassemble. 1158 An L2TP endpoint MUST not update its SPMTU (and hence its LSPMTU) 1159 value based on ICMP Datagram Too Big messages received containing a 1160 PMTU value larger than the current SPMTU. This will prevent the 1161 possibility of the second attack above where a malicious party 1162 sends these messages with a PMTU which is larger than the true PMTU 1163 for the path. 1165 References 1167 [1] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191 1169 [2] C. Kent and J. Mogul. Fragmentation Considered Harmful. In 1170 Proc. SIGCOMM '87 Workshop on Frontiers in Computer 1171 Communications Technology. August, 1987 1173 [3] K. Hamzeh, et al, "Layer Two Tunneling Protocol", Work In 1174 Progress: draft-ietf-pppext-l2tp-08.txt, November 1997 1176 [4] A. Conta, S. Deering, "Internet Control Message Protocol 1177 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 1178 Specification", RFC 1885 1180 [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) 1181 Specification", RFC 1883 1183 [6] J. Postel, "Internet Protocol", RFC 791 1185 Author's Address 1187 Richard Shea 1188 New Oak Communications 1189 125 Nagog Park 1190 Acton, Massachusetts 01720 1191 rshea@newoak.com