* ip_rt_min_pmtu
@ 2012-12-04 21:04 Christopher Schramm
2012-12-05 8:46 ` ip_rt_min_pmtu Rami Rosen
0 siblings, 1 reply; 3+ messages in thread
From: Christopher Schramm @ 2012-12-04 21:04 UTC (permalink / raw)
To: netdev
Hi,
I'm looking into an interesting detail of the Linux IPv4 implementation
I stumbled upon during a University course.
In route.c there's a value ip_rt_min_pmtu, defined as 512 + 20 + 20,
that tells Linux a minimum PMTU to use, even if e. g. an ICMP message
tells it to set a smaller one.
Of course, this is not a problem in real world, but not
standard-compliant, since RFC 791 defines a minimum MTU of 68 for IPv4.
So I wonder what's the reason for the restriction.
I looked into it and found that it appeared in Linux 2.3.15 with the
following ID in route.c:
v 1.71 1999/08/20 11:05:58 davem
While it was not present in Linux 2.3.14 with:
v 1.69 1999/06/09 10:11:02 davem
I couldn't find any related discussion or patch on the LKML around that
dates, so I'm asking you for any hints to find out the reason for
implementing this lower bound.
What I've found on the LKML is a topic around February 15th, 2001,
titled "MTU and 2.4.x kernel", where Alexey Kuznetsov points out that
the handling of "DF on syn frames" is broken for MTUs smaller than 128
and "Preventing DoSes requires to block pmtu discovery at 576 or at
least 552".
Does anybody know the actual reason for the change in 2.3.15? I first
thought it's the common misinterpretation that 576 would be the lower
bound for MTUs in IPv4, but I wonder why it was put in place as a patch
years after the IPv4 implementation was already done. There seems to
have been some clear reason for it. I also wonder why it has never been
removed up to today if it's really nothing more than a mistake.
Would be great if someone could help me shed some light on this.
Regards
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ip_rt_min_pmtu
2012-12-04 21:04 ip_rt_min_pmtu Christopher Schramm
@ 2012-12-05 8:46 ` Rami Rosen
2012-12-05 9:33 ` ip_rt_min_pmtu Christopher Schramm
0 siblings, 1 reply; 3+ messages in thread
From: Rami Rosen @ 2012-12-05 8:46 UTC (permalink / raw)
To: Christopher Schramm; +Cc: netdev
Hi,
Just a short note:
RFC 791 indeed set 68 for internet module MTU.
But RFC 791 also declares 576 as PMTU:
"All hosts must be prepared to accept datagrams of up to 576 octets".
and it says also:
"The number 576 is selected to allow a reasonable sized data block to
be transmitted in addition to the required header information."
It seems that there is a distinction between a module sending MTU and
hosts receiving MTU.
Regarding the historical details of why it was sent at that time -
I don't have an idea.
Regards,
Rami Rosen
http://ramirose.wix.com/ramirosen
On Tue, Dec 4, 2012 at 11:04 PM, Christopher Schramm
<netdev@shakaweb.org> wrote:
> Hi,
>
> I'm looking into an interesting detail of the Linux IPv4 implementation I
> stumbled upon during a University course.
>
> In route.c there's a value ip_rt_min_pmtu, defined as 512 + 20 + 20, that
> tells Linux a minimum PMTU to use, even if e. g. an ICMP message tells it to
> set a smaller one.
>
> Of course, this is not a problem in real world, but not standard-compliant,
> since RFC 791 defines a minimum MTU of 68 for IPv4. So I wonder what's the
> reason for the restriction.
>
> I looked into it and found that it appeared in Linux 2.3.15 with the
> following ID in route.c:
>
> v 1.71 1999/08/20 11:05:58 davem
>
> While it was not present in Linux 2.3.14 with:
>
> v 1.69 1999/06/09 10:11:02 davem
>
> I couldn't find any related discussion or patch on the LKML around that
> dates, so I'm asking you for any hints to find out the reason for
> implementing this lower bound.
>
> What I've found on the LKML is a topic around February 15th, 2001, titled
> "MTU and 2.4.x kernel", where Alexey Kuznetsov points out that the handling
> of "DF on syn frames" is broken for MTUs smaller than 128 and "Preventing
> DoSes requires to block pmtu discovery at 576 or at least 552".
>
> Does anybody know the actual reason for the change in 2.3.15? I first
> thought it's the common misinterpretation that 576 would be the lower bound
> for MTUs in IPv4, but I wonder why it was put in place as a patch years
> after the IPv4 implementation was already done. There seems to have been
> some clear reason for it. I also wonder why it has never been removed up to
> today if it's really nothing more than a mistake.
>
> Would be great if someone could help me shed some light on this.
>
> Regards
> --
> To unsubscribe from this list: send the line "unsubscribe netdev" in
> the body of a message to majordomo@vger.kernel.org
> More majordomo info at http://vger.kernel.org/majordomo-info.html
^ permalink raw reply [flat|nested] 3+ messages in thread
* Re: ip_rt_min_pmtu
2012-12-05 8:46 ` ip_rt_min_pmtu Rami Rosen
@ 2012-12-05 9:33 ` Christopher Schramm
0 siblings, 0 replies; 3+ messages in thread
From: Christopher Schramm @ 2012-12-05 9:33 UTC (permalink / raw)
To: Rami Rosen; +Cc: netdev
On Wed, 05 Dec 2012 09:46:18 +0100, Rami Rosen wrote:
> But RFC 791 also declares 576 as PMTU:
> "All hosts must be prepared to accept datagrams of up to 576 octets".
That's the common mistake I mentioned. The sentence goes on: "(whether
they arrive whole or in fragments)", so it says nothing about lower
layers, especially not about the MTU.
The 576 octects IP datagram every implementation is required to be able
to handle could be transferred in 12 up to over 60 fragments if we had
the minimal PMTU of 68, depending on the header size. Of course that
leads to an overhead of nearly 90 percent, but it should be possible
following the RFC.
With Linux, trying to send large data over a path with PMTU < 552 will
probably fail (unless you change the min_pmtu value).
^ permalink raw reply [flat|nested] 3+ messages in thread
end of thread, other threads:[~2012-12-05 9:33 UTC | newest]
Thread overview: 3+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2012-12-04 21:04 ip_rt_min_pmtu Christopher Schramm
2012-12-05 8:46 ` ip_rt_min_pmtu Rami Rosen
2012-12-05 9:33 ` ip_rt_min_pmtu Christopher Schramm
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).