PPP Working Group Richard Shea INTERNET DRAFT New Oak Communications Category: Internet Draft Title: draft-ietf-pppext-l2tpmtu-00.txt Date: January 1998 L2TP-over-IP Path MTU Discovery (''L2TPMTU'') Status of this Memo This document is an Internet-Draft. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet-Drafts. Internet-Drafts are draft documents valid for a maximum of six months. Internet-Drafts may be updated, replaced, or obsoleted by other documents at any time. It is not appropriate to use Internet- Drafts as reference material or to cite them other than as a ``working draft'' or ``work in progress.'' To learn the current status of any Internet-Draft, please check the 1id-abstracts.txt listing contained in the Internet-Drafts Shadow Directories on ds.internic.net, nic.nordu.net, ftp.nisc.sri.com, or munnari.oz.au. Abstract The Layer Two Tunneling Protocol (L2TP) defines a mechanism for tunneling PPP over arbitrary media. When IPv4 or IPv6 over PPP is tunneled over L2TP, it is desirable to avoid fragmentation of the L2TP data channel packets when L2TP is run over IP. This document describes a mechanism for L2TP-over-IP to avoid fragmentation of tunneled IPv4 and IPv6 datagrams by leveraging IPv4 and IPv6 path MTU discovery mechanisms. Table of Contents 1. Introduction 1.1 Conventions 1.2 Terminology 2. Protocol Overview 2.1 Transparent Tunnel Sender Shea expires July 1998 [Page 1]
INTERNET DRAFT January 1998 2.1.1 L2TP-over-IPv4 2.1.2 L2TP-over-IPv6 2.2 Transparent Tunnel Receiver 2.2.1 L2TP-over-IPv4 2.2.2 L2TP-over-IPv6 2.3 Opaque Tunnel Sender 2.4 Opaque Tunnel Receiver 2.5 PMTU Discovery Channel 3. Protocol Additions 3.1 Control Channel Messages 3.1.1 LRPMTU-Request (LRPMTURQ) 3.1.2 LRMPTU-Reply (LRPMTURP) 3.2 L2TP PMTU Discovery Channel Messages 3.2.1 LSPMTU-Explore-Request (LSPMTUExRQ) 3.2.2 LSPMTU-Explore-Reply (LSPMTUExRP) 3.3 L2TP PMTU Discovery Capabilities AVP (MTUCAP) 4. Protocol Operation 4.1 Tunnel Establishment 4.1.1 SCCRQ Sender 4.1.2 SCCRP Sender 4.1.3 SCCCN Sender 4.1.4 PMTU Discovery Channel Requirements 4.2 Packet Handling 4.2.1 Transparent Sender Actions 4.2.1.1 IPv4 Transparent Sender 4.2.1.2 IPv6 Transparent Sender 4.2.2 Transparent Receiver Actions 4.2.2.1 IPv4 Transparent Receiver 4.2.2.2 IPv6 Transparent Receiver 4.2.2.3 LRPMTU Discovery 4.3 SPMTU Discovery 4.3.1 SPMTU Discovery over IPv4 4.3.2 SPMTU Discovery over IPv6 5. Security Considerations References Author's Address 1. Introduction Both version 4 of the Internet Protocol (IPv4) and version 6 of the Internet Protocol (IPv6) define mechanisms for path MTU discovery in order to avoid fragmentation of IP datagrams. Document [1] describes a mechanism for avoiding fragmentation of IPv4 datagrams by using the IPv4 header "Don't Fragment" (DF) bit. The IPv6 protocol itself defines a similar (mandatory) mechanism for path MTU discovery in IPv6 networks. The reasons for avoiding fragmentation have been explored in [2]. Shea expires July 1998 [Page 2]
INTERNET DRAFT January 1998 When L2TP is run over IP, fragmentation of the tunneled IP datagrams may occur due to the Path MTU between the L2TP peers and especially given the fact that extra byte overhead has been added to the original IP-in-PPP datagram so that it may be tunneled. In this case, any IP flows being tunneled with fragmentation happening to the L2TP data packets inherit the bad qualities of IP fragmentation as if the fragmentation were happening to the IP flow directly. In order to avoid IP fragmentation of IP flows being tunneled by L2TP, a mechanism is needed so that Path MTU discovery between L2TP tunnel endpoints is done, and the adjusted path MTU for tunneled IP flows is communicated to the IP hosts whose traffic is being tunneled. 1.1 Conventions The following language conventions are used in the items of specification in this document: o MUST, SHALL, or MANDATORY -- This item is an absolute requirement of the specification. o SHOULD or RECOMMEND -- This item should generally be followed for all but exceptional circumstances. o MAY or OPTIONAL -- This item is truly optional and may be followed or ignored according to the needs of the implementor. 1.2 Terminology This draft currently assumes the reader is knowledgable about terms found in [3]. In addition, the following terms are used in this document: MTU The maximum size of an IP datagram such that it will not need to be fragmented. The term MTU is meant to mean the first-hop MTU, while Path MTU is used to mean the MTU along all hops along an IP path. PMTU Path MTU (Maximum Transmission Unit). The maximum size of an IP datagram between two IP hosts (i.e. along a path) that will not Shea expires July 1998 [Page 3]
INTERNET DRAFT January 1998 result in IP fragmentation. This value is necessarily equal to the smallest single-hop MTU along the path. SPMTU Send Path MTU. From the point of view of an IP host, the maximum size of an IP datagram to another IP host that will not result in IP fragmentation along the path to the peer IP host. RPMTU Receive Path MTU. From the point of view of an IP host, the maximum size of an IP datagram that another IP host can send to it which will not be received having been fragmented. LSPMTU L2TP SPMTU. The SPMTU as seen by IP flows being tunneled with L2TP, from the point of view of the L2TP endpoint sending the traffic. This value is essentially the SPMTU between two L2TP tunnel endpoints subtracted by the maximum tunneling overhead possible in the sending direction. The LSPMTU of one L2TP peer is equal to the LRPMTU of the other peer. LRPMTU L2TP RPMTU. The RPMTU as seen by IP flows being tunneled with L2TP, from the point of view of the L2TP endpoint receiving the traffic. This value is essentially the RPMTU between two L2TP tunnel endpoints subtracted by the maximum tunneling overhead possible in the receiving direction. The LRPMTU of one L2TP peer is equal to the LSPMTU of the other peer. PMTU Discovery Channel An optional L2TP channel used to send messages between peers in order to discover PMTUs between an LAC and an LNS. Opaque Tunnel Receiver An L2TP tunnel endpoint that cannot access the IP-in-PPP packets which its peer L2TP endpoint is sending to it. This is most common for an LAC, where the PPP endpoint is not typically co-located in the same software system. In this case the PPP packets may be compressed or encrypted, making it impossible (or infeasible) to recover the original IP datagram. Since PPP options are uni-directional, it is possible to be an Opaque Shea expires July 1998 [Page 4]
INTERNET DRAFT January 1998 Tunnel Receiver, but a Transparent Tunnel Sender. Transparent Tunnel Receiver An L2TP tunnel endpoint that can access the IP-in-PPP packets which its peer L2TP endpoint is sending to it. This is most common for an LNS where the PPP endpoint is co-located in the same software system as the L2TP endpoint. A LAC may also be a transparent receiver for one or more sessions it is tunneling, if the PPP endpoint did not negotiate compression or encryption receive options. Since PPP options are uni-directional, it is possible to be a Transparent Tunnel Receiver but an Opaque Tunnel Sender. Opaque Tunnel Sender An L2TP tunnel endpoint that cannot access the IP-in-PPP packets which it is tunneling to its peer L2TP endpoint. This is most common for an LAC, where the PPP endpoint is not typically co-located in the same software system. In this case, the PPP packets may be compressed or encrypted, making it impossible (or infeasible) to recover the original IP datagram. Since PPP options are uni-directional, it is possible to be an Opaque Tunnel Sender but a Transparent Tunnel Receiver. Transparent Tunnel Sender An L2TP tunnel endpoint that can access the IP-in-PPP packets which it is tunneling to its peer L2TP endpoint. This is most common for an LNS, where the PPP endpoint is co-located in the same software system. A LAC may also be a transparent sender for one or more sessions it is tunneling, if the local PPP endpoint did not negotiate compression or encryption send options. Since PPP options are uni-directional, it is possible to be a Transparent Tunnel Sender but an Opaque Tunnel Receiver. 2. Protocol overview The current practice for L2TP-over-IP is to make no special effort to prevent fragmentation of tunneled IP datagrams. This document endeavors only to define the mechanisms by which fragmentation can be avoided when the DF bit is set in the IPv4 datagram header for a packet being tunneled, or when the packet being tunneled is an IPv6 datagram. This document describes the additions necessary to the operation and protocol of L2TP so that IPv4 and IPv6 path MTU discovery Shea expires July 1998 [Page 5]
INTERNET DRAFT January 1998 mechanisms can be used between L2TP peers, and this information communicated to the IP hosts whose traffic is being tunneled again utilizing IPv4 and IPv6 path MTU discovery mechanisms. These mechanisms can only be used when either the tunnel sender or the tunnel receiver (or both) for a given flow is Transparent. If one L2TP endpoint is an Opaque Tunnel Sender and the other L2TP endpoint is an Opaque Tunnel Receiver, then path MTU discovery mechanisms cannot be used to prevent fragmentation of the tunneled IP datagrams at the tunnel level. 2.1 Transparent Tunnel Sender For a Transparent Tunnel Sender, the mechanism used is to keep track of whether the DF bit is set in tunneled IPv4 datagrams being sent or if there are tunneled IPv6 datagrams being sent. 2.1.1 L2TP-over-IPv4 If an IPv4 packet is being tunneled with the DF bit set in its header and the sending L2TP endpoint knows that the resulting L2TP-encapsulated packet would be IP fragmented, the L2TP endpoint sends an IPv4 ICMP message to the sending IP host specifying an adjusted SPMTU at which L2TP-encapsulated packets will not be fragmented. If an IPv4 packet is being tunneled with the DF bit set in its header and it does not meet the above condition, the DF bit is set in the L2TP data channel packet. If an IPv6 packet is being tunneled and the L2TP-encapsulated packet exceeds the SPMTU between the L2TP peers, the L2TP endpoint sends an IPv6 ICMP "Packet Too Big" message to the sending IP host specifying an adjusted SPMTU at which L2TP-encapsulated packets will not be fragmented. If an IPv6 packet is being tunneled and does not meet the above condition. the DF bit is set in the L2TP data channel packet. 2.1.2 L2TP-over-IPv6 If an IPv4 packet is being tunneled with the DF bit set in its header and the L2TP-encapsulated packet exceeds the SPMTU between the L2TP peers, the L2TP endpoint sends an IPv4 ICMP message to the sending IP host specifying an adjusted SPMTU at which L2TP-encapsulated packets will not need to be fragmented. Shea expires July 1998 [Page 6]
INTERNET DRAFT January 1998 If an IPv6 packet is being tunneled and the L2TP-encapsulated packet exceeds the SPMTU between the L2TP peers, the L2TP endpoint sends an IPv6 ICMP "Packet Too Big" message to the sending IP host specifying an adjusted SPMTU at which L2TP-encapsulated packets will not be fragmented. 2.2 Transparent Tunnel Receiver For a Transparent Tunnel Reciever, the mechanism used is to check to see if L2TP packets received which were fragmented were carrying tunneled IP datagrams which were not supposed to have been fragmented. This can happen when the sending L2TP peer is an Opaque Tunnel Sender, or when the sending L2TP peer is a Transparent Tunnel Sender over IPv4 with an inaccurate value for its SPMTU. 2.2.1 L2TP-over-IPv4 A tunneled IPv4 packet with the DF bit set may be received whose L2TP-encapsulated IP packet was fragmented and the tunneled IPv4 packet is larger than the L2TP endpoint's RPMTU. In this case an IPv4 ICMP message is tunneled back to the sending IP host indicating the SPMTU the IP host should use in order that the L2TP-encapsulated packets not be IP fragmented. If a tunneled IPv4 packet with the DF bit set is received whose L2TP-encapsulated IP packet was fragmented and the tunneled IPv4 packet is not larger than the L2TP endpoint's RPMTU, the L2TP endpoint must learn a more accurate value for its RPMTU. A tunneled IPv6 packet may be received whose L2TP-encapsulated IPv4 packet was fragmented and the tunneled IPv6 packet is larger than the L2TP endpoint's RPMTU. In this case an IPv6 ICMP "Packet Too Big" message is tunneled back to the sending IP host indicating the SPMTU the IP host should use in order that the L2TP-encapsulated packets not be IP fragmented. 2.2.2 L2TP-over-IPv6 A tunneled IPv4 packet with the DF bit set may be received whose L2TP-encapsulated IPv6 packet was fragmented and the tunneled IPv4 packet is larger that the L2TP endpoint's LRPMTU. In this case an IPv4 ICMP message is tunneled back to the sending IP host indicating an MTU equal to the LRPMTU. If a tunneled IPv4 packet with the DF bit set is received whose L2TP-encapsulated IPv6 packet was fragmented and the tunneled IPv4 Shea expires July 1998 [Page 7]
INTERNET DRAFT January 1998 packet is not larger than tha LRPMTU, the L2TP endpoint has to learn a more accurate value for its LRPMTU. A tunneled IPv6 packet may be received whose L2TP-encapsulated IPv6 datagram was fragmented and the tunneled IPv6 packet is larger than the L2TP endpoint's LRPTMU. In this case an IPv6 ICMP "Packet Too Big" message is tunneled back to the sending IP host with an MTU equal to the L2TP receiver's LRPMTU. If a tunneled IPv6 packet is received whose L2TP-encapsulated IPv6 datagram was fragmented and the tunneled IPv6 packet is not larger than the LRPMTU, the L2TP endpoint has to learn a more accurate value for its LRPMTU. 2.3 Opaque Tunnel Sender Since an Opaque Tunnel Sender cannot access the tunneled IP packet it is sending, it does not have the capability to detect the cases where path MTU discovery should be done. It does have the capability to learn its LSPMTU value and communicate this to its L2TP peer, however, so that the L2TP peer can update its LRPMTU value. 2.4 Opaque Tunnel Receiver Since an Opaque Tunnel Receiver cannot access the tunneled IP packets it is sending, it does not have the capability to detect the cases where path MTU discovery should be done. An Opaque Tunnel Receiver depends completely on its L2TP peer to perform the necessary path MTU discovery functions for tunneled IP flows it is receiving. 2.5 PMTU Discovery Channel The optional use of a PMTU discovery channel can be used as a mechanism for path MTU discovery. This may be necessary in environments where ICMP error packets cannot be reliably received (e.g. due to filtering). The MTU discovery channel is used to perform path MTU discovery on IPv4 and IPv6 networks. The reason a separate channel is specified is because the L2TP control MUST tear down a tunnel if a packet has to be retransmitted a number of times without an acknowledgement, as may happen during the normal operation of path MTU discovery. Shea expires July 1998 [Page 8]
INTERNET DRAFT January 1998 3. Protocol additions If both L2TP tunnel endpoints are Transparent Tunnel Senders and Transparent Tunnel Receivers, there are no additional L2TP protocol packets or AVPs necessary to support PMTU discovery for IP flows being tunneled between the peers. By including the addition of a new channel, called the L2TP PMTU Discovery Channel, and new control message types and AVPs, it is possible for a Transparent Tunnel Receiver to maintain an accurate LRPMTU and perform path MTU discovery for tunneled IP flows it receives. The situations where this is necessary are: o L2TP peer is an Opaque Tunnel Sender (necessity or policy) o L2TP peer does not support L2TP-over-IP PMTU Discovery o L2TP peer does not support IPv6 and IPv6 is being tunneled This section describes the additional control messages and AVPs necessary for a receiving L2TP peer to support PMTU discovery on tunneled IP flows. 3.1 Control Channel Messages Two optional control channel message types are used to trigger PMTU discovery and to report the results of PMTU discovery. These messages MUST only be sent if both peers have indicated their support of the optional L2TP PMTU discovery channel. 3.1.1 LRPMTU-Request (LRPMTURQ) Because PMTU discovery indicates to the sender the value of the PMTU, and in some cases the L2TP receiver must take part in PMTU discovery for L2TP, it is necessary for an L2TP endpoint to be able to query its L2TP peer in order to update its LRPMTU. To achieve this, an L2TP endpoint sends an LRPMTU-request on the L2TP control channel to its peer. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LRPMTU-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LRPMTU | +-+-+-+-+-+-+-+-+-+-+-+-+ LRPMTU-Request Shea expires July 1998 [Page 9]
INTERNET DRAFT January 1998 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Vendor ID of 2505, Attribute is the 16-bit quantity 0 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it MUST be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). LRPMTU 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | LRPMTU Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 16-bit quantity 1 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). 3.1.2 LRPMTU-Reply (LRPMTURP) An L2TP peer which has previously advertised support of L2TP PMTU Discovery, MUST respond to each received LRPMTURQ with a LRPMTURP. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LRPMTU-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LRPMTU | +-+-+-+-+-+-+-+-+-+-+-+-+ LRPMTU-Reply 0 1 2 3 Shea expires July 1998 [Page 10]
INTERNET DRAFT January 1998 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Vendor ID of 2505, Attribute is the 16-bit quantity 0 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it MUST be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). LRPMTU 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 1 | LRPMTU Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 16-bit quantity 1 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). 3.2 L2TP PMTU Discovery Channel Messages Transparent Tunnel Senders over IPv4 SHOULD learn their SPMTU by setting the DF bit in the IPv4 headers encapsulating the L2TP packets if the payload is tunneled IPv4 with the DF bit set or if the payload is tunneled IPv6. In this case the SPMTU will be learned through the reception of IPv4 ICMP Type 3 Code 4 packets. Opaque and Transparent Tunnel Senders over IPv6 MUST learn their SPMTU from IPv6 ICMP Type 2 Code 0 packets received while sending L2TP payload packets. Opaque Tunnel Senders over IPv4 SHOULD, and Transparent Tunnel Senders over IPv4 MAY, use the L2TP MTU Discovery Channel to discover the SPMTU to their L2TP peer. If both L2TP endpoint did not both previously advertise support for the L2TP PMTU Discovery Channel, the LSPMTU-Explore-Request MUST Shea expires July 1998 [Page 11]
INTERNET DRAFT January 1998 not be sent, and the LSPMTU-Explore-Reply MUST not be sent. 3.2.1 LSPMTU-Explore-Request (LSPMTUExRQ) To discover the SPMTU to its L2TP peer, an L2TP endpoint (Transparent MAY, Opaque SHOULD) send an LSPMTUExRQ packet to its peer. Over IPv4 the LSPMTUExRQ MUST be sent with the DF bit set in the encapsulating IPv4 header. The LSPMTU AVP MUST immediately follow the LSPMTUExRQ AVP. One or more Padding AVPs MUST immediately follow the LSPMTU AVP, until the L2TP packet size will be equal to the value specified in the LSPMTU AVP plus the maximum L2TP data encapsulation overhead. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPMTU-Explore-Request | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPMTU | | Padding AVPs | +-+-+-+-+-+-+-+-+-+-+-+-+ LSPMTU-Explore-Request 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 3 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Vendor ID of 2505, Attribute is the 16-bit quantity 0 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). LSPMTU 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Shea expires July 1998 [Page 12]
INTERNET DRAFT January 1998 | 2 | LSPMTU Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 16-bit quantity 2 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). Padding 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| <=1024 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 3 | Padding bytes.... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 16-bit quantity 3 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). 3.2.2 LSPMTU-Explore-Reply (LSPMTUExRP) 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. The LSPMTUExRP packet MUST only be sent in reply to a received LSPMTUExRQ packet. The LSPMTU AVP MUST immediately follow the LSPMTUExRP AVP. The value of the LSPMTU AVP in the LSPMTUExRP MUST exactly match the value in the LSPMTU AVP in the corresponding LSPMTUExRQ received. +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | L2TP Control Message Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPMTU-Explore-Reply | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPMTU | +-+-+-+-+-+-+-+-+-+-+-+-+ Shea expires July 1998 [Page 13]
INTERNET DRAFT January 1998 LSPMTU-Explore-Reply 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 0 | 4 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The Message Type AVP contains a Vendor ID of 2505, Attribute is the 16-bit quantity 0 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). LSPMTU 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 8 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 2 | LSPMTU Value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The LRPMTU AVP contains the Vendor ID 2505, Attribute is the 16-bit quantity 2 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). 3.3 L2TP PMTU Discovery Capabilities AVP (MTUCAP) The MTUCAP AVP is an AVP which can be present in SCCRQ, SCCRP, and SCCCN control channel messages. This AVP is used to indicate that the sender supports the use of an additional control channel used for L2TP path MTU discovery. MTUCAP 0 1 2 3 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0|0|0|0| 14 | 2505 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 4 | IPv4 TS | IPv4 TR | Shea expires July 1998 [Page 14]
INTERNET DRAFT January 1998 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPv6 TS | IPv6 TR | Assigned Call ID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | LSPMTU | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ The MTUCAP AVP contains the Vendor ID 2505, Attribute is the 16-bit quantity 4 (the ID 2505 reflects New Oak Communications, the initial developer of this specification, and it SHOULD be changed to 0 and an official Attribute value chosen if this specification advances on a standards track). IPv4 TS The value of this octet indicates whether the peer sending the MTUCAP AVP is a Transparent Sender of tunneled IPv4 packets in all cases for this tunnel. Defined IPv4 TS values are: 0 - Will not perform IPv4 Transparent Sender actions 1 - Will perform IPv4 Transparent Sender actions The value 1 MUST only be used for IPv4 TS if the sending L2TP endpoint will perform all Transparent Sender actions for IPv4 datagrams specified in this document. IPv4 TR The value of this octet indicates whether the peer sending the MTUCAP AVP is a Transparent Receiver of tunneled IPv4 packets in all cases for this tunnel. Defined IPv4 TR values are: 0 - Will not perform IPv4 Transparent Receiver actions 1 - Will perform IPv4 Transparent Receiver actions The value 1 MUST only be used for IPv4 TR if the sending L2TP endpoint will perform all Transparent Receiver actions for IPv4 datagrams specified in this document. IPv6 TS The value of this octet indicates whether the peer sending the MTUCAP AVP is a Transparent Sender of tunneled IPv6 packets in all cases for this tunnel. Defined IPv6 TS values are: 0 - Will not perform IPv6 Transparent Sender actions 1 - Will perform IPv6 Transparent Sender actions Shea expires July 1998 [Page 15]
INTERNET DRAFT January 1998 The value 1 MUST only be used for IPv6 TS if the sending L2TP endpoint will perform all Transparent Sender actions for IPv6 datagrams specified in this document. IPv6 TR The value of this octet indicates whether the peer sending the MTUCAP AVP is a Transparent Receiver of tunneled IPv6 packets in all cases for this tunnel. Defined IPv6 TR values are: 0 - Will not perform IPv6 Transparent Receiver actions 1 - Will perform IPv6 Transparent Receiver actions The value 1 MUST only be used for IPv6 TR is the sending L2TP endpoint will perform all Transparent Receiver actions for IPv6 datagrams specified in this document. Assigned Call ID 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. LSPMTU The LSPMTU encodes the value that the sender of the MTUCAP AVP believes is its LSPMTU to the peer. This value is used by the peer to initialize its LRPMTU value for the tunnel. 4. Protocol Operation This section describes the effects of L2TP PMTU Discovery on the L2TP protocol operation, and the additional requirements for handling tunneled packets to support PMTU Discovery. 4.1 Tunnel Establishment During L2TP tunnel establishment, the L2TP peers advertise their PMTU Discovery capabilities via the MTUCAP AVP. Both peers indicate to what extent they can be considered Transparent Senders Shea expires July 1998 [Page 16]
INTERNET DRAFT January 1998 and Receivers. They also indicate what call ID they wish to assign the L2TP PMTU Discovery channel if they are willing to support this optional channel. 4.1.1 SCCRQ Sender The sender of the SCCRQ MUST include the MTUCAP AVP in the SCCRQ message, indicating their capabilities as a Transparent Tunnel Sender and Receiver of IPv4 and IPv6 datagrams, whether they desire support of the PMTU Discovery Channel, and what their value for the SPMTU between is. Sending the MTUCAP AVP, the SCCRQ sender MUST indicate with the IPv4 TS if they are a Transparent Sender of IPv4 tunneled traffic. The SCCRQ sender MUST indicate with the IPv4 TR if they are a Transparent Receiver of IPv4 tunneled traffic. The SCCRQ sender MUST indicate with the IPv6 TS if they are a Transparent Sender of IPv6 tunneled traffic. The SCCRQ sender MUST indicate with the IPv6 TR if they are a Transparent Receiver of IPv4 tunneled traffic. The SCCRQ sender SHOULD also indicate a non-zero value for Assigned Call ID in the MTUCAP AVP that they will assign to the PMTU Discovery Channel if they are willing to support this optional channel. The SCCRQ MTUCAP AVP sender MUST indicate a non-zero value for LSPMTU which is as accurate as possible an estimate of the sending peer's LSPMTU for the tunnel (default to first-hop MTU). 4.1.2 SCCRP Sender If the receiver of an SCCRQ containing the MTUCAP AVP is sending an SCCRP, the SCCRP MUST include the MTUCAP AVP. The sender of the SCCRP MUST include in the SCCRP message the MTUCAP AVP with a non-zero value for Assigned Call ID if they wish to support the PMTU Discovery Channel. The sender of the SCCRP MUST include the MTUCAP AVP if they are not both an IPv4 and IPv6 Tunnel Sender and if the L2TP peer explicitly indicated (via the MTUCAP AVP) that the peer was not both an IPv4 and IPv6 Tunnel Sender. The sender of SCCRP MUST include the MTUCAP AVP if they are not both an IPv4 and IPv6 Tunnel Sender and if the peer did not include the MTUCAP AVP in the SCCRQ. The SCCRP MTUCAP AVP MUST indicate with the IPv4 TS if the sender is a Transparent Sender of IPv4 tunneled traffic. The SCCRP MTUCAP AVP MUST indicate with the IPv4 TR if the sender is a Transparent Receiver of IPv4 tunneled traffic. The SCCRP MTUCAP AVP MUST indicate with the IPv6 TS if the sender is a Transparent Sender of Shea expires July 1998 [Page 17]
INTERNET DRAFT January 1998 IPv6 tunneled traffic. The SCCRP MTUCAP AVP MUST indicate with the IPv6 TR if the sender is a Transparent Receiver of tunneled IPv6 traffic. If the SCCRP sender will support the PMTU Discovery channel, the SCCRP MTUCAP AVP MUST indicate a non-zero value for Assigned Call ID. The SCCRP MTUCAP AVP MUST indicate a non-zero value for LSPMTU which is as accurate as possible an estimate of the sending peer's LSPMTU for the tunnel (default to first-hop MTU). 4.1.3 SCCCN Sender If the receiver of an SCCRP containing the MTUCAP AVP is sending an SCCCN, the SCCCN MAY include the MTUCAP AVP. The SCCCN MTUCAP AVP MUST not differ from the SCCRQ MTUCAP AVP previously sent, except for the Assigned Call ID and SPMTU values. If the SCCCN sender previously sent a non-zero value for the PMTU Discovery channel Assigned Call ID and the SCCRP MTUCAP AVP Assigned Call ID was non-zero, but the capabilities of the two tunnel endpoints is such that the channel is not needed, the SCCCN sender MUST include the MTUCAP AVP in the SCCCN indicating a zero value for Assigned Call ID. If the SCCCN sender previously send a zero value for the PMTU Discovery channel Assigned Call ID, but the capabilities of the two tunnel endpoints is such that the channel is needed, the SCCCN sender SHOULD include the MTUCAP AVP in the SCCCN indicating a non-zero value for Assigned Call ID. If the SCCCN sender has an updated estimate for its LSPMTU since the SCCRQ was sent, the MTUCAP AVP MUST be included in the SCCCN and the SPMTU value of the MTUCAP AVP MUST be updated accordingly. In all cases, the SCCCN MTUCAP AVP sender MUST include the most recent estimate it has for LSPMTU. The SCCCN sender MAY include an MTUCAP AVP which has all identical values as the MTUCAP AVP sent in the SCCRQ. 4.1.4 PMTU Discovery Channel Requirements Depending on the capabilities of the two tunnel endpoints, the PMTU Discovery Channel may or may not be necessary or possible. If running L2TP-over-IPv6, the PMTU Discovery channel MUST not be used. Shea expires July 1998 [Page 18]
INTERNET DRAFT January 1998 If both tunnel endpoints had values of one (1) for both IPv4 TS and IPv6 TS the PMTU Discovery Channel MUST not be used. For L2TP-over-IPv4, it is RECOMMENDED that the PMTU Discovery channel be used in lieu of other PMTU discovery mechanisms (e.g. ICMP Echo Request/Reply). The reason for this is so that PMTU discovery can still be done in cases where other network circumstances (e.g. packet filtering) might preclude the operation of other PMTU discovery mechanisms. If one L2TP endpoint specified IPv4 TS of zero (0) and the other L2TP endpoint specified IPv4 TR of one (1) and the sender of IPv4 TS of zero (0) does not have a reliable mechanism for PMTU discovery to the L2TP peer, then the PMTU Discovery Channel MUST be used. If one L2TP endpoint specified IPv6 TS of zero (0) and the other L2TP endpoint specified IPv6 TR of one (1) and the sender of IPv6 TS of zero (0) does not have a reliable mechanism for PMTU discovery to the L2TP peer, then the PMTU Discovery Channel MUST be used. 4.2 Packet Handling This section describes the actions necessary to perform as a Transparent Tunnel Sender while L2TP-encapsulating IPv4 and IPv6 datagrams and the actions necessary to perform as a Transparent Tunnel Receiver while L2TP-decapsulating IPv4 and IPv6 datagrams. 4.2.1 Transparent Sender Actions An L2TP endpoint which has sent an IPv4 TS or IPv6 TS of one (1) in the MTUCAP AVP MUST perform the actions described in the relevant section below. An L2TP endpoint which did not send an IPv4 TS or IPv6 TS of one (1) in the MTUCAP AVP but whose implementation can detect tunneled PPP connections for which all of the requirements of the relevant section can be satisfied SHOULD act as an IPv4 or IPv6 Transparent Sender as appropriate for those selected flows. It is beyond the scope of this document to describe what mechanisms an implementations may internally use in order to have the capability of being a Transparent Sender. 4.2.1.1 IPv4 Transparent Sender Shea expires July 1998 [Page 19]
INTERNET DRAFT January 1998 Each IPv4 datagram which is greater than 68 bytes (minimum IPv4 MTU as specified in [6]) in length and is to be encapsulated MUST be checked to see if the DF bit in the IPv4 datagram header is set. Any IPv4 datagram which is equal to 68 bytes in length MUST not be checked against the LSPMTU for the L2TP tunnel. Checking the size of IPv4 datagrams with the DF bit set against the tunnel LSPMTU SHOULD be done prior to any (stateful or non-stateful) compression or encryption. If checking the size of IPv4 datagrams with the DF bit set against the tunnel LSPMTU is done after any compression or encryption, the Internet Header and first 64 bits of the original IPv4 datagram data MUST be stored. 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. If a precompressed IPv4 datagram or a postcompressed IPv4 datagram is larger than the LSPMTU for the tunnel, an IPv4 ICMP Type 3 Code 4 packet is sent to the originating IP host as in [1] and specifying an MTU equal to the the greater of the LSPMTU for the tunnel or 68 (minimum IPv4 MTU as specified in [6]). For implementations checking the IPv4 datagram size against the LSPMTU after any compression or encryption, when sending the IPv4 ICMP Type 3 Code 4 packet the stored Internet Header and first 64 bits of the original IP datagram data MUST be included in the IPv4 ICMP packet. 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. 4.2.1.2 IPv6 Transparent Sender Shea expires July 1998 [Page 20]
INTERNET DRAFT January 1998 Each IPv6 datagram which is greater than 576 bytes (minimum IPv6 MTU as specified in [5]) in length and is to be encapsulated MUST be checked to see if the IPv6 datagram is larger than the LSPMTU for the L2TP tunnel. Any IPv6 datagram which is equal to 576 bytes in length MUST not be checked against the LSPMTU for the L2TP tunnel. Checking the size of the IPv6 datagram against the tunnel LSPMTU SHOULD be done prior to any (stateful or non-stateful) compression or encryption. If checking the size of IPv6 datagrams against the tunnel LSPMTU is done after any compression or encryption, at least the first 528 bytes of the original IPv6 datagram MUST be stored (576 as specified in [4] - 40 bytes of IPv6 header - 8 bytes of ICMPv6 header = 528 bytes). 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. If a precompressed IPv6 datagram or a postcompressed IPv6 datagram is larger than the LSPMTU for the tunnel, an ICMPv6 Type 2 Code 0 packet is sent to the originating IPv6 host as in [4] and specifying an MTU equal to the greater of the LSPMTU for the tunnel or 576 (minimum IPv6 MTU as specified in [5]). For implementations checking the IPv6 datagram size against the LSPMTU after any compression or encryption, when sending the ICMPv6 Type 2 Code 0 packet the stored data from the original packet MUST be included in the ICMPv6 packet. 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. For L2TP-over-IPv6 when the size of the IPv6 packet being encapsulated is equal to 576 and the encapsulating packet is larger than the SPMTU, fragmentation MUST be performed locally on the IPv6 packet encapsulating the L2TP payload. Shea expires July 1998 [Page 21]
INTERNET DRAFT January 1998 4.2.2 Transparent Receiver Actions An L2TP endpoint which has sent an IPv4 TR or IPv6 TR of one (1) in the MTUCAP AVP and whose L2TP peer sent the corresponding IPv4 TS or IPv6 TS as zero (0) MUST perform the actions described in the relevant section below. An L2TP endpoint which did not send an IPv4 or IPv6 TR of one (1) in the MTUCAP AVP and whose L2TP peer sent the corresponding IPv4 or IPv6 TS as zero (0) SHOULD perform the actions described in the relevant section below for selected PPP sessions for which they can satisfy all of the requirements in the relevant section below. An IPv4 or IPv6 Transparent Receiver MUST be able to detect when the datagram encapsulating the L2TP packet was received having been IP fragmented. It is beyond the scope of this document to describe what mechanisms an implementations may internally use in order to have the capability of being a Transparent Receiver. 4.2.2.1 IPv4 Transparent Receiver 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). An IPv4 Transparent Receiver MUST check each received tunneled IPv4 datagram to see if the DF bit is set in the IPv4 datagram header. If a received tunneled IPv4 datagram has the DF bit set and the datagram was fragmented while encapsulated the size of the datagram is checked against the LRPMTU for the tunnel. If the size of the IPv4 datagram is larger than the the LRPMTU of the tunnel, an IPv4 ICMP Type 3 Code 4 packet MUST be sent tunneled to the originating IP host as in [1] specifying an MTU equal to the LRPMTU. If the size of the IPv4 datagram is not larger than the LRPMTU of the tunnel, this indicates that the L2TP endpoint does not have an accurate value for its LRPMTU and a better estimate MUST be obtained (see section 4.2.2.3 below). Packets for which an IPv4 ICMP Type 3 Code 4 packet was sent MAY have the DF bit cleared in the IPv4 datagram header (and the checksum re-computed) of the once-encapsulated packet and in this case processing of this packet can continue. If the DF bit is not cleared in the IPv4 datagram header, however, then the packet MUST be dropped. This is to prevent the possibility of two ICMP Type 3 Shea expires July 1998 [Page 22]
INTERNET DRAFT January 1998 Code 4 packets from being received by the originating IP host for the same packet. 4.2.2.2 IPv6 Transparent Receiver 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). An IPv6 Transparent Receiver MUST check each received tunneled IPv6 datagram and check to see if the datagram was fragmented while encapsulated. Each received tunneled IPv6 packet which was fragmented while encapsulated has its size checked against the LRPMTU for the tunnel. If the size of the IPv6 datagram is larger than the LRPMTU of the tunnel, the datagram MUST be dropped and an ICMPv6 Type 2 Code 0 packet MUST be sent tunneled to the originating IP host as in [4] specifying an MTU equal to the LRPMTU. If the size of the IPv6 datagram is not larger than the LRPMTU of the tunnel and the packet was fragmented while encapsulated this indicates that the L2TP endpoint does not have an accurate value for its LRPMTU and a better estimate MUST be obtained (see section 4.2.2.3 below). 4.2.2.3 LRPMTU Discovery If an MTUCAP AVP was received, an L2TP endpoint MUST initialize its LRPMTU value to the lesser of the value found in the most recently received MTUCAP AVP for LSPMTU or (if known) the MTU for the whole or a portion of the path (e.g. the local-hop receive MTU). 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. If an LRPMTUExRQ was sent to the peer and no LRPMTUExRP was received from the peer for (XXX - a very long time?) the peer MUST no longer attempt to use the LRPMTUExRQ to update its LRPMTU value. It MUST, instead, use the MTU values found in [1] and adjust them accordingly to obtain an updated LRPMTU value. 4.3 SPMTU Discovery An accurate value for SPMTU MUST be obtained or ready when an LRPMTUExRQ is received. An implementation MUST send an LRPMTUExRP Shea expires July 1998 [Page 23]
INTERNET DRAFT January 1998 within 10 seconds of receiving an LRPMTUExRQ. 4.3.1 SPMTU Discovery over IPv4 When running L2TP-over-IPv4, the SPMTU discovery is not as automatic as when running L2TP-over-IPv6. For IPv4 use of the L2TP PMTU Discovery Channel might be necessary. When operating some (or all) sessions in a tunnel as a Transparent Sender a reasonable estimate for the SPMTU, depending on actual traffic patterns, may be obtained naturally while setting the DF bit in IPv4 headers encapsulating L2TP packets tunneling IPv4 packets with the DF bit set or tunneling IPv6 packets. For a fully Opaque Tunnel Sender an initial estimate for the SPMTU might be the first-hop MTU. If this value proves to be inadequate, the L2TP PMTU Discovery channel SHOULD be used to do PMTU discovery as in [1]. An implementation also MAY choose to estimate the SPMTU by using Table 7-1 in [1]. For L2TP-over-IPv4 the minimum possible value for SPMTU is 68 as in [6]. This may result in an LSPMTU less than 68, although a value of less than 68 is never advertised to the originating IPv4 hosts whose traffic is being tunneled, and a value of less than 576 ([5]) is never advertised to the originating IPv6 hosts whose traffic is being tunneled. 4.3.2 SPMTU Discovery over IPv6 When running L2TP-over-IPv6, the SPMTU discovery happens naturally as a consequence of running the IPv6 protocol as specified in [5] and [4]. For L2TP-over-IPv6 the minimum possible value for SPMTU is 576 as in [5]. This may result an LSPMTU less than 576, although a value of less than 576 is never advertised to the originating IPv6 hosts whose traffic is being tunneled. 5. Security Considerations As described in [1], general path MTU discovery enables denial-of-service attacks based on a malicious party sending a false IPv4 Datagram Too Big message to an IP host. It is also true that IPv6 contains no special protection against either of these attacks and the text of this section applies to both IPv4 and IPv6 Shea expires July 1998 [Page 24]
INTERNET DRAFT January 1998 equally. The first attack is to send false messages indicating a PMTU smaller than the real PMTU. While this does not completely stop data flow, it can seriously impact performance. The second attack is to send false messages indicating a PMTU larger than the real PMTU, which could cause hosts to begin sending packets that would need to be fragmented and hence will get dropped. To avoid this in general, hosts should never raise their estimate of the PMTU based on a Datagram Too Big message, so should not be vulnerable to this attack. A more banal denial-of-service attack could be caused by a malicious party preventing delivery of legitimate Datagram Too Big messages. This is not a specific concern of this document, however, since a party that could prevent delivery of ICMP packets could conceivably prevent delivery of other packets as well affecting more serious denial-of-service attacks. The first attack above, based on Datagram Too Big messages with PMTUs smaller than the real PMTU, is somewhat worse for L2TP. Since a tunnel may represent several tunneled sessions, a single attack on the L2TP endpoint affects all of the tunneled sessions for which the L2TP endpoint is a Transparent Tunnel Sender or the remote tunnel endpoint is a Transparent Tunnel Receiver. The L2TP the first attack above is also more effective when running L2TP-over-IPv4 and tunneling IPv6 datagrams, and where an IPv4 ICMP Datagram Too Big message is sent specifying a PMTU which is less than the minimum IPv6 MTU. Note also, that this can also happen not due to a malicious party but just during normal operation. In this case, the performance of both L2TP endpoints may be affected as the sender may spend extra cycles fragmenting and the receiver may therefore spend extra cycles as well to reassemble. 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. References [1] J. Mogul, S. Deering, "Path MTU Discovery", RFC 1191 Shea expires July 1998 [Page 25]
INTERNET DRAFT January 1998 [2] C. Kent and J. Mogul. Fragmentation Considered Harmful. In Proc. SIGCOMM '87 Workshop on Frontiers in Computer Communications Technology. August, 1987 [3] K. Hamzeh, et al, "Layer Two Tunneling Protocol", Work In Progress: draft-ietf-pppext-l2tp-08.txt, November 1997 [4] A. Conta, S. Deering, "Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification", RFC 1885 [5] S. Deering, R. Hinden, "Internet Protocol, Version 6 (IPv6) Specification", RFC 1883 [6] J. Postel, "Internet Protocol", RFC 791 Author's Address Richard Shea New Oak Communications 125 Nagog Park Acton, Massachusetts 01720 rshea@newoak.com Shea expires July 1998 [Page 26]
