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/