On 28/01/19(Mon) 13:36, David Gwynne wrote:
>
>
> > 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. [...]
I agree with you David.
However in6_ifattach() still expects IFF_MULTICAST. So somebody(tm) has
to do some work if we want to properly dissociate IPv6 support from ND :o)
