[Bug 48] conntrack breaks udp path mtu discovery

[bugzilla-daemon@netfilter.org]

https://bugzilla.netfilter.org/cgi-bin/bugzilla/show_bug.cgi?id=48





------- Additional Comments From tatonet@tiscali.it  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.