[Bug 48] conntrack breaks udp path mtu discovery
Thu, 26 Feb 2004 00:30:58 +0100
------- Additional Comments From email@example.com 2004-02-26 00:30 -------
Hi Harald, sorry for bother you again.
I agree with you that the solution I've proposed isn't applicable, but I think
that conntrack really shouldn't break path MTU discovery.
In IPv4 this conntrack behaviour (although is not correct) isn't a big problem
because it produces IP datagrams with DF not set: intermediate routers can
fragment again datagrams so that they can reach destination (source will think
that it has guessed a good path MTU).
However, now that netfilter has a new (experimental) l3-indipendent conntrack
(developed by Yasuyuki Kozakai), we must face a similar problem with IPv6. UDP
packets in IPv6 datagrams could be fragmented at source, but they will never be
fragmented by intermediate routers.
So if we follow the IPv4 conntrack modus operandi we will always produce IPv6
fragments of a certain (output interface MTU ?) size independently of the size
of original fragments. If source performs path MTU discovery and for that it
has to reduce the size of fragments, conntrack will make it impossible.
More generally, if we must modify original IPv6 fragments, we must preserve
their size (or at least their maximum size)...
------- You are receiving this mail because: -------
You are on the CC list for the bug, or are watching someone who is.