Message-ID: <CAH5Ym4hAz6xRnf-o32usHj8S5ESj0cpFBb7JypDVMkq2_v0x1w@mail.gmail.com>
Date: Tue, 5 Nov 2024 16:50:46 -0800
From: Sam Edwards <cfsworks@...il.com>
To: Hangbin Liu <liuhangbin@...il.com>
Cc: netdev@...r.kernel.org
Subject: Re: [IPv6 Question] Should we remove or keep the temporary address if
 global address removed?

On Tue, Nov 5, 2024 at 3:16 AM Hangbin Liu <liuhangbin@...il.com> wrote:
>
> Hi Sam,
>
> Our QE just find the latest upstream kernel behavior changed for temporary
> address. i.e. In the previous time, the kernel will also remove the temporary
> address if the related global address deleted. But now the kernel will keep
> the temporary there. e.g.
> ```
> # sysctl -w net.ipv6.conf.enp59s0f0np0.use_tempaddr=1
> # ip add add 2003::4/64 dev enp59s0f0np0 mngtmpaddr
> # ip add show enp59s0f0np0
> 6: enp59s0f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
>     link/ether b8:59:9f:06:56:6c brd ff:ff:ff:ff:ff:ff
>     inet6 2003::d280:ee50:d13e:a1b1/64 scope global temporary dynamic
>        valid_lft 604793sec preferred_lft 86393sec
>     inet6 2003::4/64 scope global mngtmpaddr
>        valid_lft forever preferred_lft forever
> # ip add del 2003::4/64 dev  enp59s0f0np0 mngtmpaddr
> # ip add show enp59s0f0np0
> 6: enp59s0f0np0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
>     link/ether b8:59:9f:06:56:6c brd ff:ff:ff:ff:ff:ff
>     inet6 2003::d7c7:a239:2519:2491/64 scope global temporary dynamic
>        valid_lft 604782sec preferred_lft 86382sec
> ```
>     ^^ previously this temporary address will also be removed.
>
> After checking the code, it looks commit 778964f2fdf0 ("ipv6/addrconf: fix
> timing bug in tempaddr regen") changes the behavior. I can't find what we should
> do when delete the related global address from RFC8981. So I'm not sure
> which way we should do. Keep or delete the temporary address.
>
> Do you have any idea?

Hi Hangbin,

RFC8981 section 3.4 does say that existing temporary addresses must
have their lifetimes adjusted so that no temporary addresses should
ever remain "valid" or "preferred" longer than the incoming SLAAC
Prefix Information. This would strongly imply in Linux's case that if
the "mngtmpaddr" address is deleted or un-flagged as such, its
corresponding temporary addresses must be cleared out right away. That
also makes intuitive sense to me, because if an administrator is
deleting (or un-flagging) "mngtmpaddr" they very likely want no more
temporary addresses within that prefix.

So, I would say what you've found is a bug. Doubly so because the
temporaries contain a pointer to the managing address, which is
possibly now dangling.

By the way, I don't think my patch from 2 years ago is still working
correctly: I'm seeing that my (high-uptime) workstation has two
mngtmpaddr addresses, one public address and one internal to my LAN,
but currently only the "internal to my LAN" one has any
still-preferred temporary addresses currently.

Last time around, Paolo strongly suggested that I include a regression
test with my patch. I now realize it's a good idea to write such a
test:
1. Create a dummy Ethernet interface, with temp_*_lft configured to be
pretty short (10 and 35 seconds for prefer/valid respectively?)
2. Create several (3-4) mngtmpaddr addresses on that interface.
3. Confirm that temporary addresses are created immediately.
4. Confirm that a preferred temporary address exists for each
mngtmpaddr address at all times, polling once per second for at least
10 minutes.
5. Delete each mngtmpaddr address, one at a time (alternating between
deleting and merely un-mngtmpaddr-ing), and confirm that the other
mngtmpaddr addresses still have preferred temporaries.
6. Within steps 3-5, also confirm that any temporaries that exist have
a corresponding mngtmpaddr. (Basically the test should, at all steps,
confirm that every existing mngtmpaddr has at least one preferred
temporary, and that every existing temporary has a matching
mngtmpaddr.)

This test should fail, demonstrating both of these bugs, when run
against the latest kernel. Then we can get to work on making the test
pass.

Are you interested in writing that test or should I? I have never
contributed test cases to the kernel before, so there'd be a bit of a
learning curve for me, but I'm happy to do it.

Cheers,
Sam

>
> Thanks
> Hangbin

Powered by blists - more mailing lists