YOSHIFUJI Hideaki wrote:

Hello.

Sorry for my slow response.

(2010/03/16 1:27), Patrick McHardy wrote:

quoted

YOSHIFUJI Hideaki wrote:

quoted

(2010/03/11 18:16), Shan Wei wrote:

quoted

quoted

On the other hand, I'd even say we should NOT send
icmp here (at least by default) because standard routers
never send such packet.

Yes，for routers, the patch-set does not send icmp message to
source host. It only does on destination host with IPv6 connection
track enable.

Please make it optional (via parameter) at least.

The ICMP messages are only sent if the packet is destined for the
local host, similar to what IPv6 defrag would do if conntrack wouldn't
be used. So this patch increases consistency, why should we make this
optional?

Well, in the first place, I do think conntrack should be
transparent as much as possible.  And, I cannot find other
netfilter conntrack code (ipv4 or ipv6) sending icmp e.g.
parameter problem etc.

Agreed on the transparent part, however I consider silently dropping
packets not transparent. In fact conntrack itself should never drop
packets except under some very special circumstances when there's
no other choice in order to operate correctly. Dropping packets is
supposed to be a policy decision made by the user.

In this case without conntrack, IPv6 would send an ICMPv6 message,
so in my opinion the transparent thing to do would be to still send
them. Of course only if reassembly is done on an end host.

There's really no difference in sending these packets from conntrack
compared to passing the incomplete fragments upwards to IPv6 and
waiting for another timeout, except that its easier to implement
consistently by generating the packets within conntrack.

As I said before, I agree that netfilter may drop packets
by any reasons, but I do think it should be done silently.
It can increment netfilter's own statistic counting etc.
but it should not increment the core's (especially,
specific) statistic counting.

It really depends on what you define as "transparent".

Reassembling processes are the same.  We should NOT send icmp, and
if ever desired, we might optionally send icmp (in other
module maybe). 

Please see above for my reasoning. There's also the matter of consistency
between IPv4 and IPv6 conntrack.