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]

Message-ID: <AANLkTi=P80OUBSy3xCt_qOjPGTwNjrtFL1iLJnkc9joq@mail.gmail.com>
Date:	Tue, 26 Oct 2010 10:37:53 -0700
From:	Lorenzo Colitti <lorenzo@...gle.com>
To:	David Miller <davem@...emloft.net>
Cc:	brian.haley@...com, shemminger@...tta.com, netdev@...r.kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when
 losing link

On Tue, Oct 26, 2010 at 10:21 AM, David Miller <davem@...emloft.net> wrote:
>> Removing autoconfigured addresses is what the kernel currently does
>> when the link goes down. The patch just makes sure it happens when
>> carrier is lost as well, since losing link might mean that when
>> carrier comes back, the host might be on a different link than it was
>> before.
>
> I just think validating that fact would be a better approach than
> simply assuming link down/up means link change.

So when the link comes back, we'd have to wait for all RAs to come in
(there could be multiple routers on a link, each announcing different
prefixes), and when this is all done, compare the list of addresses to
the prefixes that are currently on the link and delete the ones that
don't match. We'd have to do the same with default routers and /64
routes to all the link prefixes.

Also, we'd have to figure out how long to wait for RAs, and when to
time out if there are no RAs. Bear in mind that for as long as you
have an invalid IPv6 address, you can't reach dual-stack websites at
all (well, technically you can, but only if you're prepared to wait 3
minutes for the connection to time out). The damage starts when
associating to the link and only stops when the addresses and routes
are removed.

Is the extra complexity worth it? This patch is three lines, deals
with what I think is the common case, and has no obvious downsides
we've spotted so far. And at least in my testing, it's a definite
improvement. Would you be opposed to doing something like this as a
first cut and iterating or backing out if it turns out to be
insufficient or broken?
--
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