Re: [Editorial Errata Reported] RFC3931 (2766)

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
   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.

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:
> 
> 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 protected]>
> 
> 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
> _______________________________________________
> L2tpext mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/l2tpext
>