[IPv6 Question] Should we remove or keep the temporary address if global address removed?

[IPv6 Question] Should we remove or keep the temporary address if global address removed?

[Hangbin Liu]

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?

Thanks
Hangbin

Re: [IPv6 Question] Should we remove or keep the temporary address if global address removed?

[Sam Edwards]

On Tue, Nov 5, 2024 at 3:16 AM Hangbin Liu <liuhangbin@gmail.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

Re: [IPv6 Question] Should we remove or keep the temporary address if global address removed?

[Hangbin Liu]

Hi Sam,
On Tue, Nov 05, 2024 at 04:50:46PM -0800, Sam Edwards wrote:
> > 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.

Thanks for the confirmation.

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

I can write the test and maybe also the fixes. But it could take at least 2
weeks as I also have some other works in hand. If you can do it more quick,
please feel free to do it first.

Thanks
Hangbin