On Fri, Nov 04, 2022 at 03:40:04PM +0100, Claudio Jeker wrote:
> So mpe(4) is a special device. It is a point-to-multipoint interface that
> does not do multicast. So setting IFF_MULTICAST on the interface is not
> correct but IPv6 depends on it because neighbor discovery.
>
> Now there is no neighbor discovery on mpe(4) the neighbors are handled via
> BGP. So lets adjust in6_ifattach() to succeed for mpe(4) interfaces and
> with that BGP IPv6 L3VPN should work.
>
> It may be an idea to move the IFF_MULTCAST check down into the
> ifp->if_type switch but right now this is good enough. I wonder if we have
> other interfaces that need similar treatment (e.g. mgre).
Good enough for now, I also have a few minues for nd6.c but prefer
simpler changes first, then the cleanup come later.
OK kn
> --
> :wq Claudio
>
> Index: netinet6/in6_ifattach.c
> ===================================================================
> RCS file: /cvs/src/sys/netinet6/in6_ifattach.c,v
> retrieving revision 1.119
> diff -u -p -r1.119 in6_ifattach.c
> --- netinet6/in6_ifattach.c 8 Sep 2022 10:22:07 -0000 1.119
> +++ netinet6/in6_ifattach.c 4 Nov 2022 12:52:36 -0000
> @@ -373,7 +373,8 @@ in6_ifattach(struct ifnet *ifp)
> if (ifp->if_mtu < IPV6_MMTU)
> return (EINVAL);
>
> - if ((ifp->if_flags & IFF_MULTICAST) == 0)
> + /* ND needs multicast but mpe(4) does neither multicast nor ND */
> + if ((ifp->if_flags & IFF_MULTICAST) == 0 && ifp->if_type != IFT_MPLS)
> return (EINVAL);
>
> /*
> @@ -389,10 +390,14 @@ in6_ifattach(struct ifnet *ifp)
> return (error);
> }
>
> - /* Interfaces that rely on strong a priori cryptographic binding of
> - * IP addresses are incompatible with automatically assigned llv6. */
> + /*
> + * Some interface don't need an automatically assigned link-local
> + * address either because it think it is special (wireguard) or
s/it think//
> + * because there is no need and no neighbor discovery (mpe).
s/because//
> + */
> switch (ifp->if_type) {
> case IFT_WIREGUARD:
> + case IFT_MPLS:
> return (0);
> }
>
>
