netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@redhat.com>
To: Brian Haley <brian.haley@hp.com>
Cc: David Ahern <dsahern@gmail.com>, netdev@vger.kernel.org
Subject: Re: [RFC PATCH] net: ipv6: Make address flushing on ifdown optional
Date: Mon, 26 Jan 2015 17:49:21 +0100	[thread overview]
Message-ID: <1422290961.2687.39.camel@redhat.com> (raw)
In-Reply-To: <54C2BA50.6080208@hp.com>

On Fr, 2015-01-23 at 16:17 -0500, Brian Haley wrote:
> On 01/23/2015 01:23 PM, David Ahern wrote:
> 
> >>> Add a new sysctl to make this behavior optional. Setting defaults to flush
> >>> addresses to maintain backwards compatibility. When reset flushing is bypassed:
> >>>
> >>> [root@f20 ~]# echo 0 > /proc/sys/net/ipv6/conf/eth1/flush_addr_on_down
> >>> [root@f20 ~]# ip -6 addr add dev eth1 2000:11:1:1::1/64
> >>> [root@f20 ~]# ip addr show dev eth1
> >>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
> >>> default qlen 1000
> >>>      link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> >>>      inet6 2000:11:1:1::1/64 scope global tentative
> >>>         valid_lft forever preferred_lft forever
> >>> [root@f20 ~]#  ip link set dev eth1 up
> >>> [root@f20 ~]#  ip link set dev eth1 down
> >>> [root@f20 ~]# ip addr show dev eth1
> >>> 3: eth1: <BROADCAST,MULTICAST> mtu 1500 qdisc pfifo_fast state DOWN group
> >>> default qlen 1000
> >>>      link/ether 02:04:11:22:33:01 brd ff:ff:ff:ff:ff:ff
> >>>      inet6 2000:11:1:1::1/64 scope global
> >>>         valid_lft forever preferred_lft forever
> >>>      inet6 fe80::4:11ff:fe22:3301/64 scope link
> >>>         valid_lft forever preferred_lft forever
> >>
> >> I think this was brought up in a previous thread on this, but don't you have to
> >> do DAD on these addresses once the interface comes back up?  Some other system
> >> could have come along, done DAD, succeeded, and is now using it.  Or does the
> >> use of this flag assume the user is Ok without doing DAD, and will deal with the
> >> fallout?
> > 
> > You have the same problem today, don't you? Current code allows an IPv6 address
> > to be configured on interface in the down state. The intent of this sysctl is to
> > allow that address to stay on an up-down cycle.
> 
> Yes, looks like ndisc_send_skb() never returns any lower-level error back up to
> the caller, so it's assumed the Neighbour Advertisement is always sent.
> Although the address will be marked "tentative" until IFF_UP is set.
> 
> > I don't have a strong IPv6 background so the first email thread and this RFC
> > patch are both asking first and foremost if there is any harm in this behavior.
> > None has been raised - so far. To maintain backwards compatibility this is a new
> > option which when reset allows the addresses to be retained (not flushed).
> 
> Seems as though you're in an RFC grey area then.  Personally, I'd do DAD, even
> though the possibility of a collision is always very small.  But that's just my
> opinion.

I agree. If the interface is in a state where it doesn't listen for
other hosts doing DAD, we must initiate DAD for that address during
bringing the interface up.

I am even not so sure if this is a grey area. Anyway, the current
behavior is not best and we should change that if the kernel does not do
DAD on addresses added during ifdown. Hopefully people don't use this
trick. :)

Bye,
Hannes

      reply	other threads:[~2015-01-26 16:49 UTC|newest]

Thread overview: 19+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-01-14 19:17 [RFC PATCH] net: ipv6: Make address flushing on ifdown optional David Ahern
2015-01-19 15:02 ` Hannes Frederic Sowa
2015-01-19 16:12   ` Harout Hedeshian
2015-01-19 19:11     ` Hannes Frederic Sowa
2015-01-20 17:07   ` David Ahern
2015-01-23  6:40 ` Stephen Hemminger
2015-01-23 12:22   ` Hannes Frederic Sowa
2015-01-27  4:56     ` Andy Gospodarek
2015-01-27  9:44       ` Hannes Frederic Sowa
2015-01-27 14:55         ` David Ahern
2015-01-27 15:28           ` Hannes Frederic Sowa
2015-01-28  3:21             ` David Ahern
2015-01-28  8:25               ` Hannes Frederic Sowa
2015-01-27 16:09         ` Andy Gospodarek
2015-01-23 18:47   ` David Ahern
2015-01-23 16:09 ` Brian Haley
2015-01-23 18:23   ` David Ahern
2015-01-23 21:17     ` Brian Haley
2015-01-26 16:49       ` Hannes Frederic Sowa [this message]

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=1422290961.2687.39.camel@redhat.com \
    --to=hannes@redhat.com \
    --cc=brian.haley@hp.com \
    --cc=dsahern@gmail.com \
    --cc=netdev@vger.kernel.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).