I'm surprised to see an IPv6 packet with link local scope source and a
global scope destination.
According to RFC3848 and RFC6724 this should not happen (prefer the
larger scope, when choosing a source address from several candidates).
Also RFC 4291:
2.5.6. Link-Local IPv6 Unicast Addresses
Link-Local addresses are for use on a single link. Link-Local
addresses have the following format:
| 10 |
| bits | 54 bits | 64 bits |
+----------+-------------------------+----------------------------+
|1111111010| 0 | interface ID |
+----------+-------------------------+----------------------------+
Link-Local addresses are designed to be used for addressing on a
single link for purposes such as automatic address configuration,
neighbor discovery, or when no routers are present.
Routers must not forward any packets with Link-Local source or
destination addresses to other links.
Strange to see a Probe selecting a link-local as source....
On 2026-08-06 05:50, Daryl Morse wrote:
Hello,
I've been experiencing a strange problem related to my probe for several
years.
My internet service is GPON, offering 940 Mbps up and down. The service
is provided via a Nokia G-240G-A ONT. My router is pfSense. My probe is
connected to the LAN side of my router.
For the past 3 years or so, there have been approximately 1000 log
messages per day which look like the following:
Aug 5 20:10:28 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst
2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:24 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst
2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:20 kernel cannot forward src fe80:5::2a0:a50f:fc7b:1051, dst
2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:16 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee,
dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:12 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee,
dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:08 kernel cannot forward src fe80:5::6c36:84ff:fedf:e9ee,
dst 2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:04 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst
2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:10:00 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst
2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
Aug 5 20:09:56 kernel cannot forward src fe80:5::203d:3ff:fe5b:d589, dst
2001:569:5b86:b500:1:b3ff:fedd:9f24, nxt 58, rcvif hn0, outif hn1
The destination address belongs to my probe.
For a while I wondered what caused the "5" in the fe80:5::* link-local
address, but apparently, FreeBSD, on which pfSense is based, inserts it
to denote that the link-local address is associated with the WAN interface.
You can see that the messages are periodic, occurring every 4 seconds.
The addresses are not random. They repeat. I presume that the multiple
addresses indicate multiple measurements associated with my probe.
I connected Wireshark to the WAN interface and verified the packets are
present, but without the "5".
The problem is not that pfSense is logging these messages. It's behaving
properly.
I'm wondering why the messages have a link-local source address. The
only explanation is that the ISP router is converting routable GUA
addresses to non-routable link-local addresses, otherwise, the packets
could not have been routed to my probe. Since these packets are arriving
at my router, this conversion must be happening in the ISP router at the
other end of the fibre.
I'm wondering if there is any way to get a log of the measurements being
run against my probe. If I could see that the messages in my log
correspond to measurements against my probe, I could provide that
information to my ISP to diagnose the cause.
I'm interested to hear if anyone thinks this analysis is correct or if
there is another explanation.
Regards.
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the
email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
--
NetCaT GmbH, Bennogasse 13/5, 1080 Wien
FN 433437 h, Handelsgericht Wien, UID: ATU69635335
GF: Michael Kafka, Georg Kraus
-----
To unsubscribe from this mailing list or change your subscription options,
please visit: https://mailman.ripe.net/mailman3/lists/ripe-atlas.ripe.net/
As we have migrated to Mailman 3, you will need to create an account with the email matching your subscription before you can change your settings.
More details at: https://www.ripe.net/membership/mail/mailman-3-migration/
