mirror of https://lore.kernel.org/lkml/
 help / color / mirror / Atom feed
From: Hannes Frederic Sowa <hannes@stressinduktion.org>
To: David Miller <davem@davemloft.net>
Cc: dcbw@redhat.com, mcgrof@do-not-panic.com, zoltan.kiss@citrix.com,
	netdev@vger.kernel.org, xen-devel@lists.xenproject.org,
	kvm@vger.kernel.org, linux-kernel@vger.kernel.org,
	kuznet@ms2.inr.ac.ru, jmorris@namei.org, yoshfuji@linux-ipv6.org,
	kaber@trash.net
Subject: Re: [RFC v2 2/4] net: enables interface option to skip IP
Date: Wed, 26 Feb 2014 02:29:34 +0100	[thread overview]
Message-ID: <20140226012934.GA24855@order.stressinduktion.org> (raw)
In-Reply-To: <20140225.161817.1623503840238501415.davem@davemloft.net>

On Tue, Feb 25, 2014 at 04:18:17PM -0500, David Miller wrote:
> From: Dan Williams <dcbw@redhat.com>
> Date: Tue, 25 Feb 2014 15:07:00 -0600
> 
> > Also, disable_ipv4 signals *intent*, which is distinct from current
> > state.
> > 
> > Does an interface without an IPv4 address mean that the user wished it
> > not to have one?
> > 
> > Or does it mean that DHCP hasn't started yet (but is supposed to), or
> > failed, or something hasn't gotten around to assigning an address yet?
> > 
> > disable_ipv4 lets you distinguish between these two cases, the same way
> > disable_ipv6 does.
> 
> Intent only matters on the kernel side if the kernel automatically
> assigns addresses to interfaces which have been brought up like ipv6
> does.
> 
> Since it does not do this for ipv4, this can be handled entirely in
> userspace.
> 
> It is not a valid argument to say that a rogue dhcp might run on
> the machine and configure an ipv4 address.  That's the admin's
> responsibility, and still a user side problem.  A "rogue" program
> could just as equally turn the theoretical disable_ipv4 off too.

Week end model strikes again. :)

Currently one would need to set arp_filter and arp_ignore and have no
ip address on the interface to isolate it from the ipv4 network.

IFF_NOARP is of no use here as it also disables neighbour discovery.

I am not sure we completley tear down igmp processing on that interface
if no ip address is available. Maybe there are some special cases with
forwarding, too.

Such a "silent" mode could come handy for intrusion detection systems
where one would ensure that no ip processing takes place but could also
be realized with nftables/netfilter/arpfilter, I think.

Bye,

  Hannes


  reply	other threads:[~2014-02-26  1:29 UTC|newest]

Thread overview: 61+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-02-15  2:59 [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends Luis R. Rodriguez
2014-02-15  2:59 ` [RFC v2 1/4] bridge: enable interfaces to opt out from becoming the root bridge Luis R. Rodriguez
2014-02-16 18:56   ` Ben Hutchings
2014-02-16 18:57   ` Stephen Hemminger
2014-02-18 21:02     ` Luis R. Rodriguez
2014-02-19  9:52       ` [Xen-devel] " Ian Campbell
2014-02-19 14:35         ` Zoltan Kiss
2014-02-19 17:02           ` Luis R. Rodriguez
2014-02-19 17:08             ` Stephen Hemminger
2014-02-19 17:59               ` Luis R. Rodriguez
2014-02-20 17:19                 ` Stephen Hemminger
2014-02-20 20:24                   ` Luis R. Rodriguez
2014-02-21 13:02                     ` Zoltan Kiss
2014-02-21 16:01                       ` Luis R. Rodriguez
2014-02-22  1:38                         ` Luis R. Rodriguez
2014-02-20 13:19             ` Zoltan Kiss
2014-02-20 20:01               ` Luis R. Rodriguez
2014-02-21 13:02                 ` Zoltan Kiss
2014-02-21 15:59                   ` Luis R. Rodriguez
2014-02-17 17:52   ` Zoltan Kiss
2014-02-19 16:45     ` Luis R. Rodriguez
2014-02-20 14:47       ` Zoltan Kiss
2014-02-20 20:28         ` Luis R. Rodriguez
2014-02-15  2:59 ` [RFC v2 2/4] net: enables interface option to skip IP Luis R. Rodriguez
2014-02-17 20:23   ` Dan Williams
2014-02-18 21:19     ` Luis R. Rodriguez
2014-02-18 21:42       ` Stephen Hemminger
2014-02-19 17:13         ` Luis R. Rodriguez
2014-02-19 16:45       ` Dan Williams
2014-02-19 17:20         ` Luis R. Rodriguez
2014-02-19 19:13           ` Zoltan Kiss
2014-02-20 20:39             ` Luis R. Rodriguez
2014-02-21 13:02               ` Zoltan Kiss
2014-02-22  1:40                 ` Luis R. Rodriguez
2014-02-20  0:56           ` Dan Williams
2014-02-20  0:58             ` Hannes Frederic Sowa
2014-02-20  1:02               ` Dan Williams
2014-02-20 20:31             ` Luis R. Rodriguez
2014-02-24 18:22               ` Dan Williams
2014-02-24 20:33                 ` Luis R. Rodriguez
2014-02-24 23:04                 ` David Miller
2014-02-25  0:02                   ` Ben Hutchings
2014-02-25  0:12                     ` David Miller
2014-02-25  2:01                       ` Ben Hutchings
2014-02-25  2:23                         ` Hannes Frederic Sowa
2014-02-25 19:50                       ` Paul Marks
2014-02-25 21:07                   ` Dan Williams
2014-02-25 21:18                     ` David Miller
2014-02-26  1:29                       ` Hannes Frederic Sowa [this message]
2014-02-15  2:59 ` [RFC v2 3/4] xen-netback: use a random MAC address Luis R. Rodriguez
2014-02-17 10:29   ` [Xen-devel] " David Vrabel
2014-02-18 11:22     ` Ian Campbell
2014-02-18 21:30       ` Luis R. Rodriguez
2014-02-15  2:59 ` [RFC v2 4/4] xen-netback: skip IPv4 and IPv6 interfaces Luis R. Rodriguez
2014-02-17 14:36   ` [Xen-devel] " Zoltan Kiss
2014-02-18 20:16     ` Luis R. Rodriguez
2014-02-19  9:47       ` Ian Campbell
2014-02-17 10:27 ` [Xen-devel] [RFC v2 0/4] net: bridge / ip optimizations for virtual net backends David Vrabel
2014-02-18 19:43   ` Luis R. Rodriguez
2014-02-19  9:48     ` Ian Campbell
2014-02-19 17:10       ` Luis R. Rodriguez

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=20140226012934.GA24855@order.stressinduktion.org \
    --to=hannes@stressinduktion.org \
    --cc=davem@davemloft.net \
    --cc=dcbw@redhat.com \
    --cc=jmorris@namei.org \
    --cc=kaber@trash.net \
    --cc=kuznet@ms2.inr.ac.ru \
    --cc=kvm@vger.kernel.org \
    --cc=linux-kernel@vger.kernel.org \
    --cc=mcgrof@do-not-panic.com \
    --cc=netdev@vger.kernel.org \
    --cc=xen-devel@lists.xenproject.org \
    --cc=yoshfuji@linux-ipv6.org \
    --cc=zoltan.kiss@citrix.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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox

all inboxes | Powered by JetHome®