Pablo Neira Ayuso <pablo@xxxxxxxxxxxxx> wrote: > Florian Westphal is currently exploring alternative solutions so > br_netfilter can stop (ab)using the layer 3 infrastructure from the > bridge code (this layering violation has been causing problems for > quite some time, eg. some users don't expect a bridge to modify alter > the fragmented traffic). > > Although IPv6 support in br_netfilter is fairly incomplete, let me put > these patches in a hold until Florian comes back to us with some > feedback, we'll integrate them in some way or another at some point. TBH I am not too sure abut this. IPv4 DNAT doesn't work 100% either, see http://marc.info/?l=linux-netdev&m=136627779125382&w=2 [ btw, thanks that the crap patch referenced above didn't end up in the kernel ;) ] So I think we first need to _clearly_ define how DNAT should work on a bridge, rather than inherit all the weird corner cases that we have with ipv4. F.e. I think we wouldn't have all of these issues if we wouldn't care about the l2 mac address (and would always route in NAT case). But I'll have to think about this some more. In any case, I understand that not being able to e.g. REDIRECT is bad, and perhaps it would be preferable to first fix ipv6 fragment handling and then make REDIRECT work (and defer handling/supporting arbitrary DNAT until we think we know how it should work). One small comment on the patch below. > > @@ -57,6 +58,7 @@ static inline unsigned int nf_bridge_pad(const struct sk_buff *skb) > > struct bridge_skb_cb { > > union { > > __be32 ipv4; > > + struct in6_addr ipv6; > > } daddr; This is gone, dnat_took_place() should work without further changes if you call it in the ipv6 prerouting finish hook. > > +/* This requires some explaining. If DNAT has taken place, > > + * we will need to fix up the destination Ethernet address. > > + * I really think this novel^W comment should not be copied, just add a reference to the ipv4 one. -- To unsubscribe from this list: send the line "unsubscribe netfilter-devel" in the body of a message to majordomo@xxxxxxxxxxxxxxx More majordomo info at http://vger.kernel.org/majordomo-info.html
