nftables and IPv6 prefix delegation (regression vs ip6tables)
My plan to migrate from iptables to nftables seems to have hit a major snag. nftables seems to lack the ability to use prefix-independent masks when matching IPv6 addresses.
For example, my ISP delegates a /56 prefix, which I can divide into as many as 256 separate /64 subnets. So a routable IPv6 address in my network can be broken down like this.
pppp:pppp:pppp:ppNN:hhhh:hhhh:hhhh:hhhh
Where the p's represent the delegated prefix, the N's represent an internal "network ID", and the h's represent the host address. The prefix is relatively stable, but it can change occasionally, so hard- coding it into firewall rules is not really an option.
Assume that I want to match a particular host (pppp:pppp:pppp:ppc8::1) in a rule. With ip6tables, I can match this address with this expression:
0:0:0:c8::1/::ff:ffff:ffff:ffff:ffff
I can match the whole /64 subnet with:
0:0:0:c8::/0:0:0:ff::
(Neither is particularly readable, but they do work.)
I cannot figure out how to accomplish this with nftables. Any attempt to use the same sort of expression with the nft command just results in a syntax error.
Am I missing something, or am I stuck with ip6tables?
Signature · 3 lines
======================================================================== Google Where SkyNet meets Idiocracy ========================================================================
Quoted 15 lines · Ian Pilcher
My plan to migrate from iptables to nftables seems to have hit a major snag. nftables seems to lack the ability to use prefix-independent masks when matching IPv6 addresses.
For example, my ISP delegates a /56 prefix, which I can divide into as many as 256 separate /64 subnets. So a routable IPv6 address in my network can be broken down like this.
pppp:pppp:pppp:ppNN:hhhh:hhhh:hhhh:hhhh
Where the p's represent the delegated prefix, the N's represent an internal "network ID", and the h's represent the host address. The prefix is relatively stable, but it can change occasionally, so hard- coding it into firewall rules is not really an option.
Quoted 5 lines
Assume that I want to match a particular host (pppp:pppp:pppp:ppc8::1) in a rule. With ip6tables, I can match this address with this expression:
0:0:0:c8::1/::ff:ffff:ffff:ffff:ffff
ip6tables-translate suggests:
nft add rule ip6 filter INPUT 'ip6 saddr & ::ff:ffff:ffff:ffff:ffff == ::c8:0:0:0:1'
Quoted 11 lines · Florian Westphal
Quoted 5 lines · Ian Pilcher
Assume that I want to match a particular host (pppp:pppp:pppp:ppc8::1) in a rule. With ip6tables, I can match this address with this expression:
0:0:0:c8::1/::ff:ffff:ffff:ffff:ffffip6tables-translate suggests:
nft add rule ip6 filter INPUT 'ip6 saddr & ::ff:ffff:ffff:ffff:ffff == ::c8:0:0:0:1'
Interesting. I see that too.
I missed it, because ip6tables-translate-restore suggests:
nft add rule ip6 filter INPUT ip6 saddr
::c8:0:0:0:1/::ff:ffff:ffff:ffff:ffff counter accept
Which gives a syntax error.
Signature · 3 lines
======================================================================== Google Where SkyNet meets Idiocracy ========================================================================
Quoted 13 lines · Ian Pilcher
Quoted 11 lines · Florian Westphal
Quoted 5 lines · Ian Pilcher
Assume that I want to match a particular host (pppp:pppp:pppp:ppc8::1) in a rule. With ip6tables, I can match this address with this expression:
0:0:0:c8::1/::ff:ffff:ffff:ffff:ffffip6tables-translate suggests:
nft add rule ip6 filter INPUT 'ip6 saddr & ::ff:ffff:ffff:ffff:ffff == ::c8:0:0:0:1'
Quoted 8 lines
Interesting. I see that too.
I missed it, because ip6tables-translate-restore suggests:
nft add rule ip6 filter INPUT ip6 saddr
::c8:0:0:0:1/::ff:ffff:ffff:ffff:ffff counter acceptWhich gives a syntax error.
iptables version? 1.8.8 here provides a correct translation.
Quoted 10 lines · Pablo Neira Ayuso
Quoted 6 lines · Ian Pilcher
I missed it, because ip6tables-translate-restore suggests:
nft add rule ip6 filter INPUT ip6 saddr
::c8:0:0:0:1/::ff:ffff:ffff:ffff:ffff counter acceptWhich gives a syntax error.
iptables version? 1.8.8 here provides a correct translation.
1.8.7 (on Fedora 36).
I see that the 1.8.8 changelog contains:
Phil Sutter (134):
...
xtables-translate: Fix translation of odd netmasks
And it looks like Fedora 37 will ship with 1.8.8, so it appears that my timing was particularly unfortunate.
Signature · 3 lines
======================================================================== Google Where SkyNet meets Idiocracy ========================================================================
Quoted 16 lines · Florian Westphal
Quoted 15 lines · Ian Pilcher
My plan to migrate from iptables to nftables seems to have hit a major snag. nftables seems to lack the ability to use prefix-independent masks when matching IPv6 addresses.
For example, my ISP delegates a /56 prefix, which I can divide into as many as 256 separate /64 subnets. So a routable IPv6 address in my network can be broken down like this.
pppp:pppp:pppp:ppNN:hhhh:hhhh:hhhh:hhhh
Where the p's represent the delegated prefix, the N's represent an internal "network ID", and the h's represent the host address. The prefix is relatively stable, but it can change occasionally, so hard- coding it into firewall rules is not really an option.
Quoted 8 lines
Quoted 5 lines
Assume that I want to match a particular host (pppp:pppp:pppp:ppc8::1) in a rule. With ip6tables, I can match this address with this expression:
0:0:0:c8::1/::ff:ffff:ffff:ffff:ffffip6tables-translate suggests:
nft add rule ip6 filter INPUT 'ip6 saddr & ::ff:ffff:ffff:ffff:ffff == ::c8:0:0:0:1'
Out of curiosity, why does ``0:0:0:c8::1`` get translated into ``::c8:0:0:0:1`` ? Both seem to be correct when you consider the address expands to``0:0:0:c8:0:0:0:1`` (or ``0000:0000:0000:00c8:0000:0000:0000:0001`` in full form.) It seems to come down to a program choosing to use the ``::`` consecutive-zero-hextet-condenser by looking from one end or the other, but is more considered more correct than the other (that could upset some programs that use ipv6 addresses?)
Signature · 1 line
gfish
Quoted 1 line · Gordon Fisher
Out of curiosity, why does ``0:0:0:c8::1`` get translated into ``::c8:0:0:0:1`` ?
At a guess, inet_ntop() is simply choosing the longest string of zeroes in the address to replace with '::'.
Signature · 3 lines
======================================================================== Google Where SkyNet meets Idiocracy ========================================================================
Quoted 6 lines · Ian Pilcher
Quoted 2 lines · Gordon Fisher
Out of curiosity, why does ``0:0:0:c8::1`` get translated into ``::c8:0:0:0:1`` ?
At a guess,
inet_ntop()is simply choosing the longest string of zeroes in the address to replace with '::'.
That is indeed what glibc 2.36 does, at any rate.
J.