fe80::1:1 for ipv6 track interface causes a problem with Apple TV box
-
Can someone explain to me a reason(s) behind adding fe80::1:1 address to a LAN interface if it is configured as IPv6 tracking the WAN? I could not find definitive answer by googling.
The way it is implemented in pfSense (v.25.07.x, 25.03.x and probably earlier) causes an issue with Apple TV Home Kit. It is known that Apple TV acting as a Home Kit hub advertises IPv6 ULA network if there is no IPv6 network already configured. If I configure pfSense LAN interface as IPv6 Static and use SLAAC everything works as expected. Apple TV detects existing IPv6 network and does not advertise IPv6 ULA. But If I configure pfSense LAN interface as IPv6 tracking then following happens.
- pfSense sends out RA advertising the interface's hardware-based IPv6 link-local as a router (let's say fe80::92ec:beef:34ce:9f76). The RA is sent from fe80::92ec:beef:34ce:9f76 address. It is perfectly fine.
- Apple TV accepts it and sends neighbor solicitation request for fe80::92ec:beef:34ce:9f76
- pfSense responds with Neighbor Advertisement for fe80::92ec:beef:34ce:9f76 but the packet is sent out from fe80::1:1 address instead of fe80::92ec:beef:34ce:9f76
- Apple TV senses inconsistency (the packet source address does not match the advertised address) and decides to ignore it, probably thinking it is an attempt to hack a system by a middle-man.
- Apple TV repeats neighbor solicitation request for fe80::92ec:beef:34ce:9f76 several time every time receiving pfSense neighbor advertisement reply sent from fe80::1:1 and ignoring them
- Then Apple TV decides that the router on the existing IPV6 network is not reachable (or cannot be trusted) and advertises its own IPv6 ULA network
- Then pfSense sends another RA, exactly the same as the first one, advertising fe80::92ec:beef:34ce:9f76 as a router and sent from fe80::92ec:beef:34ce:9f76
- Apple TV accepts it and sends out router advertisement deprecating its own IPv6 ULA network
- Then it sends Neighbor solicitation for fe80::92ec:beef:34ce:9f76, receives pfSense Neighbor advertisement for fe80::92ec:beef:34ce:9f76 but sent from fe80::1:1, ignores it, and sends RA advertising its own IPv6 ULA.
- This cycle of advertising and deprecating IPv6 ULA by Apple TV continues indefinitely.
As a result all devices on this LAN continuously reconfigure their interfaces with IPv6 ULA and then remove it. As a result the entire LAN IPv6 is now unstable.
This is not a new behavior. I noticed it while using v24.x and 25.x. There is also old issue in the Issues tracker (Bug #13504 https://redmine.pfsense.org/issues/13504) reporting the same inconsistency with fe80::1:1 address. But the issue went nowhere because the author found a workaround (manual editing of radvd.conf) acceptable to him.
I do not think manual editing of radvd.conf is acceptable as radvd.conf is auto-generated at every boot.
I currently use IPv6 Static configuration to avoid the problem. But once in a while when ISP changes delegated prefix my IPv6 stops working and I have to manually adjust IPv6 static configuration. I would be glad to find another solution for the problem.
Thank you in advance for any recommendations.
-
@akochetkov said in fe80::1:1 for ipv6 track interface causes a problem with Apple TV box:
Can someone explain to me a reason(s) behind adding fe80::1:1 address to a LAN interface if it is configured as IPv6 tracking the WAN?
Every IPv6 interface has a link local address. It's used for a lot of things.
-
I am a network engineer and have been designing network equipment for living. Therefore I know about IPv6 and general purpose of link-local addresses. The pfsense always has link-local addresses on all its interfaces, which are hardware-based. I mentioned in my post the fe80::92ec:beef:34ce:9f76 link-local address. My question was about additional fe80::1:1 address added to the interface in addition to hardware-based link-local address when the interface is configured as IPv6 Tracking. (It is not added when LAN IPv6 is IPv6 Static).
I am also aware that fe80::1:1 address often used in High Availability configurations when there are two routers (primary and standby). The active router advertises itself as having fe80::1:1 address. This way switching from one router to another looks seamless for LAN devices as the router address always stays fixed fe80::1:1.
In my case, I do not use HA and CARP. So, I do not see a reason to add fe80::1:1 to already existing fe80::92ec:beef:34ce:9f76 link-local address. Or, if it is added, pfSense should send RA from fe80::1:1 and not mixing up fe80::1:1 and fe80::92ec:beef:34ce:9f76.
That is why I have posted my question.
-
@akochetkov said in fe80::1:1 for ipv6 track interface causes a problem with Apple TV box:
As a result all devices on this LAN continuously reconfigure their interfaces with IPv6 ULA and then remove it. As a result the entire LAN IPv6 is now unstable.
FWIW, I do not experience this with my AppleTVs, however I have my IPv6 networks configured as Managed. How are yours configured?
-
@dennypage, My LAN is configured Unmanaged. And I can confirm that in case of "Managed" configuration there is no "instability" because with DHCPv6 only (no SLAAC) Apple TV considers existing IPv6 network unsuitable for IoT devices (many of them support SLAAC only) and always advertises IPv6 ULA.
I cannot use "Managed" configuration as some my devices do not support DHCPv6 (SLAAC only). If I use "Assisted" configuration then the instability comes back as Apple TV bounces between advertising IPv6 ULA and deprecating it as I described in my original post.
-
By the way, the instability is hard to notice. Everything looks working. Only if you analyze log files on PC or Mac you will see periodic reconfigurations of IP addresses on the interface. Cycle period is equal to interval between pfSense Router Advertisements. During reconfiguration Ethernet adapter pauses for a moment. Someone could say it is not a big deal. Maybe this is a reason many people who have this issue on their network have not noticed it. But it is wrong in my opinion and needs to be addressed.
I can edit /etc/inc/interfaces.inc script and comment out the section, which adds fe80::1:1 address in case of IPv6 Tracking. But I do not know what kind of other issues in pfSense functionality it might cause. I really would like to see comments from Netgate guys on this issue.
-
@akochetkov said in fe80::1:1 for ipv6 track interface causes a problem with Apple TV box:
By the way, the instability is hard to notice. Everything looks working. Only if you analyze log files on PC or Mac you will see periodic reconfigurations of IP addresses on the interface.
ANDwatch would notice.
-
@akochetkov said in fe80::1:1 for ipv6 track interface causes a problem with Apple TV box:
I cannot use "Managed" configuration as some my devices do not support DHCPv6 (SLAAC only).
That's why I use SLAAC. Android devices don't work with DHCPv6.
