Re: [PATCH] IPv6 dnat/snat support

Bart De Schuymer <[email protected]> Fri, 08 Feb 2008 19:20:54 +0100
Newsgroups gmane.linux.network.bridge.ebtables.devel
Message-ID <[email protected]>
Hi Kuo,

Thanks for your patch. The patch looks ok. Tiny comment: the header
diffs belong in the kernel patch and the userspace patch lacks a man
page update.
Seems like we'll need a merge of the two kernel patches and extra
userspace code.

I was gonna give my say about posting to netfilter-devel only, without
userspace code, but I guess I'm better off restraining myself from doing
that.

cheers,
Bart

Op do, 07-02-2008 te 17:03 -0800, schreef Tseng, Kuo-Lang:
> Jan Engelhardt wrote on Thursday, February 07, 2008 4:33 PM:
> 
> > On Feb 7 2008 15:59, Tseng, Kuo-Lang wrote:
> >> Jan Engelhardt wrote on Wednesday, February 06, 2008 4:33 PM:
> >>> On Feb 6 2008 16:14, Tseng, Kuo-Lang wrote:
> >>> 
> >>>>>>> I would like to find out if there is any IPv6 support in
> >>>>>>> ebtables for replacing MAC address of the Ethernet header based
> >>>>>>> on TCP or UDP port id in IPv6 packets. I would appreciate it if
> >>>>>>> there is anyone on this list who knows of any prior work in
> >>>>>>> ebtables to support IPv6.
> >>> 
> >>> Sorry; I only monitor ebtables-devel since recently,
> >>> an ebt_ip6 match has been posted at
> >>> http://marc.info/?l=netfilter-devel&m=120182168424052&w=2
> >>> 
> >>> I am not to keen to add layer-4 parsing to ebt code; instead,
> >>> it should (ideally) interface with Xtables.
> >> 
> >> We are not adding any new functionality. This only extends ebtables
> >> adding Layer 4 Port Based NAT for IPv6, which is already present for
> >> IPv4. This is efficient and is consistent with the current
> >> Functionality (this involves only few lines of code (see my patch)
> >> and matches the same way today ebtables is doing for v4).
> > 
> > Yes I see.
> 
> Thanks. Will you please then merge the port-based NATing code from my
> patch in?
> 
> > 
> >> A few comments to the br-netfilter patch you posted in that link:
> >> 
> >> 1.
> >> +	if ((info->match_flags & EBT_IP6_NEXTHDR) &&
> >> +	    (iph->nexthdr != info->nexthdr) ^
> >> +	    !!(info->invert_flags & EBT_IP6_NEXTHDR))
> >> +		return EBT_NOMATCH;
> >> 
> >> This is not sufficient and is broken if you got options headers in
> >> between the v6 header and the protocol header that you wish to match.
> > 
> > I was not sure about that - is there a way other than ->nexthdr==OPT
> > to distinguish from headers that should be skipped and those that
> > should not? I am sort of thinking of TCP-in-IPv6-in-IPv6.
> 
> Not any fast way that I know. But you meant to match just 
> layer-4 protocol, you can use ipv6_skip_exthdr() function which will 
> save you some work (e.g. the code used in my patch): 
> 
>         offset_ph = ipv6_skip_exthdr(skb, sizeof(_ip6h), nexthdrp);
>         if (offset_ph == -1)
>             return EBT_NOMATCH;
>         if (FWINV(info->protocol != *nexthdrp, EBT_IP6_PROTO))
>             return EBT_NOMATCH;
> 
> > 
> >> 2. You could use the macro FWINV and same name for the mask field,
> >> bitmask, so that this module is consistent with other protocol
> >> modules in br-netfilter.
> > 
> > Almost none of the other netfilter code uses FWINV, most likely
> > because it's just too scary. The last remnants are in core
> > ipv4/netfilter/ and ipv6/netfilter, and the extension modules
> > only have one instance in xt_conntrack.c, which is going away
> > anyway:
> > 
> >                 if (FWINV((statebit & sinfo->statemask) == 0,
> >                           XT_CONNTRACK_STATE))
> >                         return false;
> > 
> > this is much clearer for the same amount of code:
> > 
> >                 if ((info->state_mask & statebit) ^
> >                     !(info->invert_flags & XT_CONNTRACK_STATE))
> >                         return false;
> 
> OK.
> 
> 
> -------------------------------------------------------------------------
> This SF.net email is sponsored by: Microsoft
> Defy all challenges. Microsoft(R) Visual Studio 2008.
> http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/
> _______________________________________________
> Ebtables-devel mailing list
> [email protected]
> https://lists.sourceforge.net/lists/listinfo/ebtables-devel
> 


-------------------------------------------------------------------------
This SF.net email is sponsored by: Microsoft
Defy all challenges. Microsoft(R) Visual Studio 2008.
http://clk.atdmt.com/MRT/go/vse0120000070mrt/direct/01/