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.
-
Mmm, it's been there for a long time: https://github.com/pfsense/pfsense/commit/e90c833ade6f5ab60e7ef387e80b1870073120ba
But I don't think I've ever used it.
But also why is it sometimes sourcing RAs from that. Hmm.
-
Apple uses utun interfaces for private relay and I cloud and for email for privacy they all use ipv6 local addresses. It’s just how they are designed now have you set your pfSense to assist on RA?
-
Hi @stephenw10, Yes fe80::1:1 has been there for long time. And it is OK to have it as long as pfSense is consistent in how it uses link-local addresses.
The real issue is that pfSense sends RA from hardware-based link local address like fe80::92ec:beef:34ce:9f76 but when a device sends neighbor solicitation for this link-local "who is fe80::92ec:beef:34ce:9f76" a neighbor advertisement reply "I am the fe80::92ec:beef:34ce:9f76" comes from fe80::1:1 instead of fe80::92ec:beef:34ce:9f76. I am not sure if an RFC specifies explicitly that neighbor advertisement must be sent from the advertised address but it seems to me logical that it should.
To avoid the problem pfSense either should send RA from fe80::1:1 essentially advertising this address as the address of the router or always send neighbor advertisement from the address being advertised.In the Bug #13504 it is stated that the problem could be resolved by adding
AdvRASrcAddress {
fe80::1:1;
};to the radvd.conf file when fe80::1:1 had been added. This essentially forces pfSense to send RA from fe80::1:1 and the problem goes away.
Currently this section is added if CARP is configured. But it is not there when an interface is tracking but CARP is not configured.
I vaguely remember that some versions ago (maybe 23.x or earlier) it was there. But then it disappeared.
I hope Netgate will look closer into the issue and fix it one way or another. For the time being I would like to comment out the section adding fe80::1:1 in case of IPv6 tracking in the /etc/inc/interfaces.inc. Could you confirm that it is OK to do?
-
I would expect that to be fine. It doesn't cause any problems for me testing locally but there could be some edge case I haven't hit.
-
@stephenw10 Thank you. I will do it. If I run into any problem after that I will post it here.
