Re: [Editorial Errata Reported] RFC3931 (2766)

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 protected]> wrote:

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