From: Dan Williams <dcbw@redhat•com>
To: Stephen Hemminger <shemminger@vyatta•com>
Cc: Lorenzo Colitti <lorenzo@google•com>, netdev@vger•kernel.org
Subject: Re: [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link
Date: Mon, 01 Nov 2010 21:54:19 -0500 [thread overview]
Message-ID: <1288666459.4003.47.camel@dcbw.foobar.com> (raw)
In-Reply-To: <20101026082832.4c5af2ef@nehalam>
On Tue, 2010-10-26 at 08:28 -0700, Stephen Hemminger wrote:
> On Mon, 25 Oct 2010 22:44:03 -0700
> Lorenzo Colitti <lorenzo@google•com> wrote:
>
> > On Mon, Oct 25, 2010 at 9:38 PM, Stephen Hemminger
> > <shemminger@vyatta•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.
>
> For IPv4 this is already handled by network manager.
> Why couldn't the same apply to IPv6?
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.
Remember that carrier loss does *not* indicate that you've switched
networks, both for wired and especially for wifi. The only way you know
that you've really switched is when you've reconnected (or timed out the
reconnect) and inspected the new network situation. It seems only
appropriate that the policy gets applied from higher levels based on a
more nuanced view of network state.
Dan
>
> > > 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.
>
> Not sure, let me do test it.
>
> > Link-local addresses are immediately recreated in a tentative state as
> > soon as link comes back, because on NETDEV_UP addrconf_notify calls
> > addrconf_dev_config. So, this patch only makes it so that they become
> > tentative when link goes away and comes back. In that time, the router
> > that temporarily loses link is unable to send packets for the brief
> > period of time that the link is performing DAD, but if the router has
> > lost link, it will also fail to send the packet while link is lost.
> > 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.
>
next prev parent reply other threads:[~2010-11-02 2:55 UTC|newest]
Thread overview: 32+ messages / expand[flat|nested] mbox.gz Atom feed top
2010-10-26 2:08 [PATCH] ipv6: addrconf: clear IPv6 addresses and routes when losing link Lorenzo Colitti
2010-10-26 4:38 ` Stephen Hemminger
2010-10-26 5:44 ` Lorenzo Colitti
2010-10-26 15:28 ` Stephen Hemminger
2010-10-26 17:11 ` Lorenzo Colitti
2010-11-02 2:54 ` Dan Williams [this message]
2010-11-05 6:40 ` Lorenzo Colitti
2010-10-26 16:58 ` Brian Haley
2010-10-26 17:09 ` Lorenzo Colitti
2010-10-26 17:10 ` David Miller
2010-10-26 17:13 ` Lorenzo Colitti
2010-10-26 17:21 ` David Miller
2010-10-26 17:37 ` Lorenzo Colitti
2010-10-26 17:47 ` David Miller
2010-10-26 17:50 ` Lorenzo Colitti
2010-10-26 17:55 ` David Miller
2010-10-26 18:02 ` Lorenzo Colitti
2010-10-26 18:21 ` David Miller
2010-11-02 2:50 ` Dan Williams
2010-10-26 18:17 ` Lorenzo Colitti
2010-10-26 18:23 ` David Miller
2010-10-26 22:53 ` Lorenzo Colitti
2010-10-27 15:51 ` David Miller
2010-10-27 16:01 ` Lorenzo Colitti
2010-10-27 16:05 ` David Miller
2010-10-27 2:31 ` Brian Haley
2010-10-27 8:35 ` Maciej Żenczykowski
2010-10-27 16:03 ` Lorenzo Colitti
2010-10-27 20:39 ` Maciej Żenczykowski
2010-10-28 22:23 ` Lorenzo Colitti
2010-10-28 22:41 ` Lorenzo Colitti
2010-10-28 22:50 ` Maciej Żenczykowski
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=1288666459.4003.47.camel@dcbw.foobar.com \
--to=dcbw@redhat$(echo .)com \
--cc=lorenzo@google$(echo .)com \
--cc=netdev@vger$(echo .)kernel.org \
--cc=shemminger@vyatta$(echo .)com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox