Ok. This looks doable. I expect to run into trouble along the way, but I don't have any more objections for now. Did you receive my second mail from that day? (https://marc.info/?l=netfilter-devel&m=158700165716521&w=2) I won't hold it against you if you refuse the bridge, I just need something to tell my users. On Sat, Apr 18, 2020 at 1:25 PM Laura Garcia <nevola@xxxxxxxxx> wrote: > > On Wed, Apr 15, 2020 at 11:41 PM Alberto Leiva <ydahhrk@xxxxxxxxx> wrote: > > > > > Looking at the code, the pool4db is pretty much an adaptation of what > > > conntrack already does. So, why not to put the efforts in extending > > > conntrack to support NAT64/NAT46 ? > > > > Ok, please don't take this as an aggressively defensive gesture, but I > > feel like this is an unfair question. > > > > Sorry, but I don't get your point. What I meant is that both pool4db > and conntrack are natting machines, so extending conntrack (which is > already integrated in the kernel) with what pool4db does could be a > good way to go. > > Anyway, please let me come back to the technical discussion. > > > If I provide a ready and simple but effective means to bridge our > > projects I feel like it befalls on you to justify why you wish to > > commit to the far more troublesome course of action. > > > > Merging the projects seems to me like several (if not many) months > > worth of development and testing, little of which would be made in > > benefit of our users. (No real functionality would be added, and some > > functionality might be dropped--eg. atomic configuration, session > > synchronization.) > > > > Atomic configuration is already supported in nftables and extending > conntrack all the security functionalities and session replication > with conntrackd will be also available. > > > I mean I get that you want to avoid some duplicate functionality, but > > is this really a more important use of my time than, say, adding MAP-T > > support? ([0]) > > > > > This way, the support of this natting is likely to be included in the > > > kernel vanilla and just configure it with just one rule: > > > > > > sudo nft add rule inet table1 chain1 dnat 64 64:ff9b::/96 > > > > Ok, but I don't think an IP translator is *meant* to be configured in > > a single line. Particularly in the case of NAT46. How do you populate > > a large EAM table ([1]) on a line? If your translator instance is > > defined entirely in a rule matched by IPv6 packets, how do you tell > > the corresponding IPv4 rule to refer to the same instance? > > > > nft supports maps generation from user space, so something like this > could be configured: > > table inet my_table { > map my_eamt { > type ipv4_addr : ipv6_addr; > flags interval; > elements = { 192.0.2.1/32 : 2001:db8:aaaa::5/128, > 198.51.100.0/24 : 2001:db8:bbbb::/120, > 203.0.113.8/29 : 2001:db8:cccc::/125 } > } > } > > And then, use this map to perform the nat rule: > > nft add rule inet my_table my_chain snat ip saddr to @my_eamt > > Currently, the map structure doesn't work cause the second item should > be a singleton, but probably it can be fixed easily. > > > It is my humble opinion that some level of separation between nftables > > rules and translator instances is clean design. > > > > My humble opinion is that this model will be hard to accept after the > great efforts done with nftables that joins different commands that > were used in the age of iptables. > > > > One more thing, it seems that jool only supports PREROUTING, is that right? > > > > Yes, although this might presently only be because nobody has asked elsewhat. > > > > I tried adding LOCAL_OUT support some years ago and forgot to write > > down the problems that prevented me from succeeding. I can give it > > another shot if this is important for you. > > > > My concern is that this can break the normalization of having source > nat in the postrouting instead of in the prerouting phase. Note that > integrating a new feature must ensure not breaking other subsystems. > > Cheers.
