netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
* 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).