fe80::1:1 for ipv6 track interface causes a problem with Apple TV box
-
@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.
