nftables and IPv6 prefix delegation (regression vs ip6tables)

nftables and IPv6 prefix delegation (regression vs ip6tables)

[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.

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?

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Florian Westphal]

Ian Pilcher <arequipeno@gmail.com> wrote:
> 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

ip6tables-translate suggests:

nft add rule ip6 filter INPUT 'ip6 saddr & ::ff:ffff:ffff:ffff:ffff == ::c8:0:0:0:1'

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Ian Pilcher]

On 11/3/22 18:12, Florian Westphal wrote:
> Ian Pilcher <arequipeno@gmail.com> wrote:
>> 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'
> 

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.

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Pablo Neira Ayuso]

On Mon, Nov 07, 2022 at 03:54:37PM -0600, Ian Pilcher wrote:
> On 11/3/22 18:12, Florian Westphal wrote:
> > Ian Pilcher <arequipeno@gmail.com> wrote:
> > > 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'
> > 
> 
> 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.

iptables version? 1.8.8 here provides a correct translation.

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Ian Pilcher]

On 11/8/22 03:13, Pablo Neira Ayuso wrote:
> On Mon, Nov 07, 2022 at 03:54:37PM -0600, Ian Pilcher wrote:
>> 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.
> 
> 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.

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Gordon Fisher]

On 11/3/2022 16:12 PM, Florian Westphal wrote:
> Ian Pilcher <arequipeno@gmail.com> wrote:
>> 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
> ip6tables-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?)

-- 
gfish

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Ian Pilcher]

On 11/8/22 13:03, Gordon Fisher wrote:
> 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 '::'.

-- 
========================================================================
Google                                      Where SkyNet meets Idiocracy
========================================================================

Re: nftables and IPv6 prefix delegation (regression vs ip6tables)

[Jeremy Sowden]

[-- Attachment #1: Type: text/plain, Size: 366 bytes --]

On 2022-11-09, at 08:19:14 -0600, Ian Pilcher wrote:
> On 11/8/22 13:03, Gordon Fisher wrote:
> > 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.

[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 833 bytes --]