Re: [Editorial Errata Reported] RFC3931 (2766)

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


Op 22 apr 2011, om 06:08 heeft Carlos Pignataro het volgende geschreven:

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