Re: [PATCH] IPv6 dnat/snat support

"Tseng, Kuo-Lang" <[email protected]> Thu, 7 Feb 2008 17:03:17 -0800
Newsgroups gmane.linux.network.bridge.ebtables.devel
Message-ID <3F25FE8C477E9E4FB3D42C2FF937C08A85CB14@orsmsx423.amr.corp.intel.com>
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/