One document matched: draft-ietf-pppext-l2tpmtu-00.txt
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]
| PAFTECH AB 2003-2026 | 2026-04-22 15:11:42 |