Re: [PATCH] IPv6 dnat/snat support

Jan Engelhardt <[email protected]> Fri, 8 Feb 2008 01:32:39 +0100 (CET)
Newsgroups gmane.linux.network.bridge.ebtables.devel
Message-ID <[email protected]>
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.

>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.

>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;

-------------------------------------------------------------------------
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/