Hi, Le vendredi 23 janvier 2009 à 16:40 +0900, Yasuyuki KOZAKAI a écrit : > Hi, Eric, > > How about just using NOTRACK target ? This is a possible solution but you will then have to be a Netfilter Jedi to build a correct IPv6 filtering ruleset. I think even Padawan have no clue about the existence of the NOTRACK target. Seriously speaking, the NOTRACK target is tagged "NETFILTER_ADVANCED" and IPv6 is becoming more and more frequent. I don't think we should use such a complicated solution for simply obtaining an IPv6 address. We will loose quit a bunch of users on this. BR, -- Eric > > -- Yasuyuki Kozakai > > From: Eric Leblond <eric@xxxxxx> > Date: Thu, 22 Jan 2009 00:41:27 +0100 > > > Hi, > > > > Le mercredi 05 novembre 2008 à 13:35 +0100, Marek Szuba a écrit : > > > On Wed, 05 Nov 2008 13:44:05 +0900 (JST) > > > Yasuyuki KOZAKAI <yasuyuki.kozakai@xxxxxxxxxxxxx> wrote: > > > > > > > In short: nf_conntrack_proto_icmpv6.c does not help for protocols > > > > using their messages. conntrack helper is better. > > > So what you are suggesting is, someone needs to write such a helper > > > module. Correct? > > > > I'm reopening this thread because Victor Stinner (in CC) has opened a > > similar bug in bugzilla: > > http://bugzilla.netfilter.org/show_bug.cgi?id=567 > > Pablo has then pointed out this discussion. > > > > I don't think that we have to handle these part of ICMPv6 protocol with > > a connection tracking helper. For example, here's the trace of the > > exchange which are needed to obtain a "public" IPv6 address on my setup: > > > > 15:14:42.377744 IP6 fe80::a00:27ff:feb3:e26c > ff02::2: ICMP6, router solicitation, length 16 > > 15:14:42.405725 IP6 fe80::207:cbff:fe90:f8d1 > ff02::1: ICMP6, router advertisement, length 104 > > 15:14:43.401395 IP6 :: > ff02::1:ffb3:e26c: ICMP6, neighbor solicitation, who has 2a01:e35:1394:5bd0:a00:27ff:feb3:e26c, length 24 > > 15:14:46.628300 IP6 fe80::a00:27ff:feb3:e26c > ff02::16: HBH ICMP6, multicast listener report v2, 1 group record(s), length 28 > > > > If we only analyse the first two, we see we can't easily invert the > > tuple of the connection: we don't know which address will answer and the > > destination address of the packet are changing. But as pointed by > > Yasuyuki the main point is not here, we need to accept the router > > advertisement to be able to detect changes in the routing. In fact, > > theses protocols are stateless and should be considered as such. > > > > IMHO, the main issue here is to tag the packets as INVALID. They are > > valid even we can't track them. I thus propose a patchset which adds the > > capability to avoid connection tracking the packets of these protocols. > > A sysctl flag can be set to activate this feature. > > > > With this patchset, the concerned packet don't get blocked by the > > INVALID rule and are not seen by the conntrack. They can be cleanly > > filtered in the ruleset. > > > > Patchset statistics: > > net/ipv6/netfilter/nf_conntrack_proto_icmpv6.c | 35 +++++++++++++++++++++++- > > 1 files changed, 34 insertions(+), 1 deletions(-) > -- > To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in > the body of a message to majordomo@xxxxxxxxxxxxxxx > More majordomo info at http://vger.kernel.org/majordomo-info.html -- Éric Leblond <eric@xxxxxx> INL, http://www.inl.fr/ NuFW, http://www.nufw.org
Attachment:
signature.asc
Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e?=
