On Mon, Jan 28, 2019 at 01:36:44PM +1000, 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. 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...
On a pure p2p tunnel multicast is for free and so IFF_MULTICAST can be set
without issues. On a point to multipoint interface like mpe(4) setting
IFF_MULTICAST would have some implications since the interface would
support multicast which requires to send the packet to more than one
endpoint. This is doable but I think not implemented (and nobody cares
about that). So keeping mpe(4) IFF_MULTICAST free would make sense.
Yes, ND needs local-multicast (not sure if that is a requirement for IPv6
in itself). I would say no but for that our stack needs changes.
--
:wq Claudio
