All of lore.kernel.org
 help / color / mirror / Atom feed
From: Dan Williams <dcbw@redhat.com>
To: Jiri Benc <jbenc@redhat.com>
Cc: Mahesh Bandewar <maheshb@google.com>,
	linux-netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address
Date: Mon, 30 Mar 2015 09:37:10 -0500	[thread overview]
Message-ID: <1427726230.1913.9.camel@redhat.com> (raw)
In-Reply-To: <20150328193254.6c79784d@griffin>

On Sat, 2015-03-28 at 19:32 +0100, Jiri Benc wrote:
> On Fri, 27 Mar 2015 22:56:15 -0700, Mahesh Bandewar wrote:
> > The current logic disables broadcast by default and enables only when
> > an IPv4 address is added. If this is inverted and -
> > enables broadcast by default but disables it when only IPv6
> > address(es) is / are added. These links can have multiple addresses
> > and hence have to be careful if any one of those is IPv4 then
> > broadcast bit has to be set.
> 
> You'd have to be careful and ignore IPv6 link local addresses.
> Those are added automatically whenever IPv6 is enabled and their
> presence does not mean the network is not IPv4 only.
> 
> But I don't like such magic behavior. It would lead to DHCP sometimes
> working and sometimes not in mixed v4/v6 environment depending on
> whether DHCPv4 or SLAAC was faster.
> 
> Could we perhaps add a flag when creating ipvlan interface stating
> whether IPv4 broadcast should be always enabled? Or, rather, the other
> way round - whether it should be disabled by default. Call it "nodhcp"
> or so.
> 
> Btw, speaking about IPv6 link local addresses, these actually do not
> work with ipvlan correctly. I'm getting DAD failures if I have more
> than one ipvlan interface, which is no wonder. This means that ipvlan
> cannot work with IPv6 reliably by default (unless you take care of ll
> address assignment and ensure all ipvlan interfaces get a different
> one).

ipvlan doesn't set dev_id.  Once dev_id is set the kernel's IPv6LL
address generation code will assign a different LL address to each
ipvlan interface created from the same physical interface, despite that
they have the same MAC address.

But of course you'd have to be careful to assign a *different* dev_id
than any of that physical interface's non-ipvlan children too, and I
have no idea how that would work since dev_id is currently done
per-driver.  eg, if you have a physical interface with dev_id=1 which
you then create an ipvlan from, that ipvlan must not use dev_id=1 or it
will be assigned the same IPv6LL address as the parent.

Dan

  reply	other threads:[~2015-03-30 14:36 UTC|newest]

Thread overview: 37+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-03-26 22:41 [PATCH 1/2] ipvlan: don't loose broadcast MAC when setting MAC filters Dan Williams
2015-03-26 22:43 ` [PATCH 2/2] ipvlan: always allow the broadcast MAC address Dan Williams
2015-03-27 17:46   ` Jiri Benc
2015-03-28  0:52   ` Mahesh Bandewar
2015-03-28  5:56     ` Mahesh Bandewar
2015-03-28 18:32       ` Jiri Benc
2015-03-30 14:37         ` Dan Williams [this message]
2015-03-30 16:54           ` Mahesh Bandewar
2015-03-30 17:44             ` Dan Williams
2015-03-30 17:56               ` Mahesh Bandewar
2015-03-30 18:13                 ` Dan Williams
2015-03-30 18:32                   ` Mahesh Bandewar
2015-03-27 17:45 ` [PATCH 1/2] ipvlan: don't loose broadcast MAC when setting MAC filters Jiri Benc
2015-03-30 20:28 ` Mahesh Bandewar
2015-03-30 21:01   ` Dan Williams
2015-03-30 21:11     ` Mahesh Bandewar
2015-03-31  3:05       ` Dan Williams
2015-03-31  4:22         ` [PATCH] ipvlan: fix up broadcast MAC filtering for ARP and DHCP Dan Williams
2015-04-01 20:07           ` Dan Williams
2015-04-01 20:24           ` Mahesh Bandewar
2015-04-01 20:55             ` Dan Williams
2015-04-02  1:30               ` Mahesh Bandewar
2015-04-02 14:40                 ` Dan Williams
2015-04-03  1:39                   ` Mahesh Bandewar
2015-04-06 17:17                     ` Dan Williams
2015-04-07 18:32                       ` Mahesh Bandewar
2015-04-07 19:45                         ` Dan Williams
2015-04-09 15:51                           ` Dan Williams
2015-04-09 16:01                             ` Eric Dumazet
2015-04-09 16:33                             ` Mahesh Bandewar
2015-04-09 22:18                               ` Dan Williams
2015-04-08  9:37                       ` David Laight
2015-04-08 14:12                         ` Dan Williams
2015-04-09  1:08                         ` Mahesh Bandewar
2015-04-02 18:16           ` David Miller
2015-04-02 18:39             ` Dan Williams
2015-04-02 18:46               ` Dan Williams

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=1427726230.1913.9.camel@redhat.com \
    --to=dcbw@redhat.com \
    --cc=jbenc@redhat.com \
    --cc=maheshb@google.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 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.