From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [PATCH 0/2] IPv6 conntrack support for neighbour discovery Date: Mon, 26 Jan 2009 14:11:37 +0100 Message-ID: <497DB689.3020109@trash.net> References: <1232701347.32071.13.camel@khasse.inl.fr> <200901231021.n0NALINO007201@toshiba.co.jp> <1232707890.32071.41.camel@khasse.inl.fr> <200901231110.n0NBAR7Z000645@toshiba.co.jp> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15; format=flowed Content-Transfer-Encoding: 7bit Cc: eric@inl.fr, Marek.Szuba@if.pw.edu.pl, netfilter-devel@vger.kernel.org, vstinner@inl.fr, pablo@netfilter.org To: Yasuyuki KOZAKAI Return-path: Received: from stinky.trash.net ([213.144.137.162]:43458 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1750738AbZAZNLm (ORCPT ); Mon, 26 Jan 2009 08:11:42 -0500 In-Reply-To: <200901231110.n0NBAR7Z000645@toshiba.co.jp> Sender: netfilter-devel-owner@vger.kernel.org List-ID: Yasuyuki KOZAKAI wrote: > From: Eric Leblond > Date: Fri, 23 Jan 2009 11:51:30 +0100 > >>> I prefer 'NEW' rather than 'UNTRACKED' as other protocols which >>> validation is unclear. So another solution is to let the connection >>> tracking subsystem to create a new conntrack and to make >>> nf_contrack_proto_icmpv6 assign 0 as timeout. How do you think ? >> If we do that, we can have nfnetlink messages (NEW, DESTROY) send to >> userspace. Personnaly, I don't think they are necessary. But there is an >> other issue: as we can't invert the tuple, the information provided to >> userspace will be false. >> >> Once we agree on this last point, I will send a reworked patchset (with >> at least the removal of sysctl stuff). > > Thank you. I understand why ICMPv6 packets are special here and > I agree to assign UNTRACKED to them. Indeed non-invertible tuple might > bring issues. How about adding a flag to indicate that only one direction of the tuple exists? It makes sense to support this for other kinds of simplex flows as well in my opinion and it somewhat goes in the same direction as the patch I talked about during the workshop to have only a single tuple within the conntrack and have reply tuples or potentially other tuples that relate to a connection within the ct_extend area. And using NEW and having netlink events seems more consistent to me.