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] [day] [month] [year] [list]

Message-ID: <AANLkTikr8mNkap0skgAPdNFTjv3LhoGGXQwrUz5hBT1K@mail.gmail.com>
Date:	Fri, 5 Nov 2010 14:40:38 +0800
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Stephen Hemminger <shemminger@...tta.com>, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when
 losing link

On Tue, Nov 2, 2010 at 10:54 AM, Dan Williams <dcbw@...hat.com> wrote:
> For this sort of thing, I tend to think that only higher-level network
> management daemons like NM have the *possibility* to get this sort of
> thing right, because only they have overall knowledge of the networking
> situation, like whether you've actually connected to a different network
> or not.  Specifically in the case of wifi, only the connection manager
> (or wpa_supplicant) knows whether you're on a different network or  not,
> anything else is a layering violation.

Maybe you're right and everything should be done in userspace. But for
now, the kernel is still processing RAs itself and adding IPv6
addresses to interfaces itself. If we don't intend to rip that all out
and replace it with a userspace implementation, then we should fix the
kernel to be a little smarter and not keep addresses around when they
are not useful any more.

This can be done relatively in a hitless fashion by putting old
addresses into the deprecated state until they are refreshed by an RA,
etc.

I don't think it's reasonable to say that we need a network management
daemon because we need to delete addresses that the kernel created and
the kernel can't be bothered to clean up after itself.

Cheers,
Lorenzo
--
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