Re: PPPoE assigns link local fe80::200:0:0:1 instead of fe80::1
Bjorn Ketelaars <[email protected]> Sat, 18 Jul 2026 16:21:55 +0200
| Newsgroups | gmane.os.openbsd.misc |
|---|---|
| Message-ID | <[email protected]> |
On Sat 18/07/2026 11:44, Martin Crossley wrote: > Clean build of OpenBSD 7.9 generic.mp#449 amd64. > > During PPPoE negotiation the peer gives us fe80::1 and we accept it. > So why does pppoe set our link local address to fe80::200:0:0:1 ? > > fe80::200:0:0:1 looks like the EUI64 conversion for a MAC address of > 00:00:00:00:00:01, so could it be that the offered IFID is being > Interpreted as a MAC? > > (1) hostname.pppoe0 (NB: same result if we explicitly set inet6 fe80::1) > > inet 0.0.0.0 255.255.255.255 NONE \ > pppoedev bge0 authproto chap \ > authname ‘xxxxx' authkey ‘xxxxx’ up > dest 0.0.0.1 > inet6 eui64 > !/sbin/route add default -ifp pppoe0 0.0.0.1 > !/sbin/route add -inet6 default -ifp pppoe0 fe80::%pppoe0 > > (2) Ifconfig pppoe0 after negotiation > > pppoe0: flags=8855<UP,DEBUG,POINTOPOINT,RUNNING,SIMPLEX,MULTICAST> mtu 1492 > index 5 priority 0 llprio 3 > dev: bge0 state: session > sid: 0xca5 PADI retries: 0 PADR retries: 0 time: 00:04:27 > sppp: phase network authproto chap authname “xxxxx" > dns: 212.23.3.100 212.23.6.100 > groups: pppoe egress > status: active > inet6 fe80::200:0:0:1%pppoe0 --> prefixlen 64 scopeid 0x5 > inet 217.155.184.174 --> 51.148.77.132 netmask 0xffffffff > > > (3) Packet capture on the ethernet (our mac address is 00:9c:02:ab:d9:44) > > 21:17:19.111881 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 36: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 16 > IPV6CP Configure-Request Id=0x03: IPv6-Interface-Id=029c:02ff:feab:d944 > 21:17:19.117305 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 60: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 12 > IPCP Configure-Request Id=0x30: IP-Address=51.148.77.133 > 21:17:19.117307 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 60: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 24 > IPCP Configure-Nak Id=0x02: IP-Address=217.155.184.174 Primary-DNS-Server=212.23.3.100 Secondary-DNS-Server=212.23.6.100 > 21:17:19.117308 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 60: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 16 > IPV6CP Configure-Request Id=0x62: IPv6-Interface-Id=827f:f8ff:fe74:014b > 21:17:19.117779 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 32: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 12 > IPCP Configure-Ack Id=0x30: IP-Address=51.148.77.133 > 21:17:19.117780 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 44: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 24 > IPCP Configure-Request Id=0x04: IP-Address=217.155.184.174 Primary-DNS-Server=212.23.3.100 Secondary-DNS-Server=212.23.6.100 > 21:17:19.117781 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 36: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 16 > IPV6CP Configure-Ack Id=0x62: IPv6-Interface-Id=827f:f8ff:fe74:014b > 21:17:19.117895 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 60: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 16 > IPV6CP Configure-Nak Id=0x03: IPv6-Interface-Id=0000:0000:0000:0001 > 21:17:19.118149 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 36: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 16 > IPV6CP Configure-Request Id=0x05: IPv6-Interface-Id=0000:0000:0000:0001 > 21:17:19.118595 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 94: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 74 > IPv6 fe80::29c:2ff:feab:d944 > ff02::2: HBH icmp6: multicast listener done max resp delay: 0 addr: ff02::2 [hlim 1] > 21:17:19.118597 00:9c:02:ab:d9:44 80:7f:f8:74:01:4b 8864 94: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 74 > IPv6 fe80::200:0:0:1 > ff02::1:ff00:1: HBH icmp6: multicast listener report max resp delay: 0 addr: ff02::1:ff00:1 [hlim 1] > 21:17:19.226019 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 60: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 24 > IPCP Configure-Ack Id=0x04: IP-Address=217.155.184.174 Primary-DNS-Server=212.23.3.100 Secondary-DNS-Server=212.23.6.100 > 21:17:19.226621 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 60: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 16 > IPV6CP Configure-Ack Id=0x05: IPv6-Interface-Id=0000:0000:0000:0001 > 21:17:19.402414 80:7f:f8:74:01:4b 00:9c:02:ab:d9:44 8864 110: PPPoE-Session > code Session, version 1, type 1, id 0x07e4, length 90 > IPv6 fe80::827f:f8ff:fe74:14b > ff02::1: icmp6: router advertisement [class 0xc0] > I think your diagnosis is correct. The peer NAKs your initial interface ID and suggests 0000:0000:0000:0001. The sppp state machine accepts it and schedules installation of fe80::1. The problem is in in6_ifattach_linklocal(), which then unconditionally applies an EUI-64 U/L bit transformation to the provided interface ID: ifra.ifra_addr.sin6_addr.s6_addr[8] &= ~EUI64_GBIT; ifra.ifra_addr.sin6_addr.s6_addr[8] |= EUI64_UBIT; /* 0x00 → 0x02 */ That turns fe80::1 into fe80::200:0:0:1. This transformation is appropriate when deriving an interface ID from a MAC address, but RFC 5072 requires PPP-negotiated interface IDs to be used verbatim — they carry no EUI-64 semantics. The fix is to remove those two lines, see diff below. There are three call sites for in6_ifattach_linklocal(). Only sys/net/if_spppsubr.c reaches this branch. The other two — in sys/netinet/ip_carp.c and sys/netinet6/in6_ifattach.c itself — both pass NULL as the ifid argument and never reach this branch, so there is no impact on any other interface type. The lines were introduced by r1.66 of sys/netinet6/in6_ifattach.c (stsp@, January 2014), which added the ifid parameter to allow sppp to install peer-suggested interface IDs — a correct change overall. The EUI-64 bit manipulation was apparently carried over by analogy with the MAC-to-EUI-64 code nearby, but does not belong in the PPP context. Could you test this against your setup? 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);