netfilter-devel.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Patrick McHardy <kaber@trash.net>
To: Yasuyuki KOZAKAI <yasuyuki.kozakai@toshiba.co.jp>
Cc: eric@inl.fr, Marek.Szuba@if.pw.edu.pl,
	netfilter-devel@vger.kernel.org, vstinner@inl.fr,
	pablo@netfilter.org
Subject: Re: [PATCH 0/2] IPv6 conntrack support for neighbour discovery
Date: Tue, 27 Jan 2009 11:14:43 +0100	[thread overview]
Message-ID: <497EDE93.9000606@trash.net> (raw)
In-Reply-To: <200901271009.n0RA9d4I025010@toshiba.co.jp>

Yasuyuki KOZAKAI wrote:
> From: Patrick McHardy <kaber@trash.net>
> Date: Mon, 26 Jan 2009 14:11:37 +0100
> 
>>> 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.
> 
> It sounds good for long term solution. For now Eric's patch is enough,
> I think.

OK, thanks.

> And sorry, I don't remember your patch in detail since maybe nftables talk
> was impressive to me ;) but it sounds that it will make easier to implement
> a module to track protocols using broadcast. 

:) Yes, that was one of the ideas. The other one was that f.i. protocols
like SIP don't actually care about the network identitities of their
flows and might send traffic related to a single logical connection on
multiple different flows. I'm hoping that allowing more than two tuples
per conntrack will help with proper tracking.

      parent reply	other threads:[~2009-01-27 10:14 UTC|newest]

Thread overview: 26+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-10-30 13:52 IPv6 conntrack support for neighbour discovery Marek Szuba
2008-11-04 14:06 ` Patrick McHardy
2008-11-05  4:44   ` Yasuyuki KOZAKAI
     [not found]   ` <200811050444.mA54i7F8028119@toshiba.co.jp>
2008-11-05  9:50     ` Patrick McHardy
2008-11-05 12:40       ` Marek Szuba
2008-11-05 12:48         ` Patrick McHardy
2008-11-05 13:01         ` Yasuyuki KOZAKAI
     [not found]   ` <200811050444.mA54i7XU020102@toshiba.co.jp>
2008-11-05 12:35     ` Marek Szuba
2009-01-21 23:41       ` [PATCH 0/2] " Eric Leblond
2009-01-21 23:43         ` [PATCH 1/2] netfilter: use sysctl to choose icmpv6 autoconf behaviour Eric Leblond
2009-01-21 23:43         ` [PATCH 2/2] netfilter: don't track ICMPv6 negotiation message Eric Leblond
2009-01-21 23:49           ` Eric Leblond
2009-01-21 23:51             ` [Resend PATCH " Eric Leblond
2009-01-23 10:21           ` [PATCH 0/2] IPv6 conntrack support for neighbour discovery Yasuyuki KOZAKAI
2009-01-23  7:40         ` Yasuyuki KOZAKAI
2009-01-23  9:02           ` Eric Leblond
2009-01-23  9:42             ` Jozsef Kadlecsik
2009-01-23  9:50               ` Jozsef Kadlecsik
2009-01-23 10:42                 ` Yasuyuki KOZAKAI
     [not found]             ` <200901231021.n0NALINO007201@toshiba.co.jp>
2009-01-23 10:51               ` Eric Leblond
2009-01-23 11:10                 ` Yasuyuki KOZAKAI
2009-01-24 10:32                   ` [PATCH] netfilter: don't track ICMPv6 negotiation message Eric Leblond
2009-01-27 10:07                     ` Yasuyuki KOZAKAI
     [not found]                 ` <200901231110.n0NBAR7Z000645@toshiba.co.jp>
2009-01-26 13:11                   ` [PATCH 0/2] IPv6 conntrack support for neighbour discovery Patrick McHardy
2009-01-27 10:09                     ` Yasuyuki KOZAKAI
     [not found]                     ` <200901271009.n0RA9d4I025010@toshiba.co.jp>
2009-01-27 10:14                       ` Patrick McHardy [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=497EDE93.9000606@trash.net \
    --to=kaber@trash.net \
    --cc=Marek.Szuba@if.pw.edu.pl \
    --cc=eric@inl.fr \
    --cc=netfilter-devel@vger.kernel.org \
    --cc=pablo@netfilter.org \
    --cc=vstinner@inl.fr \
    --cc=yasuyuki.kozakai@toshiba.co.jp \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).