> > I would probably suggest implementing this not as netfilter hooks, > but rather as a virtual device (tun/tap/veth/dummy like). > This exactly how I implemented it in early version of my module. I changed to netfilter-hook solution, because it seemed to me that translation process gets faster by doing so. At the other hand netfilter way generates some additional processing (really small) for every received packet, even if it is not dedicated to translation - so it is some kind of trade off. > > From the web page it doesn't sound like there's any actual netfilter > interaction... > Yes , as I wrote in my previous message - my module only registers its functions in netfilter hooks, it doesn't use any other netfilter functionality. > Furthermore, I would hazard a guess that requiring an IPv4 address for > every IPv6 host desiring to connect to an IPv4 address makes > this a little uninteresting.... to quote: > Yes, I agree that it is big constraint, despite that such configuration can be useful in some environment, when one needs to have IPv6 host which should be able to reach IPv4 network from static IPv4 address, reserved to this host only, without port forwarding. It is similar to one of Cisco NAT translation schemes, called Static NAT. I am aware that I would have to implement port forwarding option to make translator more functional. But it is big topic and I do not have time to code it at this moment. I am just looking for review of my kernel module. Lukasz -- 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
