Re: [Editorial Errata Reported] RFC3931 (2766)

Ignacio Goyret <[email protected]> Fri, 22 Apr 2011 10:55:46 -0700
Newsgroups gmane.ietf.l2tpext
Message-ID <[email protected]>
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

At 12:08 AM 4/22/2011 -0400, Carlos Pignataro wrote:
>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
>>