[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4B98B4FC.50904@cn.fujitsu.com>
Date: Thu, 11 Mar 2010 17:16:44 +0800
From: Shan Wei <shanwei@...fujitsu.com>
To: YOSHIFUJI Hideaki <hideaki.yoshifuji@...il.com>
CC: Patrick McHardy <kaber@...sh.net>,
David Miller <davem@...emloft.net>,
Alexey Dobriyan <adobriyan@...il.com>,
Yasuyuki KOZAKAI <yasuyuki.kozakai@...hiba.co.jp>,
"netdev@...r.kernel.org" <netdev@...r.kernel.org>,
netfilter-devel@...r.kernel.org,
"yoshfuji@...ux-ipv6.org >> YOSHIFUJI Hideaki"
<yoshfuji@...ux-ipv6.org>
Subject: Re: [RFC PATCH net-next 0/7 v2]IPv6:netfilter: defragment
yoshifuji-san:
YOSHIFUJI Hideaki wrote, at 03/11/2010 01:13 AM:
> Well, because the context of defragment are different
> from standard ones (e.g., In netfilter, defragment can
> happen even on forwarding path, and the result is always
> thrown away anyway), I think it is not a good idea to
> touch standard MIB here. However I'm okay to increment
> other stats like InDiscards, OurDiscards and netfilter
> specific stats.
Not only on router, but also on host, if conntrack fails to reassemble
fragments, the fragments will not be forwarded to IPv4/IPv6 stack.
So, these fragments can't be traced from MIB counter.
And, IPv4 conntrack records these fragments.
Is the context of IPv4 defragment different from IPv6?
> 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.
--
Best Regards
-----
Shan Wei
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists