[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <20090108145628.3cdbc80a@extreme>
Date: Thu, 8 Jan 2009 14:56:28 -0800
From: Stephen Hemminger <shemminger@...tta.com>
To: David Miller <davem@...emloft.net>
Cc: yoshfuji@...ux-ipv6.org, netdev@...r.kernel.org
Subject: Re: [RFC] IPV6 address management
On Thu, 08 Jan 2009 14:03:39 -0800 (PST)
David Miller <davem@...emloft.net> wrote:
> From: Stephen Hemminger <shemminger@...tta.com>
> Date: Thu, 8 Jan 2009 14:01:22 -0800
>
> > Fine, it won't be the first or last vendor specific kernel patch.
>
> You're just supporting my argument even more.
>
> If all the dists ship it and turn it on, then logically we should
> include it and have it on by default.
>
> But you know we can't do that.
>
> Therefore, it's detrimental for the dists to ship it too because it
> does break things.
>
> I know you want to shove this in, via some avenue, but it is really
> so undesirable to cope with existing behavior?
Reading back in the archives, this has come up before. The real problem
is that when link goes down and comes back the address needs to be
reverified for DAD. Maybe instead of deleting addresses they should
be moved to another list for restart.
It is a real problem for routing daemons like hostapd and zebra since
the kernel address deletion looks a lot like a user address deletion.
Since Vyatta has the luxury of a configuration/scripting layer, this
means the state space is contained (we know what the address was),
I'll just hack around it there for now until a better solution arises.
--
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