> On 27 Dec 2018, at 5:42 pm, Claudio Jeker <cje...@diehard.n-r-g.com> wrote:
>
> On Wed, Dec 26, 2018 at 09:27:59PM +0100, Denis Fondras wrote:
>> Resend because of nasty typo :/
>>
>> On Mon, Dec 24, 2018 at 08:43:10PM -0200, Martin Pieuchot wrote:
>>> I'm not happy with adding the IFF_MULTICAST flag and SIOC{ADD,DEL}MULTI
>>> ioctls. It seems to be a common pattern between in existing pseudo-driver,
>>> so this shouldn't block you. However I'd greatly appreciate if you
>>> could explain to us which code is asking for this and if this could be
>>> improved.
>>>
>>
>> Interface needs IFF_MULTICAST when enabling IPv6 as per in6_ifattach().
>> When an address is configured, the interface joins multicast groups with
>> in6_joingroup() (hence use SIOCADDMULTI) but only if IFF_MULTICAST is set.
>> It is
>> useful for interfaces extern-facing interfaces, not so much for internal
>> (like
>> mpe) as they won't process all-{nodes, routers} packets.
>>
>> We may remove the test in in6_ifattach() because there are many tests through
>> the stack. It works if I disable the test in in6_ifattach() and remove the
>> IFF_MULTICAST. However I haven't tested further so it may break elsewhere.
>>
>
> Doing IFF_MULTICAST on a true IFF_POINTOPOINT interface is indeed trivial
> and save. I think that bit of the mpe(4) diff is OK and I would not go and
> try to work around this in in6 code. IPv6 requires multicast and it was an
> oversight in mpe(4) to not add it.
My current thinking on this is that IFF_MULTICAST should be used by v6 to
decide if an interface can do neighbour discovery or not, it should not be used
to decide if an interface can have an IPv6 address assigned or not. You should
be able to assign v6 to any interface that can transport it, but if it can't do
ND then you'll need to statically assign prefixes. Assigning prefixes is what
bgpd implementing VPNv6 would be doing, and it would work fine.
This might mean we don't need IFF_MULTICAST on the layer three p2p tunnel
interfaces...
Cheers,
dlg
