From: Stefan Sperling Subject: Re: Fwd: Re: PPPoE assigns link local fe80::200:0:0:1 instead of fe80::1 To: Bjorn Ketelaars Cc: tech@openbsd.org Date: Mon, 20 Jul 2026 22:07:18 +0200 On Mon, Jul 20, 2026 at 09:26:01PM +0200, Bjorn Ketelaars wrote: > Bringing this from misc@ to tech@ as I'm looking for comments/OK. > > > netinet6: keep negotiated IPv6CP IFID unchanged for link-local address > > When sppp/PPPoE installs a peer-suggested IPv6CP interface identifier, > in6_ifattach_linklocal() forced EUI64 G/U bit adjustments on the > provided IFID. This incorrectly rewrote a valid negotiated IFID such as > ::1 into ::200:0:0:1, yielding fe80::200:0:0:1 instead of fe80::1. > > Do not apply EUI64 bit mangling when an explicit IFID is supplied; use > the negotiated value as-is (RFC 5072). Other callers are unaffected > since they pass NULL and continue using in6_get_ifid(). > > Reported and tested by Martin Crossley . > Tested by me on a connection that allows an explicit IFID. I am fine with this change in principle. I am not sure if we can safely assume that any potential future callers passing an ifid won't need EUI64 bit mangling. Would it make sense to guard EUI64 bit mangling with a check for point-to-point interfaces? Something like this? if ((ifp->if_flags & IFF_POINTOPOINT) == 0) { ifra.ifra_addr.sin6_addr.s6_addr[8] &= ~EUI64_GBIT; ifra.ifra_addr.sin6_addr.s6_addr[8] |= EUI64_UBIT; } > diff --git sys/netinet6/in6_ifattach.c sys/netinet6/in6_ifattach.c > index 975ccbf5056..c8c7033c058 100644 > --- sys/netinet6/in6_ifattach.c > +++ sys/netinet6/in6_ifattach.c > @@ -244,8 +244,6 @@ in6_ifattach_linklocal(struct ifnet *ifp, struct in6_addr *ifid) > ifra.ifra_addr.sin6_addr.s6_addr16[0] = htons(0xfe80); > ifra.ifra_addr.sin6_addr.s6_addr16[1] = htons(ifp->if_index); > ifra.ifra_addr.sin6_addr.s6_addr32[1] = 0; > - ifra.ifra_addr.sin6_addr.s6_addr[8] &= ~EUI64_GBIT; > - ifra.ifra_addr.sin6_addr.s6_addr[8] |= EUI64_UBIT; > } else > in6_get_ifid(ifp, &ifra.ifra_addr.sin6_addr); > >