headers
RFC Errata System | 4 Apr 2011 16:19
Favicon

[Editorial Errata Reported] RFC3931 (2766)


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 <teco <at> inf-net.nl>

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
(Continue reading)

Permalink | Reply | 4 comments |
headers
Carlos Pignataro | 22 Apr 2011 06:08
X-Face
Picon
Favicon

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
(Continue reading)

Permalink | Reply | 3 comments |
headers
Teco Boot | 22 Apr 2011 10:27
Picon

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".
(Continue reading)

Permalink | Reply | 1 comment |
headers
Carlos Pignataro (cpignata | 22 Apr 2011 14:10
Picon
Favicon

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" <teco <at> inf-net.nl> 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:
(Continue reading)

Permalink | Reply | 0 comments |
headers
Ignacio Goyret | 22 Apr 2011 19:55
Favicon

Re: [Editorial Errata Reported] RFC3931 (2766)

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.
(Continue reading)

Permalink | Reply | 0 comments |

Gmane