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/