From: Hannes Frederic Sowa <hannes@redhat.com>
To: YOSHIFUJI Hideaki <hideaki.yoshifuji@miraclelinux.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
David Ahern <dsahern@gmail.com>,
"netdev@vger.kernel.org" <netdev@vger.kernel.org>
Subject: Re: why are IPv6 addresses removed on link down
Date: Tue, 13 Jan 2015 13:36:53 +0100 [thread overview]
Message-ID: <1421152613.13626.24.camel@redhat.com> (raw)
In-Reply-To: <54B50C71.7090007@miraclelinux.com>
Hi,
On Di, 2015-01-13 at 21:15 +0900, YOSHIFUJI Hideaki wrote:
> YOSHIFUJI Hideaki wrote:
> > Hi,
> >
> > Hannes Frederic Sowa wrote:
> >> On Mo, 2015-01-12 at 23:10 -0800, Stephen Hemminger wrote:
> >>> On Mon, 12 Jan 2015 22:06:44 -0700
> >>> David Ahern <dsahern@gmail.com> wrote:
> >>>
> >>>> We noticed that IPv6 addresses are removed on a link down. e.g.,
> >>>> ip link set dev eth1
> >>>>
> >>>>
> >>>> Looking at the code it appears to be this code path in addrconf.c:
> >>>>
> >>>> case NETDEV_DOWN:
> >>>> case NETDEV_UNREGISTER:
> >>>> /*
> >>>> * Remove all addresses from this interface.
> >>>> */
> >>>> addrconf_ifdown(dev, event != NETDEV_DOWN);
> >>>> break;
> >>>>
> >>>> IPv4 addresses are NOT removed on a link down. Is there a particular
> >>>> reason IPv6 addresses are?
> >>>>
> >>>> Thanks,
> >>>> David
> >>>
> >>> See RFC's which describes how IPv6 does Duplicate Address Detection.
> >>> Address is not valid when link is down, since DAD is not possible.
> >>
> >> It should be no problem if the kernel would reacquire them on ifup and
> >> do proper DAD. We simply must not use them while the interface is dead
> >> (also making sure they don't get used for loopback routing).
> >>
> >> The problem the IPv6 addresses get removed is much more a historical
> >> artifact nowadays, I think. It is part of user space API and scripts
> >> deal with that already.
> >
> > We might have another "detached" state which essintially drops
> > outgoing packets while link is down. Just after recovering link,
> > we could start receiving packet from the link and perform optimistic
> > DAD. And then, after it succeeds, we may start sending packets.
> >
> > Since "detached" state is like the state just before completing
> > Optimistic DAD, it is not so difficult to implement this extended
> > behavior, I guess.
> >
>
> Note that node is allowed to send packets to neighbours or default
> routers if the node knows their link-layer addresses during Optimistic
> DAD.
>
I don't think it should be a problem from internal state handling of the
addresses.
I am much more concerned with scripts expecting the addresses to be
flushed on interface down/up and not reacting appropriate.
Bye,
Hannes
next prev parent reply other threads:[~2015-01-13 12:37 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 [this message]
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
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=1421152613.13626.24.camel@redhat.com \
--to=hannes@redhat.com \
--cc=dsahern@gmail.com \
--cc=hideaki.yoshifuji@miraclelinux.com \
--cc=netdev@vger.kernel.org \
--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.