From: Hannes Frederic Sowa <hannes@redhat.com>
To: Sowmini Varadhan <sowmini.varadhan@oracle.com>
Cc: David Ahern <dsahern@gmail.com>,
YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>,
Stephen Hemminger <stephen@networkplumber.org>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: why are IPv6 addresses removed on link down
Date: Tue, 13 Jan 2015 16:09:51 +0100 [thread overview]
Message-ID: <1421161791.13626.33.camel@redhat.com> (raw)
In-Reply-To: <20150113150048.GA28371@oracle.com>
On Di, 2015-01-13 at 10:00 -0500, Sowmini Varadhan wrote:
> On (01/13/15 07:53), David Ahern wrote:
> >
> > The current code seems inconsistent: I can put an IPv6 address on a
> > link in the down state. On a link up the address is retained. Only
> > on a subsequent link down is it removed. If DAD or anything else is
> > the reason for the current logic then why allow an address to be
> > assigned in the down state? Similarly that it currently seems to
> > work ok then it suggests the right thing is done on a link up in
> > which case a flush is not needed.
> >
> > Bottom line is there a harm in removing the flush? If there is no
> > harm will mainline kernel take a patch to do that or is your
> > backward compatibility concern enough to block it?
>
> Does some of this have to do with the manner in which this interacts
> with SLAAC? I recall that there were two schools of thought for doing
> DAD when SLAAC is present: one says it is sufficient to just do DAD
> on the interface-id, the other requies DAD on the whole 128-bit IPv6
> address. I'm not sure which choice linux makes.
Yes, it does have something to do with it. But I didn't understand what
you meant by doing DAD on the interface-id.
If you look at the patches I just posted, only addresses which are in
link-local and not in permanent state will be flushed.
I also need to do research on how to safely approach this, I don't know,
yet.
Bye,
Hannes
next prev parent reply other threads:[~2015-01-13 15:10 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2015-01-13 5:06 why are IPv6 addresses removed on link down David Ahern
2015-01-13 7:10 ` Stephen Hemminger
2015-01-13 10:35 ` Hannes Frederic Sowa
2015-01-13 11:58 ` YOSHIFUJI Hideaki
2015-01-13 12:15 ` YOSHIFUJI Hideaki
2015-01-13 12:36 ` Hannes Frederic Sowa
2015-01-13 14:53 ` David Ahern
2015-01-13 15:00 ` Hannes Frederic Sowa
2015-01-13 17:05 ` Nicolas Dichtel
2015-01-13 15:00 ` Sowmini Varadhan
2015-01-13 15:09 ` Hannes Frederic Sowa [this message]
2015-01-13 15:13 ` Sowmini Varadhan
2015-01-13 17:25 ` David Miller
2015-01-13 17:34 ` Hannes Frederic Sowa
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=1421161791.13626.33.camel@redhat.com \
--to=hannes@redhat.com \
--cc=dsahern@gmail.com \
--cc=hideaki.yoshifuji@miraclelinux.com \
--cc=netdev@vger.kernel.org \
--cc=sowmini.varadhan@oracle.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.