Ok, my point of view has changed. Sorry; I'm trying to reconcile the interests of different parties. Here's the thing: Creating a bridge between nftables and Jool, and merging Jool into nftables, are (from my perspective) separate tasks. The former is simple, the latter is longterm. My current pull request attempts to address the former, but not the latter. The former task is [0], and the latter is [1]. According to Jool's feature survey ([2]), a majority of my opinionated users want the nftables/Jool bridge, another majority wants me to implement MAP-T. Unfortunately, I lack the number of users who want me to perform a formal merge between nftables and Jool, but I presume that it has diminished ever since Jool was packaged for different distributions. (Since installation is no longer a daunting task.) However, I do acknowledge that merging Jool into nftables is the right course of action, and I would like to commit in this direction. So I propose the following order of events: 1. Merge the bridge into nftables. This will give a temporary early solution for those who want it. 2. Implement MAP-T. 3. Merge Jool into nftables. 4. Deprecate the bridge, and eventually remove it. Is this an acceptable compromise? Alberto [0] https://github.com/NICMx/Jool/issues/285 [1] https://github.com/NICMx/Jool/issues/273 [2] https://docs.google.com/forms/d/e/1FAIpQLSe_9_wBttFGd9aJ7lKXiJvIN7wWZm_C6yy3gU0Ttepha275nQ/viewanalytics On Wed, Apr 15, 2020 at 4: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. > > 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.) > > 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? > > It is my humble opinion that some level of separation between nftables > rules and translator instances is clean design. > > > 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. > > Cheers, > Alberto > > [0] https://tools.ietf.org/html/rfc7599 > [1] https://jool.mx/en/eamt.html > > On Wed, Apr 8, 2020 at 2:22 PM Laura Garcia <nevola@xxxxxxxxx> wrote: > > > > On Tue, Apr 7, 2020 at 8:03 PM Alberto Leiva Popper <ydahhrk@xxxxxxxxx> wrote: > > > > > > Jool statements are used to send packets to the Jool kernel module, > > > which is an IP/ICMP translator: www.jool.mx > > > > > > Sample usage: > > > > > > modprobe jool > > > jool instance add "name" --iptables -6 64:ff9b::/96 > > > sudo nft add rule inet table1 chain1 jool nat64 "name" > > > > > > > Hi Alberto, > > > > 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 ? > > > > 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 > > > > One more thing, it seems that jool only supports PREROUTING, is that right? > > > > Cheers.
