All of lore.kernel.org
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Miller <davem@davemloft.net>
Cc: nicolas.dichtel@6wind.com, dsa@cumulusnetworks.com,
	netdev@vger.kernel.org, hannes@redhat.com
Subject: Re: [PATCH net-next v5] net: ipv6: Make address flushing on ifdown optional
Date: Wed, 14 Oct 2015 14:14:05 +0200	[thread overview]
Message-ID: <1444824845.2190190.409937049.5F844219@webmail.messagingengine.com> (raw)
In-Reply-To: <20151014.051814.801287755321309990.davem@davemloft.net>



On Wed, Oct 14, 2015, at 14:18, David Miller wrote:
> From: Hannes Frederic Sowa <hannes@stressinduktion.org>
> Date: Wed, 14 Oct 2015 13:03:41 +0200
> > The difference is that people upgrade (in case of fedora they get a
> > .rpmnew file) or install a distribution and don't wonder or have
> > assumptions about old behavior. In case companies integrate kernel in
> > products/appliances without a way to manage those sysctls we cannot
> > simply change them as this would break assumptions for them. I think
> > those are two different cases.
> 
> The thing that is similar is that people set rp_filter inappropriately
> (no end host should have that knob enabled, ever, it's totally
> unnecesary).  And the risk here is similar, distribution X will set it
> so Y will say "we probably should set it too even though we really
> don't understand it fully".
> 
> I really hate situations like this.

I can bring up the rp_filter setting, too. It currently gets
unconditional set to strict mode in systemd on all interfaces.

The question is, if we should care about people enabling forwarding by
simply toggling the sysctl forwarding knob? Essentially in the kernel we
could provide two sysctl knobs, one for forwarding and one for local
reception. So people following the guidelines how to enable forwarding
could automatically have rp_filter enabled while host mode does not
because we leave  the forwarding rp_filter setting enabled. This at the
same time seems unnecessary complex and maybe we should simply talk to
distributions. ;)

What do you think?

Bye,
Hannes

  reply	other threads:[~2015-10-14 12:14 UTC|newest]

Thread overview: 11+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-10-12 16:33 [PATCH net-next v5] net: ipv6: Make address flushing on ifdown optional David Ahern
2015-10-14  1:45 ` David Miller
2015-10-14  9:34   ` Hannes Frederic Sowa
2015-10-14 10:08     ` Nicolas Dichtel
2015-10-14 11:03       ` Hannes Frederic Sowa
2015-10-14 12:18         ` David Miller
2015-10-14 12:14           ` Hannes Frederic Sowa [this message]
2015-10-14 13:00             ` David Miller
2015-10-14 16:09     ` David Ahern
2015-10-15  1:06       ` David Miller
2015-10-15  2:46         ` David Ahern

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=1444824845.2190190.409937049.5F844219@webmail.messagingengine.com \
    --to=hannes@stressinduktion.org \
    --cc=davem@davemloft.net \
    --cc=dsa@cumulusnetworks.com \
    --cc=hannes@redhat.com \
    --cc=netdev@vger.kernel.org \
    --cc=nicolas.dichtel@6wind.com \
    /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.