* Adding NAT64 to Netfilter @ 2020-01-03 18:09 Alberto Leiva 2020-01-07 13:00 ` Laura Garcia 2020-01-07 14:14 ` Laurent Fasnacht 0 siblings, 2 replies; 5+ messages in thread From: Alberto Leiva @ 2020-01-03 18:09 UTC (permalink / raw) To: netfilter-devel Hello I've been working on Jool, an open source IP/ICMP translator for a while ([0]). It currently implements SIIT, NAT64 and (if everything goes according to plan) will later this year also support MAP-T. It currently works both as a Netfilter module (hooking itself to PREROUTING) or as an xtables target, and I'm soon going to start integrating it into nftables. Actually, it's the same software once advertised by this guy: [1] Several people have approached me over the years expressing their desire to have it integrated into the kernel by default. The intent of this mail is to query whether a merge of Jool into the Netfilter project woud be well-received. Of course, I'm willing to make adjustments if needed. Here are some justifications that have been listed to me. For the sake of credit, these are all stolen from [2]: 1. IPv6 is getting significantly more exposure 2. NAT64 is getting more required / will be a default thing to do, along with MAP-E/T 3. OpenBSD already has the functionality in pf 4. Enabling it upstream can potentially help IPv6 migration world wide Thoughts? [0] https://jool.mx [1] https://marc.info/?l=netfilter-devel&m=136271576812278&w=2 [2] https://github.com/NICMx/Jool/issues/273#issuecomment-568721875 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding NAT64 to Netfilter 2020-01-03 18:09 Adding NAT64 to Netfilter Alberto Leiva @ 2020-01-07 13:00 ` Laura Garcia 2020-01-07 14:14 ` Laurent Fasnacht 1 sibling, 0 replies; 5+ messages in thread From: Laura Garcia @ 2020-01-07 13:00 UTC (permalink / raw) To: Alberto Leiva; +Cc: Netfilter Development Mailing list On Fri, Jan 3, 2020 at 7:10 PM Alberto Leiva <ydahhrk@gmail.com> wrote: > > Hello > > I've been working on Jool, an open source IP/ICMP translator for a > while ([0]). It currently implements SIIT, NAT64 and (if everything > goes according to plan) will later this year also support MAP-T. It > currently works both as a Netfilter module (hooking itself to > PREROUTING) or as an xtables target, and I'm soon going to start > integrating it into nftables. > Hi Alberto, I was analyzing the impact to add support NAT64/46 several months ago. It seems that you've done a very good job. In regards to the iptables approach, do you have any benchmark compared to the NAT in the same stack? In regards to the nftables approach, do you mean to integrate the RFC implementations natively into the nftables infrastructure? Checking your code, it seems that you use several user space tools (jool, joold) and a conntrack-like table to store the connection data. As you know, in the nftables project it has been done a great effort to avoid several tools for packet mangling so something natively like the following would be probably required. nft add table ip6 nat nft add chain ip6 nat postrouting { type nat hook postrouting priority 100 \; } nft add rule ip6 nat postrouting oif eth0 snat 1.2.3.4 More thorough study would be the possibility of supporting the sessions in conntrack and conntrackd but, I believe a first approach with stateless NAT from ingress could be a great achievement. Cheers. > Actually, it's the same software once advertised by this guy: [1] > > Several people have approached me over the years expressing their > desire to have it integrated into the kernel by default. The intent of > this mail is to query whether a merge of Jool into the Netfilter > project woud be well-received. Of course, I'm willing to make > adjustments if needed. > > Here are some justifications that have been listed to me. For the sake > of credit, these are all stolen from [2]: > > 1. IPv6 is getting significantly more exposure > 2. NAT64 is getting more required / will be a default thing to do, > along with MAP-E/T > 3. OpenBSD already has the functionality in pf > 4. Enabling it upstream can potentially help IPv6 migration world wide > > Thoughts? > > [0] https://jool.mx > [1] https://marc.info/?l=netfilter-devel&m=136271576812278&w=2 > [2] https://github.com/NICMx/Jool/issues/273#issuecomment-568721875 ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding NAT64 to Netfilter 2020-01-03 18:09 Adding NAT64 to Netfilter Alberto Leiva 2020-01-07 13:00 ` Laura Garcia @ 2020-01-07 14:14 ` Laurent Fasnacht 2020-01-07 23:09 ` Alberto Leiva 1 sibling, 1 reply; 5+ messages in thread From: Laurent Fasnacht @ 2020-01-07 14:14 UTC (permalink / raw) To: Alberto Leiva; +Cc: netfilter-devel [-- Attachment #1.1: Type: text/plain, Size: 693 bytes --] Hello, ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote: > Hello > > I've been working on Jool, an open source IP/ICMP translator for a > while ([0]). It currently implements SIIT, NAT64 and (if everything > goes according to plan) will later this year also support MAP-T. It > currently works both as a Netfilter module (hooking itself to > PREROUTING) or as an xtables target, and I'm soon going to start > integrating it into nftables. That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible. Cheers, Laurent ProtonVPN R&D [-- Attachment #1.2: publickey - lf@o-t.ch - 0x0007104B.asc --] [-- Type: application/pgp-keys, Size: 631 bytes --] [-- Attachment #2: OpenPGP digital signature --] [-- Type: application/pgp-signature, Size: 217 bytes --] ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding NAT64 to Netfilter 2020-01-07 14:14 ` Laurent Fasnacht @ 2020-01-07 23:09 ` Alberto Leiva 2020-02-10 18:07 ` Alberto Leiva 0 siblings, 1 reply; 5+ messages in thread From: Alberto Leiva @ 2020-01-07 23:09 UTC (permalink / raw) To: Laurent Fasnacht; +Cc: netfilter-devel Hi! > In regards to the iptables approach, do you have any benchmark > compared to the NAT in the same stack? I think we do, but they are old to the point of pointlessness. But we can allocate some testing efforts in February, if you would confirm the desirability of this information. > In regards to the nftables approach, do you mean to integrate the RFC > implementations natively into the nftables infrastructure? I would say "yes," but I'm not sure we mean the same thing. Jool is currently a box of translating code that interfaces with the kernel by way of wrappers. ie. The Netfilter wrapper receives packets by registering itself to nf_register_hooks(), and the iptables wrapper receives packets by registering itself to xt_register_targets(). What I mean by integrating Jool into nftables is to create a wrapper that would receive packets by means of something like nft_register_expr(). (I'm not entirely sure this is what I'm supposed to do because I haven't started analyzing this task yet. But that would be my starting point.) Does this answer your question? > Checking your code, it seems that you use several user space tools > (jool, joold) and a conntrack-like table to store the connection data. > As you know, in the nftables project it has been done a great effort > to avoid several tools for packet mangling so something natively like > the following would be probably required. I'm not averse to the idea of adapting code to fulfill the standards of the Netfilter project. Jool's core itself has naturally changed substantially over the years to account for emerging RFCs and feature requests. It wouldn't be my first major overhaul. But I admit I don't presently understand how things like the EAM table ([0] [1]) are meant to fit in this model. (Then again, I don't know much about nftables just yet.) [0] https://jool.mx/en/eamt.html [1] https://jool.mx/en/usr-flags-eamt.html > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible. Thank you! :) On Tue, Jan 7, 2020 at 8:14 AM Laurent Fasnacht <lf@o-t.ch> wrote: > > Hello, > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote: > > > Hello > > > > > I've been working on Jool, an open source IP/ICMP translator for a > > while ([0]). It currently implements SIIT, NAT64 and (if everything > > goes according to plan) will later this year also support MAP-T. It > > currently works both as a Netfilter module (hooking itself to > > PREROUTING) or as an xtables target, and I'm soon going to start > > integrating it into nftables. > > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible. > > Cheers, > > Laurent > ProtonVPN R&D ^ permalink raw reply [flat|nested] 5+ messages in thread
* Re: Adding NAT64 to Netfilter 2020-01-07 23:09 ` Alberto Leiva @ 2020-02-10 18:07 ` Alberto Leiva 0 siblings, 0 replies; 5+ messages in thread From: Alberto Leiva @ 2020-02-10 18:07 UTC (permalink / raw) To: Laurent Fasnacht; +Cc: netfilter-devel Hi I have a working prototype of a Jool wrapper for the nftables framework. Details can be found here: [0]. Of course, it's not the full integration you're hoping for (the rules simply send packets to a Jool instance, in accordance to the current model), but it should keep users happy while the transition happens. However, I noticed that nft is not extensible (like iptables), so I need to provide a custom nft build ([1][2]) instead of a plugin. I don't think it's viable to expect my more casual users to build nft if they need cooperation between Jool and nftables, thus I believe I need to propose a merge of this early code into the nftables project. Is this acceptable? [0] https://github.com/NICMx/Jool/issues/285#issuecomment-575400539 [1] https://github.com/ydahhrk/nftables [2] https://github.com/ydahhrk/libnftnl On Tue, Jan 7, 2020 at 5:09 PM Alberto Leiva <ydahhrk@gmail.com> wrote: > > Hi! > > > In regards to the iptables approach, do you have any benchmark > > compared to the NAT in the same stack? > > I think we do, but they are old to the point of pointlessness. But we > can allocate some testing efforts in February, if you would confirm > the desirability of this information. > > > In regards to the nftables approach, do you mean to integrate the RFC > > implementations natively into the nftables infrastructure? > > I would say "yes," but I'm not sure we mean the same thing. > > Jool is currently a box of translating code that interfaces with the > kernel by way of wrappers. > > ie. The Netfilter wrapper receives packets by registering itself to > nf_register_hooks(), and the iptables wrapper receives packets by > registering itself to xt_register_targets(). > > What I mean by integrating Jool into nftables is to create a wrapper > that would receive packets by means of something like > nft_register_expr(). (I'm not entirely sure this is what I'm supposed > to do because I haven't started analyzing this task yet. But that > would be my starting point.) > > Does this answer your question? > > > Checking your code, it seems that you use several user space tools > > (jool, joold) and a conntrack-like table to store the connection data. > > As you know, in the nftables project it has been done a great effort > > to avoid several tools for packet mangling so something natively like > > the following would be probably required. > > I'm not averse to the idea of adapting code to fulfill the standards > of the Netfilter project. Jool's core itself has naturally changed > substantially over the years to account for emerging RFCs and feature > requests. It wouldn't be my first major overhaul. > > But I admit I don't presently understand how things like the EAM table > ([0] [1]) are meant to fit in this model. > > (Then again, I don't know much about nftables just yet.) > > [0] https://jool.mx/en/eamt.html > [1] https://jool.mx/en/usr-flags-eamt.html > > > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible. > > Thank you! :) > > On Tue, Jan 7, 2020 at 8:14 AM Laurent Fasnacht <lf@o-t.ch> wrote: > > > > Hello, > > > > ‐‐‐‐‐‐‐ Original Message ‐‐‐‐‐‐‐ > > On Friday, January 3, 2020 7:09 PM, Alberto Leiva <ydahhrk@gmail.com> wrote: > > > > > Hello > > > > > > > > I've been working on Jool, an open source IP/ICMP translator for a > > > while ([0]). It currently implements SIIT, NAT64 and (if everything > > > goes according to plan) will later this year also support MAP-T. It > > > currently works both as a Netfilter module (hooking itself to > > > PREROUTING) or as an xtables target, and I'm soon going to start > > > integrating it into nftables. > > > > That's really great news! We (ProtonVPN) will be following the project, and will be glad to help if possible. > > > > Cheers, > > > > Laurent > > ProtonVPN R&D ^ permalink raw reply [flat|nested] 5+ messages in thread
end of thread, other threads:[~2020-02-10 18:07 UTC | newest] Thread overview: 5+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2020-01-03 18:09 Adding NAT64 to Netfilter Alberto Leiva 2020-01-07 13:00 ` Laura Garcia 2020-01-07 14:14 ` Laurent Fasnacht 2020-01-07 23:09 ` Alberto Leiva 2020-02-10 18:07 ` Alberto Leiva
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).