netdev - Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Date:	Mon, 30 Mar 2015 09:54:54 -0700
From:	Mahesh Bandewar <maheshb@...gle.com>
To:	Dan Williams <dcbw@...hat.com>
Cc:	Jiri Benc <jbenc@...hat.com>, linux-netdev <netdev@...r.kernel.org>
Subject: Re: [PATCH 2/2] ipvlan: always allow the broadcast MAC address

On Mon, Mar 30, 2015 at 7:37 AM, Dan Williams <dcbw@...hat.com> wrote:
> 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.
>
Yes, that was what my plan was but never got around fixing that

> 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.
>
The description is very clear for dev_id (in netdevice.h). So the idea
of using the subsequent numbers after master's id should be possible.
After all these logical devices are going to share the same link. Most
physical drivers don't assign dev-id so the beginning is 0x0 (for the
physical driver) and from 0x1 can be assigned to the logical links.
The definition is not clear in terms of what is the beginning (0x0 or
0x1) but from the code that generates the IPv6LL it's common that it's
0x0 hence logical links on top of these links can use 0x1 onward.
However a check to see if the master-link has dev-id and staying clear
of that should be sufficient.

--mahesh..


>
> Dan
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html