[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Nits]

Versions: 00                                                            
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]