Subject: [L2tpext] [Editorial Errata Reported] RFC3931 (2766)

From: RFC Errata System <[email-masked]>
Date: Mon, 4 Apr 2011 07:19:32 -0700 (PDT)

The following errata report has been submitted for RFC3931,
"Layer Two Tunneling Protocol - Version 3 (L2TPv3)".

--------------------------------------
You may review the report below and at:
http://www.rfc-editor.org/errata_search.php?rfc=3931&eid=2766

--------------------------------------
Type: Editorial
Reported by: Teco Boot <[email-masked]>

Section: 4.1.4

Original Text
-------------
   An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
   example, if an IPv4 packet arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and IP,
   does not fit in the available path MTU towards its LCCE peer, the
   local LCCE may perform IPv4 fragmentation on the packet before tunnel
   encapsulation. 

Corrected Text
--------------
   An LCCE MAY fragment a packet before encapsulating it in L2TP.  For
   example, if an IPv4 packet with DF=0 arrives at an LCCE from a Remote System
   that, after encapsulation with its associated framing, L2TP, and IP,
   does not fit in the available path MTU towards its LCCE peer, the
   local LCCE may perform IPv4 fragmentation on the packet before tunnel
   encapsulation. 

Notes
-----
Following RFC 791, IPv4 packets with the DF flag set shall not fragment such packets. RFC 3931 shall not make a precedent for fragmenting IPv4 packets with DF=1.

Instructions:
-------------
This errata is currently posted as "Reported". If necessary, please
use "Reply All" to discuss whether it should be verified or
rejected. When a decision is reached, the verifying party (IESG)
can log in to change the status and edit the report, if necessary. 

--------------------------------------
RFC3931 (draft-ietf-l2tpext-l2tp-base-15)
--------------------------------------
Title               : Layer Two Tunneling Protocol - Version 3 (L2TPv3)
Publication Date    : March 2005
Author(s)           : J. Lau, Ed., M. Townsley, Ed., I. Goyret, Ed.
Category            : PROPOSED STANDARD
Source              : Layer Two Tunneling Protocol Extensions
Area                : Internet
Stream              : IETF
Verifying Party     : IESG

---

From: Carlos Pignataro <[email-masked]>
Date: Fri, 22 Apr 2011 00:08:06 -0400

Hi,

Please find an initial comment on this erratum, my 2¢ as an individual:

I appreciate the need to precision, and just followed the discussion
about DF and ip.ident, in Int-area.

However, I do not agree with the interpretation that supports this
change, and I have a different read of the second para of S4.1.4 of RFC
3931. The text in question says:

   For

And the key here is "the local LCCE may perform IPv4 fragmentation".
Performing IPv4 fragmentation does not imply that the result is
fragmenting a datagram (or a fragment). The result of the fragmentation
procedure can just be check the DF and discard.

When RFC 791 describes the fragmentation procedures, the first step is
to compare the TL with the MTU, and if the TL > MTU then check the DF,
and discard the datagram if DF is set. That is, check DF and discard is
part of the "fragmentation procedure". This means that "perform IPv4
fragmentation" can be: if the datagram is too big for the tunnel, then
check DF and if set then drop and send an ICMP3/4 to the source (with a
Next-Hop MTU that accounts for the tunnel encap). I am aware of
implementations that work like this. And this allows for PMTUD to work
as if the tunnel is just another link.

Excerpts of RFC 791 that support this are:

    An Example Fragmentation Procedure

      Procedure:

        IF TL =< MTU THEN Submit this datagram to the next step
             in datagram processing ELSE IF DF = 1 THEN discard the
        datagram ELSE
        To produce the first fragment:

The paragraph of RFC3931 describes pre-fragmentation (i.e.,
fragmentation before encapsulation). This is further covered in the
later S3.4 of RFC 4459:

http://tools.ietf.org/html/rfc4459#section-3.4

3.4.  Fragmentation of the Inner Packet

   A final possibility is fragmenting the inner packet, before
   encapsulation, in such a manner that the encapsulated packet fits in
   the tunnel's path MTU (discovered using PMTUD).  However, one should
   note that only IPv4 supports this "in-flight" fragmentation;
   furthermore, it isn't allowed for packets where the Don't Fragment
   bit has been set.  Even if one could ignore IPv6 completely, so many
   IPv4 host stacks send packets with the DF bit set that this would
   seem unfeasible.

Based on this, I'd recommend rejecting this erratum.

Thanks,

-- Carlos.

On 4/4/2011 10:19 AM, RFC Errata System wrote:
> _______________________________________________
> L2tpext mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/l2tpext
>

---

From: Teco Boot <[email-masked]>
Date: Fri, 22 Apr 2011 10:27:20 +0200

Hello Carlos,

Thanks clearing this up. I agree on your argumentation that text already
is clear that IPv4 packets with DF=1 shall not be fragmented. That is why
I used type Editorial.
But others used this RFC as example that fragmenting DF=1 packets is legal.

Thanks, Teco

---

From: "Carlos Pignataro (cpignata)" <[email-masked]>
Date: Fri, 22 Apr 2011 08:10:37 -0400

Thank you, Teco. IMHO, using this as such example is stretching the meaning beyond reasonable. The text (or other similar ones) do not say that TTL/HL is decremented when forwarding a packet either... But I do not see a reason to add that explicitly. 

Carlos P.

On Apr 22, 2011, at 4:27 AM, "Teco Boot" <[email-masked]> wrote:

>> Please find an initial comment on this erratum, my 2Â¢ as an individual:
>>

---

From: Ignacio Goyret <[email-masked]>
Date: Fri, 22 Apr 2011 10:55:46 -0700

Hi Carlos,
I agree with you. There is no need to explicitly mention the
DF check: that is implied by the IPv4 fragmentation process
as described in RFC791.
I also reject the errata.
-Ignacio