netdev - Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Tue, 26 Oct 2010 10:11:00 -0700
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	Stephen Hemminger <shemminger@...tta.com>
Cc:	netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when
 losing link

On Tue, Oct 26, 2010 at 8:28 AM, Stephen Hemminger
<shemminger@...tta.com> wrote:
>> That won't help the case I am trying to fix, which is the case where
>> the new link has a global prefix different than the old link. Marking
>> the addresses as tentative will simply make them pass DAD and come
>> back as soon as link comes back. But since they don't match the prefix
>> that is assigned to the new link, they are unusable, because packets
>> can't be routed back to them.
>
> For IPv4 this is already handled by network manager.
> Why couldn't the same apply to IPv6?

I think addresses should be deleted by the entity that configured
them. In IPv4, the addresses are created by userspace daemons like
networkmanager or DHCP, and so they should be deleted by
networkmanager as well. In IPv6, autoconf addresses are created by the
kernel, and so should be deleted by the kernel.

Otherwise, userspace daemons that are not IPv6 aware must listen to
see what addresses are created, deleting them if they think they need
to go away, and possibly even racing with the kernel (e.g., imagine
networkmanager purging IPv6 addresses just before the kernel processes
an RA that adds new IPv6 addresses).

>> What's the additional failure scenario? Will it help if I make it so
>> that link-local addresses aren't touched at all?
>
> Link-local works fine.

Ok, so if global addresses work, then the patch doesn't need to do
anything special with link-local?
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html