From mboxrd@z Thu Jan 1 00:00:00 1970 From: Patrick McHardy Subject: Re: [RFC] ecn match ported to ipv6 Date: Thu, 09 Jun 2011 14:20:05 +0200 Message-ID: <4DF0BA75.1070102@trash.net> References: <1307545312.3057.49.camel@edumazet-laptop> <4DEFB213.5030802@trash.net> <4DF081B5.2060102@trash.net> Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-15 Content-Transfer-Encoding: 7bit Cc: Jan Engelhardt , Eric Dumazet , Netfilter Development Mailinglist To: Dave Taht Return-path: Received: from stinky.trash.net ([213.144.137.162]:37928 "EHLO stinky.trash.net" rhost-flags-OK-OK-OK-OK) by vger.kernel.org with ESMTP id S1754355Ab1FIMUG (ORCPT ); Thu, 9 Jun 2011 08:20:06 -0400 In-Reply-To: Sender: netfilter-devel-owner@vger.kernel.org List-ID: On 09.06.2011 14:15, Dave Taht wrote: > On Thu, Jun 9, 2011 at 2:17 AM, Patrick McHardy wrote: >> On 08.06.2011 22:50, Jan Engelhardt wrote: >>> On Wednesday 2011-06-08 19:32, Patrick McHardy wrote: >>> >>>> On 08.06.2011 17:47, Dave Taht wrote: >>>>> On Wed, Jun 8, 2011 at 9:01 AM, Eric Dumazet wrote: >>>>> >>>>>> Dave Taht mentioned in bloat list that netfilter ecn match was ipv4 >>>>>> only. >>>>>> >>>>>> Is there any plan to make the switch from net/ipv4/netfilter/ipt_ecn.c >>>>>> to net/netfilter/xt_ecn.c ? >>>>>> >>>>>> I can probably do it but not before ~ten days, so if someone is >>>>>> interested, this will please Dave ;) >>>> >>>> That should be a relatively quick job, I'll give it a shot while >>>> my dinner is cooking :) >>>> >>>>> The larger question I had was this >>>>> >>>>> "iptables seems to think ecn can only be looked at in TCP streams, where (for >>>>> example), ecn bits can be copied to the outer header of a udp vpn >>>>> stream, and marked >>>>> >>>>> when needed." >>>>> >>>>> ECN is an ip level standard, not just a tcp one. >>>> >>>> That probably needs a new revision and is slightly more work, lets >>>> begin by porting it to IPv6, then we can add this on top. >>> >>> Moving it to xt_ecn first seems like producing a smaller patchset >>> because you don't have to potentially duplicate the functions first. :) >> >> It actually already supports matching on IP header ECN bits: >> >> [!] --ecn-ip-ect [0..3] Match ECN codepoint in IPv4 header >> > > Sorry, my bad. It's even documented as existing. > > So it's just a pair of convienence functions ( > --ecn-ip-ece --ecn-ip-cwr ) Yeah, that would make usage easier. > and ipv6 iptables support for ECN that are MIA. Sent out patches a few seconds ago. > I'll argue that extending the blackhole-ing feature to also include ip > > --ecn-tcp-remove > > might be good... although in my testing I have not found a blackhole > yet, they must still be out there. That would be the ECN target, not the match.