netdev.vger.kernel.org archive mirror
 help / color / mirror / Atom feed
From: Jiri Benc <jbenc@redhat.com>
To: Mahesh Bandewar <maheshb@google.com>
Cc: Dan Williams <dcbw@redhat.com>, linux-netdev <netdev@vger.kernel.org>
Subject: Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address
Date: Sat, 28 Mar 2015 19:32:54 +0100	[thread overview]
Message-ID: <20150328193254.6c79784d@griffin> (raw)
In-Reply-To: <CAF2d9jh_-DxxUMcTjFK3TUAJhC=B9ORrmH0=tVH1KBiWsYPpLg@mail.gmail.com>

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).

 Jiri

-- 
Jiri Benc

  reply	other threads:[~2015-03-28 18:32 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 [this message]
2015-03-30 14:37         ` Dan Williams
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=20150328193254.6c79784d@griffin \
    --to=jbenc@redhat.com \
    --cc=dcbw@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 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).