[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <4CC708CE.4040404@hp.com>
Date: Tue, 26 Oct 2010 12:58:54 -0400
From: Brian Haley <brian.haley@...com>
To: Lorenzo Colitti <lorenzo@...gle.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 10/26/2010 01:44 AM, Lorenzo Colitti wrote:
> On Mon, Oct 25, 2010 at 9:38 PM, Stephen Hemminger
> <shemminger@...tta.com> wrote:
>> This is incorrect. When link is lost, routes and address should not be
>> flushed. They should be marked as tentative and then go through DAD again
>> on the new network.
>
> 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.
The old addresses will become deprecated, and eventually get removed, but
it will take 2 hours.
>> If you do it this way, you break routing protocols when link is brought
>> down and back up.
>
> The only addresses and routes flushed in this way should be ones that
> aren't manually configured, i.e., the ones created by autoconf
> (addrconf.c:2720 onwards). These won't be used by routing protocols,
> except for link-local addresses. So I assume you're talking about
> link-local here.
I posted a very similar patch recently:
http://marc.info/?l=linux-netdev&m=128415231909522&w=2
But the first response pointed out that I didn't test this with just a
simple link flap, in which case all the IPv6 addresses are deleted,
and all sessions using them die. Not good. This changes the current
behavior, and isn't what happens with IPv4 either.
Having these addresses restart DAD is probably about as much as we
can do I think, unless we add a per-device sysctl to remove the addresses
(which I think has been shot-down before). Is this a mobile device that
is actually changing it's point of attachment?
-Brian
--
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
Powered by blists - more mailing lists