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.
