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).
--
: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
+ * because there is no need and no neighbor discovery (mpe).
+ */
switch (ifp->if_type) {
case IFT_WIREGUARD:
+ case IFT_MPLS:
return (0);
}
